<chaals> intersection observer spec
Stefan: Have been working on the Interesection Observer (IO) spec.
<chaals> one issue to resolve
Stefan: Close to CR, but there is an issue for discussion.
... By default the implementations use the layout viewport by default.
... Out metrics say that IO is used on about 25% of pages loaded in Chrome.
... The visual viewport is more intuitive.
... We're concerned about performance.
... There is some consensus that people should be able to choose between visual and layout viewport depending on situation.
<mgiuca> Pinch-zoom needs to not be janky. Don't want the layout running 60 times per second when pinch-zooming.
Stefan: Question is what should the default be?
Jake: What is the difference between performance with pinch zoom as opposed to scrolling.
Stefan: There is no real rendering work being done.
... Once zoomed it's a composite scroll when you're panning around.
Simon: Do we care about scrolling with pinch zoom?
Stefan: Not sure about the pinch zoom spec.
Simon: There is none.
... There is none.
Stefan: No scrolling spec either.
... Trying to avoid spec by implementation bugs.
Yoav: Impressions are an important use case for IO, but not the only one.
Simon: But you wouldn't want a lazy load image that was briefly visible.
Stefan: The last comments on the issue are about lazy loading.
... For the ad visibility use case, pinch zoom probably isn't that important.
... Would still be good to have a consistent story.
Jake: Has this request been driven by developers?
Stefan: Was being driven by Matt Rakow of Microsoft.
... Who feels strongly that visual viewport should be the default.
Simon: Changing to visual viewport will make it more accurate?
Stefan: Yes, but performance will deteriorate.
Tim: Do we fire events when we pinch zoom?
Stefan: resize and scroll.
Jake: It's not synchronous, but not at the end of the gesture either.
Simon: In favour of picking one.
... Prefer to have visual viewport only.
<JakeA> Layout viewport vs visual viewport https://www.youtube.com/watch?v=S38WTbtgqlY
<JakeA> (no sound)
Stefan: Safari is the only browser not to ship so far, so no backwards compat problem.
Simon: We're working on shipping.
<JakeA> In that video, layout viewport is green/blue, visual is red
Chaals: Straw poll. Who wants it to be optional?
... 2 for optional, 0 layout viewport, and 4 visual viewport.
Jake: Do we need IO to be synchronous?
Tim: The timing when the algorithm is run is very explicit - as son as the new frame of content is ready.
Olli: It's queuing a task?
Stefan: Yes.
Daniel: Is there any spec around when the resizing is fired?
Stefan: We do get resize events asynchronsouly during a zoom.
[slides - hope we will get a copy]
SZ: you get onscreen/offscreen but cannot see when things are covered by other ones.
... a lot of web fraud happens like this so it matters. Proposal for IO v2 is to add trackvisilibilty and sending a boolean indicator.
... if we say isVisible the UA guarantees that the target element is presented on top of everything with no filtering.
... for an example, there is a site with an iframe for payment. Nothing pops out, it is all clean. Problem is that maklicious sites might be covering the payment item but letting the events go to a paymetn button underneath
... so we use the isVisible flag when the click comes in to see if the element getting the click is actually visible
... or make the payment go on top, but with opactiy .04 so tyou cannot see it.
... now we reject it because the opacioty filter is applied. we think this helps protect against common fraud
... the payment provider doesn't need to rely on a 3rd-party to find out if they are visible. So if the UA is trustworthy, the embedded content can be fairly sure it's all good.
... This is implemented behind a flag in CHromiujm,. planning to make this a v2, would love feedback.
RN: seems problematic if there are a bunch of rules…
... what about opacity 80%?
<chaals> i18h issues for UI events
Gary from Google. Addison from Amazon.
Gary: What concerns do you have (to Addison).
The issues I am most aware of related to keybaord events.
<r12a> outstanding issues as seen by i18n http://w3c.github.io/i18n-activity/reviews/
Nobody has a specific issue to discuss.
Updated link: https://github.com/w3c/uievents/labels/i18n-comment
3 issues in there with the i18n-comment label.
r12a's link above has 5 issues which would be good to resolve.
Under input-events.
We're talking about keyboard events, which are directly related to UI events.
r12a also 5 issues under "uievents" in http://w3c.github.io/i18n-activity/reviews/. 2 could be closed.
http://w3c.github.io/i18n-activity/reviews/#uievents
<addison> https://github.com/w3c/uievents/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3Ai18n-comment
Gary: Serbian doesn't use a different keyboard from rest of EU. Any different?
Addison: Serbian has a different layout than other Cyrillic keyboards.
Discussing this issue: https://github.com/w3c/uievents/issues/122
Everyone takes one of 5-6 keyboard layouts and slaps their keys on top of it. Serbian falls into one of these standard layouts.
Chaals: Looks like they are laid out very differently (physically).,
Addison: If you were Russian you'd think they are all scrambled. But in Serbian keyboard, the Cyrillic letters are in the place you would expect the equivalent keys on a Latin keyboard.
Gary: Not sure why Serbian should rise up to be listed here. This would apply to a whole lot of other languages.
Addison: Apparently there's something special about the letters W, A, S and D.
(Perhaps gaming related?)
<garykac> https://github.com/w3c/uievents/issues/122
(Oh yes this is gaming related)
Since we're having troube accessing GitHUb:
5.2.1. Motivation for the code Attribute https://w3c.github.io/uievents/#code-motivation A real-world example of this is a game that wants to use the "W", "A", "S" and "D" keys to control player movement. Editorial: You could make the point more clearly by continuing the sentence to say "... when a user is using a Serbian keyboard (which has no WASD on the key caps and doesn’t produce w, a, s or d when keys are pressed)." (or something like)
(That's the full text of the bug report.)
Looks like all of the issues are easily resolvable. (Agreement between Chaals, Gary and Addison.)
Gary: Keyboard map spec, currently in WICG
https://wicg.github.io/keyboard-map/
Solving the problem of how to identify the physical character printed on the key.
Use case in gaming: we want to use W, A, S, D not because of their letter value, but their placement on the keyboard (W-A-S-D form an arrow pattern useful for gaming).
You can't just use the code value. The keyboard map API tells you a mapping from key code -> the value printed on the key.
scribe: You only need to know ASCII (Latin characters).
chaals: ack
... couldn't find any examples of keyboard shortcuts using non-ASCII characters.
... e.g. for keyboard shortcuts like Ctrl+C, because almost every keyboard has the Latin characters on them in addition to the native keys.
Addison: Also need to consider soft keyboards. You may have a keyboard with no ASCII labels on it.
... For keyboard shortcuts like Ctrl+C you're right.
Gary: For the game use case, virtual keyboards aren't useful for controls.
... Currently the spec looks for the highest priority layout that is ASCII-capable.
... Japanese, the quote key is actually an IME key.
... I'm trying to define "ASCII-capable" as "Can generate A-Z", but the Japanese layout causes some trouble.
Addison: Good to know what the realm of physical keys are.
Gary: Not looking at keys like Tab, Caps Lock, just the ASCII. Only the backtick key is weird, in this Japanese layout.
Ryosuke: My immediate concern is fingerprinting.
Gary: Fingerprinting has been addressed in spec.
... It's easy to fingerprint from a physical layout. But not from the dictionary that we give out.
... We are aware of fingerprinting and call it out in the spec.
rniwa: Megabytes of JavaScript to do fingerprinting.
Gary: Can only be done in the foreground tab. If people want to add a permission, we could do that.
rniwa: Why do we need this before the user starts typing?
Gary: Because at the point where we set up, you haven't necessarily typed anything yet.
... e.g. when you want to show the user what key to press
rniwa: Seems a totally reasonable trade-off to me.
Gary: I think that's awkward but reasonable.
... Normally we express these restrictions as permissions. It sounds like you want to gate this on a user gesture.
... Thats a terrible way of getting permission.
rniwa: Permission model wouldn't work. Typical user wouldn't understand implication about disclosing the keyboard layout.
... I don't think a dialogue would work at all. Privacy concern is mitigated once the user starts typing (because that information is already available to the site).
Gary: Typing a single character does not currently give you this information. So it would still expose additional information to the site.
rniwa: A better compromise would be .... (didn't get this). Not significantly worse if typing a single key would provide this information to the site.
... But the idea that any website can get information about keyboard layout is not OK in terms of privacy.
Gary: Typing a single key versus not typing anything, is not that much different from a user consent standpoint.
... If you're concerned about this, typing a key doesn't really alleviate that concern.
rniwa: Users don't type on many websites.
Gary: You're basically trying to use a gesture as a permission.
... A permission is the proper way to do this if that's your concern.
... We should not have more of these "gesture implies permission" on the web platform.
rniwa: It is unexpected that a website could access my keyboard layout to the website.
... when I'm not using the keyboard.
<addison> http://cldr.unicode.org/index/charts/keyboards
Addison: Are you aware of CLDR's keyboard ^^^ the above link.
... THey are trying to enumerate all the layouts that go with keyboards.
Gary: We thought it was more of a privacy concern having a layout for every kwyboard event.
mgiuca: wondering how much information is exposed here?
... every keyboard has the same layout will need the same map
... is that correct?
Gary: Fingerprinting concern is vast majority of people, no information leaked, but for small set of people, will leak a few bits because unusal keyboard layout.
... People most at risk are people using a non-traditional layout.
... while in a country where that isn't the normal layout.
... Privacy-focused browsers could always return the default layout for the user's current region.
... That's why we wouldn't return a list of all installed layouts. Collapsing it down to JUST emitting the highest-priority ASCII layout significantly reduces the fingerprinting risk.
Addison: Anybody have an i18n spec coming up that needs review? Speak now or forever hold your peace.
(none raised)
Gary: Key and code specs.
... Because there are so many different possible code values (due to supporting multimedia devices etc), got comments that it was hard to evaluate this when implementations are implementing all the desktop keys, but the spec deals with other devices we haven't implemented (e.g. remote controls)
... Should we break the spec into two levels (desktop, and everything else)?
... We want people using relatively stable values rather than making up their own.
chaals: Breaking into 2 levels is an easy way to do that. Ending up with lots of specs is a pain.
... Seems to be W3C's way of doing it. If there is a linear progression. (Level 1 = everybody implements, Level 2 = obscure things, and some people implement some parts but not all)
... Maybe another approach is instead of breaking the spec apart, say "Here are the things you have to implement, i.e. the level 1 stuff. Here is the experimental stuff, but we might change it."
Gary: Any precedent?
chaals: Not off top of my head.
... There would be SHOULD requirements in the spec for the Level 2 stuff.
Gary: Problem with REQUIRED vs SHOULD to mean "mandatory" and "experimental". Because there will be stuff in the Level 1 part that are not required.
chaals: Some of it will actually be pretty clear. Others will not be very clearly defined.
... we'd like people to use this, but we don't want to nail it down.
Gary: It's a bit more formal than that, because we refer to other specifications and map them into our values in the web spec.
mgiuca: My feeling is that it's messy to use REQUIRED vs SHOULD to mean level 1 vs level 2. It doesn't match my understanding of those words in spec language.
chaals: Splitting to l1/l2 is the path of least resistance.
rniwa: I would prefer if the key code and key value spec was a single spec instead of 2.
Gary: You're likely to get the wrong key, because it's confusing to have both tables in the same document.
... Someone finding within the page of the document would end up finding the wrong table. People typically only use one of those two specs, not both.
... People doing games typically want the key codes, whereas people using them in other applications use the values.
rniwa: Also there is no normative text explaining what they are.
... We need some normative text linking the two together, so when you press this key you get this value.
Gary: A lot of the time you're passing through what the native OS is giving you.
rniwa: Ctrl+C versus Command+C on Mac. (mgiuca: Not sure what the point was.)
Gary: Many of these issues are hard to fix because we don't have an algorithmic definition in the spec.
... Because the spec is very old (from 2000s era).
... I have been trying to write down full algorithms for each event firing. I've started working on that but I didn't get as much done yet as I'd hoped.
... Wednesday (break-out sessions) hoping to have some brainstorming about this.
<garykac> https://docs.google.com/document/d/1ftDHpkz_6bYn0SbI0DU6xyMbBy2q2SktB875_EPipPw/edit?usp=sharing
<garykac> http://domeventviewer.com
Gary: The above doc, anyone can edit.
... The above demo lets you see all the different event firings, so we can try and figure out the differences between browsers.
... Want an early first draft of this more solid description of the UI events, by the start of next year.
chaals: Good idea.
... Please don't remove the stuff from the simpler times. Very useful for readers to get a quick sense of what does it do.
Gary: The vast majority of this would become non-normative.
Richard: For i18n review, we don't have the bandwidth.
Gary: Keyboard lock and keyboard map.
... Feedback from devs on keyboard lock. Would like to have two different levels. The thing that most developers want is the easy stuff. Fewer developers want the harder stuff.
... KB lock for immersive apps like games, so that Alt+Tab and Esc don't take you out of the app.
... More common case is just the browser keys (like Ctrl+W), things that browsers typically take from you. The hard case is the OS keys like Alt+Tab.
... Does it make sense to merge lock and map together.
... Thinking of splitting these cases out into two specs or two levels.
Nobody expressed care.
Gary if nobody cares, keep going the way we're doing: which is two separate specs.
End of session. Break time.
TL: This spec has been around for a while, describes inner/outerHTML and some related features, describing how to set up the calls and relies on the HTML parsing spec. Describes XML serialisation
... Today we want to talk about how to continue to make progress. I am the editor but havne't been ative and issues are waiting for resolution.
... about 3 months ago wwg asked if we should reintegrate the content into the HTML spec, we discussed that. The question is whether that would help resolve the issues.
... I propose considering that we reintegrate it to HTML, and rely on the active editors to do the work instead of having to figure out what problem goes where.
... I don't plan to keep working as editor so I welome people taking over the work. There may be a concern from W3C about the spec leaving W3C. Otherwise I would expectg to reunify… questions
PLH: I am supportive of the reintegration.
CMN: Taking my chair hat off and representing Consensys
chaals: Question of whether you re-integrate is separable from whether it goes out from W3C to WHATWG.
... Web components were put into both of the specs. I don't see a problem with doing both.
DomenicD: Thank you Travis for working on the spec. Part of the discussion is someone who implemented it from scratch found a few bugs we would like to address but overall a great job.
RNiwa: can we look at the open issues?
adjacent HTML is broken (issue 4)
TL: DOM has an insertion algorithm and I think the DOM spec has moved forward and doesn't have a direct insert so we need to make a change. Seems like using pre-insert may introduce complications.
DD: In particular, insert doesn't adopt across different documents. There are also validity checks that may not apply here. Need some research and testing.
... seems like there is a clear test to o, and I hope the answer is that nodes are adopted across Documents
-> https://github.com/w3c/DOM-Parsing/issues/6 sort out innerHTML with <script> and <style> in XML. Per spec scriptt is disabled on XML, but browsers make it work.
scribe: you need to set enable flag to match browser behaviour. Second point is that you do something but it is redundant - the spec could be clearer. (Buty this is issue 7)
TL: seems to use HTML style context to insert text instead of nodes when you add markup…
... when inserting a style element.
... this is very non-interoperable so we can choose what to recommend. Needs tests cases and continued discussion.
RN: Seems that the HTML behaviour is required for WebCompat. For XML we can maybe change gthe behaviour to make it like a normal XML parser.
TL: Does it get mode from teh document or the operation context?
RN: I think we normally follow th document's mode. You can have SVG or MathML in there, and it should be like XML.
TL: Boris says webkit/blink behaviour is totally broken. Seems like we need to work out how to find a consensus. Things may have changed too.
DD: We should enable scriptiing in XML docs because browsers do, the other action is editorial,. Seems easy.
-> https://github.com/w3c/DOM-Parsing/issues/19">https://github.com/w3c/DOM-Parsing/issues/19 https://github.com/w3c/DOM-Parsing/issues/19
TL: Ooooh.
DD: Figure out what happens and spec it? Does anyone have an opinion already?
JA: Think the intent is to run script if the HTML parser would run them during initial parsing.
RN: If the script it inside template the point is not to run?
... doesn't matter as much because people importNode, but think the script inside template not running has the virtue of its document not having browsing context. If you adapt it to another document you don't want it to run.
JA: createContextualFragment feels hacky. As part of the integration that could be fixed.
TL: High-order bit is to test carefully and match reality.
DD: have noted some stuff in the issue.
HTML entities and serialisation
DD: this looks like a feature request and a claim based on bad data
TL: Let's see if we can just close this
DD: Agree
define innerHTML on ShadowRoot
DD: Seems pretty straightforward. There is multiple implemnetation - were there any complications?
RN: Think we need to figure out the right context element for parsing inside shadowRoot - host, root, template, …?
TL: Need to find out what happens.
RN: Not that worried about interop, if we do a more permissive thing it won't break, if we are more restrctive that might be bad.
DD: Will note and look for implmentation info.
DOMParsers parseFromString should have CEReations
TL: Custom elements are per realm, so any doc in the realm would trigger reactions
DD: How do we get to the realm?
Define origin of documents returned from DOMParser
DD: It may be the opaque origin, nobody has tested. Not sure what this affects if there is no browser context
... fetches and stuff won't happen. Needs testing.
clarify requirewellformed is optional
TL: Think that can be done pretty easily
flags don't have T/F as values
TL: the spec editor should have picked that up. The clever new ones will.
fragment serialisation serialises node itself
DD: THink we ran into this when implementing in JS
TL: I think I have a PR open for WPT …
DD: We want to keep track of that while we do this work
TL: Explores magic of namespaces and making attributes ...
attribute prefixes aren't preserved?
DD: This is an issue
RN: going back to 22, we can close it because we don't need to have the Reactions because we create a new doc that won't have any custom elements in it
TL: Issue 29 creator put together a PR that we merged.
DM: need to take a look
DD: We have multiple JS implementations
Daniel Murphy (Google): Talking about IndexedDB
scribe: Topics: General spec updates. A few new APIs we're working on.
... IDBFactory.datases [sic?], IDBTransaction.commit
<pwnall> IDBFactory.databases
scribe: Want to modernize integration with other specs/APIs (e.g. BigInt, HTML, DOM, WebIDL).
... IDBFactory databases. Used to be webkit prefixed way to get database names but was removed.
... Now adding the same functionality back in with a new promise-based API, due to popular demand.
(sorry I missed a bit because my IRC stopped working)
Daniel: Ran through an example of put() then get() illustrating the difference between auto-commit and explicit commit, on performance.
(Eliminates one roundtrip)
<pwnall> IDBTransaction.commit: https://github.com/andreas-butler/idb-transaction-commit/blob/master/EXPLAINER.md
<dmurph> https://www.irccloud.com/pastebin/u7JZdbPS/
Jake: What does commit return?
(Jake Archibald)
<pwnall> IDBFactory.databases: https://github.com/w3c/IndexedDB/issues/31
dmurph: It will throw an exception if you try and issue more requests to it. (The callback)
Jake: Could you provide a promise instead?
dmurph: Commit() returns void.
<pwnall> IDBTransaction.commit spec PR: https://github.com/w3c/IndexedDB/pull/242
<dmurph> Databases()
<dmurph> Feature issue: https://github.com/w3c/IndexedDB/issues/31 (previously https://www.w3.org/Bugs/Public/show_bug.cgi?id=16137, http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1528.html)
<dmurph> Pull Request: https://github.com/w3c/IndexedDB/pull/240
<dmurph> Explainer Draft: https://github.com/andreas-butler/idb-databases/blob/master/EXPLAINER.md
<dmurph> Intent to Implement: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/qKjn0tLMezI
Domenic Denicola: Async Local Storage
Domenic: Main missing feature from the web: simple key/value store API.
... Right now, you need to use the sync localStorage API, or IndexedDB.
... Proposal to provide, in the out-of-box web experience, an async key/value store. Called Async Local Storage.
... StorageArea has async map methods: get, has, delete, clear, keys, values, entries.
... Can use the underlying IndexedDB backing store.
... If your app has evolved past the basic async storage API, you can also directly talk to the indexed DB. (This is just a wrapper around IndexedDB)
... Default StorageArea for localStorage-like use cases. Unlike sync local storage, you can also create your own individual storage areas.
Tess: Is there a fixed name for the default storage?
Domenic: Yes, it's just called localStorage:default. (MG: I think, something like that.)
<dmurph> link to presentation: https://docs.google.com/presentation/d/1xuj772aWD5zNYlsnCCOaAquRvGg94nDUHYP6JCodtQk/edit?usp=sharing
Domenic: Open questions: Naming (perhaps local storage is a bit misleading). Should "has" exist? May encourage use of has-then-get pattern which would be non-atomic.
... But then that means need to think about whether "undefined" is a valid value that can be stored, or whether it represents absence.
... Should we abstract further over Indexed DB by reducing key space.
olli: Does this need to be layered on top of IndexedDB? Can it just be standalone API.
Domenic: Would be unfortunate to introduce a fourth storage area, with its own quotas and management. Good for developers to "upgrade" to Indexed DB via the backing store.
olli: Will LAPIs [editorial: the technology that async local storage is built on] be natively implemented in a browser or does it have to be written in JS?
Domenic: It can be implemented natively, does not have to be written in JavaScript as a wrapper.
Jake: Does the .... ???
Domenic: The store will always be called "store". So you can easily blow away the whole database at once.
<chaals> s/There is a timeout on the life of the serviceWorker as a whole, not the specific waitUntil/setting the store name set the database name or the store name?
<chaals> JA: In the library I maintain I allowed people to set both, and that was a mistake.
Domenic: This is in the IndexedDB because it almost feels like part of the IDB API
... (once it graduates from incubation)
AliA (Microsoft): Do you anticipate that this spec will work its way back into IndexedDB, or maintained as a separate spec?
Domenic: Feels natural enough to be in IDB. Up to the IDB community and editors. Could go either way.
... Presumably the same implementors would maintain the code.
AliA: Big fan of the API surface. As co-editor on IDB spec, I would love to see it part of the same spec.
dmurph: Downsides of IDB. Pretty confusing API. Callbacks everywhere. Not compatible with promises (because of its age).
... Jake Archibald has his library that wraps around it with promises.
... Changes are not reliably observable. So when people need a guarantee around observing changes happening to the DB, this is missing.
... Especially since IDB applies to whole origin.
... Doesn't work with promises well because the auto-commit can commit the transaction where it would be unexpected. Because if one step in the promise change doesn't directly do another operation on the transaction (e.g. it does an in-between step like hitting the network), then the transaction will be auto-committed.
... A waitUntil API on the transaction would help with this. You give the transaction a Promise and it would not commit until the Promise resolves. Matches the WebLocks API.
... Downside: If you make a mistake you might accidentally never release the lock. Essentially you'd be holding the lock forever. The user might need to restart the browser to get the website to work again.
... (This would literally be a lock on the database table.)
... It makes sense to have this API in WebLocks because that's the whole point of WebLocks. Maybe not so much for IndexedDB (maybe an unnecessary footgun).
... Soliciting feedback on whether this makes sense.
Jake: WebLocks API takes a callable that expects a promise. Whereas here it just is waitUntil. Which is being proposed here?
dmurph: Either.
... We don't need to wait to take the lock. Could wait until autocommitted.
... I would imagine it just being a promise.
Andrew Sutherland, Mozilla: Web Locks has a concept of breaking a lock. Would we be able to do this here?
dmurph: If the commit API is there, that could force the transaction to commit. You would have to do bookkeeping on all of your transactions (which seems reasonable).
Jake: There's an abort() method on transactions as well.
Travis: waitUntil and Service Workers: I thought there was an explicit timeout.
Jake: ... ???
Travis: Maybe establishing a timeout could be useful.
Matt Falkenhagen, Google: I don't know if the spec lets you timeout an event at any time. Chrome's implementation will let an event live up to a certain amount of time (per event, in the service worker model).
dmurph: Both commit() and abort() are good tools to make this seem less scary.
Jake: When the timeout is reached, we kill the SW. The equivalent here would be killing the tab.
Matt Falkenhagen: We're changing this; now going to let the SW live and just timeout the event.
scribe: If there are no other events, eventually the SW will die (that's an implementation detail).
dmurph: Would be nicer to not have a timeout and let the page handle it. We have a pretty long tail of how long it can take for a callback to come back to the page.
Ben Kelly, Google: We had a similar issue with the fetch() API, which we solved with the abort() signal, letting sites control their own timeouts.
scribe: There's history for using the abort() method for timeouts.
Andrew Sutherland: We're positive on this at Mozilla. Since libraries can already hack around this by spamming (something?), better to give explicit control.
dmurph: IndexedDB observers. Work stalled for a few years. (It was behind a flag in Chrome but not many people checked it out).
... Every transaction's changes would be batched together. You could also have a transaction with it where you could read in the rest of the world.
... With page lifecycle (e.g. pages being hibernated), this basically holds a lock on the object store. So if you require that your txn has a consistent state, you're preventing other people from doing changes. We'd like to remove that feature.
... And we'd like to remove the idea of having batched changes [I think??]
... Have to think about how much batching we'd want to do.
... Maybe worth defining the amount of changes that could be batched.
... We want to remove the special transaction with the changes.
... Currently, your callback gets called with the set of changes that a transaction has done.
... 1:1 mapping from transaction to the notification callback.
<chaals> MG: So there is currently a notification per transaction. Could you have part of a transaciton notified or is it a minimum of 1?
dmurph: We want to make it so we just send you them in batches. You could see multiple transactions come in in a single notification.
... But you wouldn't see part of a transaction in a notification.
... The observer API you would get called back multiple times. The API takes a transaction, which means you need to start from a particular state of the world. So observation is tied to a specific transaction.
... After this transaction is completed, your observations will start. For syncing changes to a server, there would be a table with your changes. And from the same transaction where you put your changes, you start observing, to guarantee that the state is consistent.
(That question was from rniwa.)
End of session.
<dmurph> https://github.com/WICG/indexed-db-observers
<lisaS> can i have a link to the call in details?
Charles: Personalization Task Force (TF) wants your help deciding which schema we should use.
<xiaoqian> Personalization Semantics https://www.w3.org/TR/personalization-semantics-1.0/
Charles: The work came out of the Cognitiive Coga) TF, now part of the Accessible Platform Architectures (APA) WG.
... Users often need simplified content, or augmented content that helps them identify certain types of content.
... For example, "9 out of 10 people" could be simplified to "almost all people...".
... Another example, an agreed set of symbols can be used to identify common types of content.
... We have three documents in Editors Draft (ED) status.
... Personalization Semantics Explainer; Semantics and Context module, Help module, and Tools module.
... We have different implementation options, and would welcome your help in identifying the one to take forward.
Daniel: Can you explain more about the symbols?
Lisa: People with severe language communication difficulties can often communicate successfully using symbols.
... People who for different reasons, like brain injury, find words difficult but who can learn symbols.
<clapierre> http://www.blissymbolics.org
Lisa: At the moment most symbol sets are propriatary, which is a problem for a web solution.
... UNICEF is working on a unified symbol set called Bliss.
Daniel: Does this also mean translation from common spoken language to symbols, or just between symbol sets?
Lisa: It would enable adaptation of normal content, but only for people using the given symbol set.
Ryoske: Finding it hard to understand the use cases, could someone give a concrete example?
... Also, can someone explain why this is not possible in existing technologies like roles etc.
John: The idea is having a common token, so that it doesn't matter which symbol set you want to use, it maps to a common set of tokens.
<lisaS> is an example of using symbols
Chaals: When someone doesnt understand a written language, they can see symbols instead, which they will recogise.
<chaals> LJW: There are different audiences. ARIA works for screenreaders, that provides text information, but that text isn't the information that someone using symbols actually needs. There aren't enough tokens in ARIA to cover the needs.
tink: aARIA is for a different audience.
... So aria-label gives an accessible name to an element for a screen reader user, but that information is not the same that a person with a cognitive difficulty needs.
Erfan: An example is different types of address - office address, home address, would there be a different symbol for each?
<lisaS> you can cogigate symbols as well
Steve: No, the symbols tend not to be that granular.
<lisaS> congregate
John: The underlying goal is user-personalization.
Terence: We (HM Gov) are keen to help on this.
... Is the icon set envisaged to become part of Unicode?
Steve: They're not emoji.
Terence: I know.
Chaals: The questin we want to resolve, is that given these needs, how do we do it?
John: It's element level metadata.
Terence: Looking at the examples, it looks like many of them could be addressed by writing better content.
... Is this the right solution for all the examples in th Explainer?
Chaals: The use case goes beyond this solution.
Lisa: Sometimes user needs conflict.
... People on the Autistic Spectrum might prefer "90% humidity", but others might prefer "it's t-shirt weather".
<JF> Comparison of ways to use vocabulary in content: https://github.com/w3c/personalization-semantics/wiki/Comparison-of-ways-to-use-vocabulary-in-content
John: We'd like feedback on the proposed taxonomy, but also on the method of adding this metadata
... We've considered models, different forms of syntax.
... Single attributes, single attributes with multiple possible delimited values, prefixed attributes, etc.
Ryosuke: If there is an address field, and someone gets the symbol of their choice, how do they populate the field?
Chaals: They have a button on the board that lets them populate that field.
John: In WCAG2.1 the autocomplete attribute is a recommended pathway to enabling people to easily complete form fields.
... It's a machine understandable taxonomy.
<bkardell_> are the ones in here with shortlist** the ones those presenting prefer?
<chaals> [Yes bkardell_ they are]
tink: it's content switching, instead of seeing the word "Email" you would see your preferred symbol representing "email".
Chalres: There is a session on Wednesday where we can continue this discussion.
<Zakim> chaals, you wanted to ask how big this vocabulary is, and whether it is a single layer of labels or a deeper structure with multiple layers.
John: We have three modules, and we have about 17 or 18 conceptual terms in the taxonomy.
... That could grow, but likely by tens not thousands.
Lisa: Symbols number in the hundreds and take a URI, but there is no concept of nesting.
Tomek: How much could this solutio be reused?
Lisa: Yes, it could be reused.
... Translating content, annotating content, etc.
... Suggestion is that people look at the proposed options, and perhaps we could have a joint discussion at some point?
<JF> One more time :) Taxonomy (ies) Personalization Semantics Content Module 1.0(https://w3c.github.io/personalization-semantics/content/index.html) Personalization Help and Support 1.0(https://w3c.github.io/personalization-semantics/help/index.html) Personalization Tools 1.0(https://w3c.github.io/personalization-semantics/tools/index.html) Personalization Semantics Explainer 1.0(https://www.w3.org/TR/personalization-semantics-1.0/)
Chaals: The solutions boil down to a couple of options,
... are there pros and cons to either?
John: Any method needs to be author friendly.
... Including through the use of a WYSIWYG editor.
Ryosuke: Would avoid micro-syntax.
... Use exiting host language features as much as possible, and extend if there is something missing.
Chaals: Is there a preference on style?
Ryosuke: This keeps coming up.
... In each discussion we've found that actions often require an input.
John: Once we have the taxonomy, machines can learn and use it.
Charles: We may want to add multiple things onto a single element.
<bkardell_> Is part of the ask here to reserve a new "aui-" space then?
Charles: For example the symbol, plus a simplified version, plus a prioritisation level.
Lisa: Is this group open and amenable to us taking something like rel or type and using it?
Chaals: I suggest that if we do that, we'll have a world of pain.
... Think we want a mechanism that adds cleanly.
<chaals> [bkardell_ potentially yes…, unless we choose one or two attributes that each take a dictionary of possible values]
Steve: Agree.
Chaals: Agee with Ryosuke, don't go for a micro-syntax.
John: If we have single attributes, we stil need a way to define multiple values.
Brian: Where did AUI come from?
... Have some concerns because there is a CSS vendor that already uses that prefix, my company also uses it, probably others.
John: We went through multiple prefixs.
<chaals> tink: I would suggest not prefixing it - there are multiple use cases outside the personalisation semantics.
<chaals> … siloing it into accessibility will actually reduce uptake in useful scenarios.
tink: Would suggest not using a prefix.
<lisaS> whole colection
<lisaS> Iv seen authors get mixed up with the others
Chaals: Let's get a sense of how people think about this...
... Collection of attributes 1.
... Think it's hard and needs more htinking 6 people.
... Let you go away and decide 0 votes.
John: Not seeing a lot of votes, so what's the missing piece?
Ian: For me it's looking at the taxonomy.
Chaals: It seems that a large collection of attributes is not the way forward, but more thinking on the taxonomy would be good.
<lisaS> do we have next steps?
John: Given that there will be some interdependency here, can you give us a sense of the process we should follow?
Chaals: Come back with a clear sense of what the vocabulary looks like.
... We have some sense of how we can add it in.
<lisaS> we have a clearish vocablary
Lisa: We The vocab is clear.
... It might be tweaked but it won't substantially change.
Chalrles: Reminder of the Wednesday session.
https://github.com/wicg/cookie-store
<falken> ScribeNick: falken
Mek: Modern API to give an alternative to document.cookie
... asynchronous, observe cookie changes, both in documents and in service workers
... we've tweaked the API a little since last year
... and implemented it
... any concerns about shipping? or ways to change to be better
JakeA: API questions...
... ?? takes an options but two of those options are required?
Mek: what you get from get you can put back into set
JakeA: can't omit those. get() without a name does what? first one that matches the url and matchtype?
Mek: good q
<pwnall> i can answer this
<pwnall> (it's yes)
Mek: not really familiar
annevk: rationale for set?
Mek: can pass beteeen get and set without having to change it
annevk: for other maps we don't really have that pattern where you return from get and pass to set
pwnall: can you hear me (yes)
... the thinking here for set/get. sites will want to get a cookie and change a single attribute
... unlike a normal map a cookie has many attributes... expiration date
JakeA: that will be racy
pwnall: it will be if someone else is trying to do the same thing
<Domenic> It's almost as if we need some kind of lock API... for the web...
chaals: recognize Anne's point. Motivating usecase is pretty sound. Except for the raciness.
... can you just build the API so it takes the non-optional things. the non-optional things go as name-values. and you throw them in when you get(). so they are gettable and settable.
<wanderview> JakeA: raciness can be solved with WebLocks
JakeA: could have an update method
[everyone says weblocks]
wanderview: web locks api
pwnall: thank you for feedback
<chaals> scribe: chaals
[missed a bit off the initial stuff ;( :(]
<scribe> scribe: falken
rniwa: obviously don't want known racy api. can we make a cookie observer interface
... subscribe to changes
Mek: docs get events for every change that affects you
... for service workers that doesn't work well
... subscribe and adding events to service worker would work
JakeA: talking about onchange event or subscribe to changes for service worker?
rniwa: still feels strange that we have two diff mechanisms
... seems subopitmal. is this a general pattern for service workers
JakeA: don't really have anything like this just yet
wanderview: push notifications
JakeA: that hangs off registration
<chaals> [+1 to two methods being suboptimal…]
JakeA: this we want on the install event
Mek: we did this for other things on install event
pwnall: the code that manages the cookies and observes the cookies will have an easier time if it's entirely inside the service worker
Mek: and we'll want to change subscribtion after the service worker installation
pwnall: currently have it so subscription can only change in the install event
... becuase of no known use cases for otherwise
... for impl it doesn't matter. can change the spec
rniwa: question. point of the subscription is the service worker gets woken up when the cookies it subscribes to are changes
... what are the use cases for that for being woken up before the network request that uses the cookies
pwnall: login monitoring. detect sign out. sw deletes all cache data.
... cookie might expire
Mek: not immediately
pwnall: eventually. but it can be significiantly before any network request
JakeA: most privacy sensitive way is to say it's guaranteed to happen before the next network request
Mek: or anything on the domain
JakeA: or anything that would wake up the service worker
rniwa: technical challenge. for ios... we delete cookies and browser isn't running at all
hober: if your application depends ??
rniwa: cookie will be deleted even without our knowledge
... browser isn't even running
wanderview: is it deleting the hwole oriign or just part of the origin's cookies
... if deleting the whole origin including the sw, sw is gone anyway
rniwa: good point... i think we do delete the entire website's data.. not sure if in all cases...
dmurph: i did research on cookie deletion. chrome tries not to delete cookies on granularity more than registerable domain. sites would break if you do more fine-grained delete. like single origin deletion
pwnall: as long as the sw doesn't get to run and do other things like return cached response to doc before it had a chance to notice the cookiechanged event, then the application wouldn't have a way to notice ??
... this is useful. thanks for the feedback
annevk: will the feedback affect the spec
pwnall: yes we will think about it and try to come up with ways to address it
... last time we brought the spec to microsoft said they interested in one part so we split up the spec that way. and we heard the spec was too long so split it up. so we are interested in taking feedback and addressing it.
<JakeA> fwiw I like the feature & API. Nice and simple.
dmurph: not sure if there's a case where a website data gets deleted in a way that doesn't just look like a fresh visit of the page
... i think the concern was if something outside dleetes the cookie data, how does the page tell
... but i don't think that happens for chrome, it's either all or nothing
asuth: web extensions api provides a more granular wiping
... but i don't think it makes sense
annevk: in our UI it's separate
asuth: yes the ones that are sane are all cookies and offline data coherently deleted
annevk: site vs origin
... browser UI typically still allows for some granularity vs all or nothing. but not all browsers figured out origin vs site yet.
... http header clear-site-data might provide some granularity.
Mike: [clear-site-data explanation]
... site owner is responsible for handling the granularity
... chrome's cookie settings ui. our current ui shows origins.
... users can delete individual cookies from origins
... it's not clear we need to account for that in this API
... only users who really know what they are doing
... we need sane behavior for the events that are fired
... seems reasonable that the service worker be notified, unless the sw was wiped too
JakeA: service worker can maintain its view of the world for the last time the event was fired. and compare that view the next time it's woken up
chaals: do weblocks and come back, or continue?
rniwa: did we get an answer from tab about the web components
chaals: tab is here on thurs
rniwa: [asked about scope]
pwnall: service worker gets events for a scope
JakeA: doesn't seem to make sense to tie to service worker scope
pwnall: service worker sees all urls under which it can serve a response
JakeA: creating an iframe for an origin...
<chaals> [Note, we continue this discussion, and will move Web Locks back - either after this or at 4.30 pm
JakeA: if the cookie api is restricted to scope of your page, it's not a worthwhile restriction because you can make an iframe to break that
wanderview: but service worker can't do that
rniwa: if you make an iframe in the page it doesn't go to the service worker
annevk: but page would have script that runs in the iframe
... don't do this for referrer. origin is the boundary
rniwa: you can see the referrer header ...?
annevk: only restriction for referrer is same origin
... same with cookies
... once you have access to an iframe and can run script you can do what you want within the origin
Mike: rephrasing that. path attribute on the cookie is not actually a security boundary.
annevk: yes. hopefully clear in 2018
rniwa: seems strange that you observe change to random cookie not in your scope
annevk: but scope.... .... .nevermind...
Mike: cookie security model doesn't match the same-origin policy
... would be better not to support path attribute
... but we have it and people rely on it... so there we are
annevk: service worker scope and path are similar
rniwa: not talking about security threat
... but app's scoping mechanism
Mike: what are the arguments to the subscription mechanism? if you can add filter it might make sense.
rniwa: as I understand it you specify the URLs
... so why are we allowing observation of things outside of service worker scope
Mek: no reason to restrict it
JakeA: scope's a feature not a security boundary
rniwa: not sure
wanderview: subscribe mechanism has a startsWith
Mek: cookie name not path... but you can specify URL
asuth: concern is we don't want to wake up additional service workers
Mike: makes sense. and makes sense for service worker to filter itself. sounds fine
rniwa: maybe something like by default you just specify the name
... subscription thing in service worker requires quite a bit of thinking
... not ready for prime time
Mek: file issues!
pwnall: i think what you describe is roughly how it works today
... we're open to making the API more capable
... easier to ship a more restrictive version first
... and open it up if we convince ourselves
rniwa: i see. current proposal rejects it.
pwnall: open to making subscription mechanism more complex
... paths
... start with the minimum solution for handle the use cases
annevk: main reason to not restrict path is it gives a false sense of security
pwnall: i'll defer to MikeWest
Mike: agree with Anne
JakeA: would be nice to see the spec define how the events fire if the service worker isn't awake.
... fire once awake etc
... to avoid abuse
pwnall: that would have to be balanced with a desire to clean caches as soon as the user is logged out.
dmurph: api for subscribing
... can you explain the two-step process here?
... it's so you don't wake up the service worker if you don't want it?
Mek: yes.
chaals: suggest we break
... weblocks at 4:30
... rAF at 5
wanderview: API that Joshua Bell and Victor Costan have worked on
... page or worker context can lock a resource and do exclusive work on it...
<dmurph> https://github.com/WICG/web-locks
wanderview: feature that has been asked for, for a long time... initial request proposal from 2009
... google has been interested in implementing in the last year
<pwnall> Web Locks deck: https://docs.google.com/presentation/d/1Xalf4FF9NnHn8wm62znGAkXiXsSb40r_xYxIWBZSWxU/
wanderview: Josh posted an explainer on WICG Discourse
... TAG review... feedback from bz
... Google Docs sees a 10x reduction in error rate when using the API
... promise-based api
... use-cases: document editor with multiple tabs open that must coordinate activity. earlier example today of cookie API with races.
... additional features. shared locks. e.g., for efficient database access.
... abort to get out of blocking state
... ifAvailable
... API to query what locks are outstanding. for debugging
... steal feature to break a lock beyond the abort signal.
... dangerous feature but an escape hatch if a site is stuck
... the API does not prevent deadlocks. you still need to be familiar with concurrent programming.
... why not atomics? sharedarraybuffer only works in one agent cluster
... this API works across processes
annevk: example: two tabs can be in diff agent clusters because they are in diff processes even if they are same origin.
... each tab has an agent cluster.
wanderview: common question that comes up when looking at this API. the options argument and then callback. why isn't options the last argument?
... it's more ergonomic this way. the options are more visible when the callback is a long function
... was talked about extensively at TAG
yoav: is this the new way to do these kinds of options followed by a function?
<scribe> ... new standard?
wanderview: ... tag liked it....
pwnall: we picked this form because it's the easiest way to use from javascript.
... anonymous or inline function still look nice
bz: true of the common case
... is the expected thing to pass in options or not
... you can explicitly allow two arg version and three arg version
wanderview: yes that's what it does
ali: do we think these APIs are useful in service workers
wanderview: yes available in windows and workers
asuth: how would this work in Edge? push notification in separate service worker?
ali: as of latest release in October, we now forward background push notifications to foreground service workers
... expect in the case where Edge isn't running
asuth: so now you only ever see one service worker?
ali: yes
wanderview: other cases to consider. what happens if a background tab has a lock. can the browser throttle the tab?
... in theory should work like open indexdb transactions. probably the browser wouldn't throttle it.
??: requires the page to handle that
wanderview: browsers shouldn't throttle pages that have a lock
??: what happens in mobile
wanderview: discarding is the easier case. frozen is problem
rniwa: in case of mobile, the background tab would be completely suspended
<asuth> Olli was Olli
wanderview: what do you do for indexed db transactions that are locked?
... do you freeze them?
... while foregground pages are locked?
rniwa: don't know of the top of my head
wanderview: whatever you do there should work for this api
dmurph: for indexed db we have two types of locks. one on the transaction, so just having the transaction open locks out tabs. other lock is on the db connection.
... our approach is to kill a page that we'd otherwise suspend, if it's blocking another page
... we don't throttle existing indexed db tasks. [?]
rniwa: not sure how we do the indexed db case.
wanderview: extended topic of discussion: would indexed db ever be written to depend on web locks
... don't think there are plans now
... there was a question about lock manager scope
... bz had a question on a blink dev thread
... how to determine how pages share a lock manager
... boils down to same scoping that's used for storage
... in a browser that scopes storage for third-party storage... the lock manager should do the same scoping
... same applies to private/incognito tabs
... Any questions/feedback?
iclelland: spec refers to wikipedia for private browsing modes
... is there a w3c definition of this concept
wanderview: don't believe it's specified or works the same across browsers
bz: and users have no idea how it works
chaals: there's a stubbed spec somewhere, probably attached to the TAG
yves: no specs, just random ideas.
... will look up where it is
iclelland: should it be specified wrt privacy mode
... in web locks API
<Mek> https://github.com/w3ctag/private-mode
wanderview: i believe it's covered by saying it's about the browser's storage mechanism
... dont think web locks spec will define those things
<Yves> https://github.com/w3ctag/private-mode
<wanderview> web locks API presentation link: https://docs.google.com/presentation/d/1Xalf4FF9NnHn8wm62znGAkXiXsSb40r_xYxIWBZSWxU/edit?usp=sharing
[trying to find szager]
JakeA: will give it a go
JakeA: spec has it at the start of the render. before events like resize/mouse events.
... firefox and chrome implement seemingly according to the spec.
... edge has change relatively recently to do it too
... safari doesn't
... plans to change? or disagreement
rniwa: don't think it makes much sense, but there's enough web compat issues that we have to accept that reality and change the impl probably
JakeA: the place where safari runs requestAnimationFrame I"ve wanted a callback there before
rniwa: the problem with the current model is you get the callback at a random time for the next frame... dont know when the next frame is coming... consider ipad... the refresh rate is changing constantly
... if you don't know when the next frame will be painted you're drawing bogus frame
JakeA: resync time?
rniwa: if you get a callback at that point there's no guarantee when the next callback is for the next frame
... all sites assume 60hz. consider ipad at a different frequency... you get a callback that's but you don't know when the next frame is coming - might be twice as long away as you think…
JakeA: why don't css animations and such suffer from the same problem
rniwa: many animations we do is done by CoreAnimation
... they know when the frame is rendered
... every native graphics API has this thing. tells you when the next frame will be
... we need to have an api where either it tells the browser when the next frame will be shown, or the browser should tell the script when to draw
... everyone needs to impl what chrome/gecko implement because of web compat
... but i think we need another API
JakeA: rAF gives us a way to debounce things until...
... yea should look at another API, extra param or extra thing
... interested in a callback that fires after layout
rniwa: anyone discussing resize observer?
... similar issue there
JakeA: resize observer is a good place for that...
... was thinking of a case where you're trying to attach an element to another element like a tooltip
... but you end up with a 1 frame delay
rniwa: need to be mindful of not introducing n^2 layout
JakeA: resize observer seems to good a job about that
wanderview: there's been talk of 120hz displays. any ovelap with the dynamic framerate issues on the ipad?
... seems like a problem everyone will have
JakeA: I was complaining on twitter about it... is it really a problem? then they sent me one of my demos that showed the problem
smaug: if processing compositor stuff takes too much time... ??
<smaug> Hmm, my comment was reply to rniwa about FF possibly falling back to 30hz in some cases