<scribe> scribe: chaals
<beverloo> https://docs.google.com/presentation/d/14EFlm3VIDvE7WJnyEZKKQfY3S5wLF9nQM9SPVbqosqA/edit#slide=id.p
PB: update on progress…
... having a single push service intermediary helps reduce
battery usage, means the application doesn't need to identify
that service and can just trust it.
... there are web services using this.
... End-to-end encryption makes quite a barrier to adding
things. This has led to creating push aggregators - people who
will collect the information and distribute it.
... not so wide support for advanced notifications. Displaying
basic stuff is, but buttons, inlines images, etc, not so much.
We are getting there, but the API still could do with more
implemented interop.
... Path to Rec. The API itself is pretty old and stable, but a
couple of minor ideas for consideration.
... Only allows one subscription per service worker, so if your
connection drops between unsubscribe and resubscribe, you lose
the connection to the user.
... When you get a message, implementations require you to
notify the user. But browsers don't always do that, based on
heuristics about whether we think the user trusts that site. So
we should be able to tell the developer that the user wasn't
getting anything a notification.
... We would like to more this to CR in the next few weeks… so
now is a time to comment.
... Open non-blockers
... Push depends on servers and clients, and the clients depend
on external input, making it hard to develop a test
suite.
... Another issue is notification permission spam. Everyone
requests the permission,, and it is annoying.
... Trying to work out how we can reduce that, but ideas are
welcome.
LJW: You said you think we are good for CR in the next few weeks? For that we need to have the tests prepared - is that viable?
PB: We have various tests, what is coverable automatically is in WPT, there are also manual tests we have.
LJW: So we just need to add that manual test info to the automated report?
PB: Yes.
... Thank you.
MG: Spec gives metadata about
your website to help it be installable. Has names and icons and
stuff, defines an event to request being installed, …
... grab bag of stuff related to installing and running web
content as a desktop app.
<marcosc> https://github.com/w3c/manifest/wiki/TPAC-2018-Agenda
MG: Update on changes,
implementation status, ...
... Lots of progress on implementation. Was on Firefox/Chrome
for Android last year. Now we have it on various other Chromes,
Safari, and Bing is scanning sites and indexing them and you
can install them through the windows store. Samsung and Opera
have their own implementations too.
... the marketingese for sites with manifests is "PWA" - we
have seen big uptake in the last year.
... Big famous websites are doing it.
... We've made some breaking changes - some are not
implemented. We changed the default scope from that of the page
you got the manifest from to a root that is more stable. The
algo matches service worker
... when you get out of the scope, you should have browser UI
showing. We had said you cannot navigate outside the manifest,
but can open in a new tab. Implementations were following this,
but it is a bad idea - breaks the assumption of HTML that
top-level context is what gets navigated. So you couldn't do
authentication in a 3rd-party and then try to get back,
because now you're no longer in the app view.
... with separated browser instances, you couldn't do that at
all…
CMN: Doesn't that allow for phishing because you have the page in the app look just like you are in a third-party login situation?
MG: Yes. We recommend using
non-spoofable UI in addition, which we do in desktop but not on
Android. So you haven't got *exactly the same as native UI" but
close. We know it's an issue...
... The other change is an optional feature currently
unimplemented, called masking icons. Android now makes you put
icons in a little white circle. Or you provide a full bleed
rectangle and the system crops something out. So on that OS you
have to provide a full-bleed icon designed to be cropped in
arbitrary ways.
... we added a feature to provide a separate icon that meets
this use case.
... saying exactly which pixels might get cropped out. Want to
ensure developers still provide an icon that works on most
platforms.
... will have to see whether that gets picked up.
... To get to CR we need testing. We have almost nothing beyond
basic IDL. This stuff is hard to auto-test, involves different
user agent UI across browsers, no API to trigger an
autoinstall
... Looks like we will have to do a bunch of manual
testing.
... We looked for features at risk yesterday,
BeforeInstallPrompt has one implementation. ServiceWorker is
meant to let you declaratively register one - don't think it is
implemented anywhere.
MC: Idea was that synching two devices would enable you to automatically get a serviceworker, but it didn't get done.
MG: There are some things that
are for scrapers not browsers.
... We are expecting to leave stuff for a year and see what
happens.
... We rewrote to use WebIDL, but this is a JSON format not a
JS API.
MC: There are some feature
requests related top making things more like desktop UI
... discussion on back button, because inconsistent UI is odd.
Proposed a CSS query to find out, so you don't add a button
when there is one already.
MC: Doing test-driven development
means we have higher-quality specs, we can verify them, it
increases the likelihood of features happening. Would be good
to move toward a work mode where testing is a core part of the
specs we make. There are different things we can do - have a
template where you promise to test stuff, or you can insist on
a test before you merge a change…
... I would like the hardline policy, which leads to
high-quality specs.
<marcosc> https://github.com/w3c/payment-request/pull/749
MC: having it in the PR template
also helps us go back and find out where the tests are easily.
(We also flag implementor commitment in Web Payments)
... having a strong signal about implementation in whatever
space a spec gets implemented is very useful.
... Downsides: Sometimes we have a feature and we don't like it
and we wasted time on testing. But that effort helps figure out
what was wrong.
... There are PRs that are otherwise ready, but are waiting on
tests.
... We can fiddle around with the template to figure out what
you need for a given spec
TL: +1
CMN: +1
LJW: When you have something with manual and automated tests is there an easy way to handle that?
MC: Yes there is a
manual-test-result integration tool in WPT.
... We cannot currently tell wpt.fyi to run stuff behind
flags.
MG: We had a discussion with
implementors about how to notify breaking changes. That's why
we set up a template - we want to have a discussion with all
implementors
... it is hard to always get input from implementors.
CMN: It is hard to define all the implemntors, or get their attention. I hope at least the 4 browsers we typically talk to pay attention
AvK: I would not assume that. Reach out over email, IRC, or proactively file bugs and see what happens.
MC: There is no magic technique to do this.
LJW: We have Pubstatus where we
try to keep track of the things we are doing, a pile of Github
repos, and groups working on each of those things. There is
often not much cross-pollenation, we feel fragmented.
... Does anyone have better ideas about how to communicate
better?
MC: Instead of large-room
meetings, do more standup style updates.
... then go off and split into pieces to work intensely.
we have 4 days and web manifest gets 15 minutes.
scribe: then at the end we get together again and figure out what we achieved.
<mgiuca__> chaals: Yes, but... it's great that for some groups like Web Components, you had a small group. But some people may need to attend lots of these "unconference" meetings.
<mgiuca__> ... How are you going to make sure people can come to all the meetings they need to go to.
LJW: Who would have been torn between manifest, push.
<mgiuca__> chaals: Would need each group to make a F2F agenda, and stick to it.
<mgiuca__> ... So that people can attend the meetings when they are relevant.
TOC: I am the only person from my team in this room, and I prefer the linear model
[back and forth on benefits, mechanics…]
MG: If you work on a tiny spec you then have a risk of not getting any attention. Sometimes small specs should have a pleanary thing instead of a full unconference.
CMN: Yes. Likewise, we need to think about managing conflicts, but I think it would be goo to move in this directions.
LJ: W: We probably want a blend of approaches. SHould we make a strawman?
DM: How do I make sure the people I need to atlk to are available, and not in some other session working on some other important spec.
LJW: What do we do betgween now and next TPAC?
MC: Reduce the number of
specs.
... there are specs that haven't moved in 2 years, I think they
should go.
TOC: Would be helpful to have a Web components F2F in half a year again.
[+1 to tess]
LJW: Are there others who would be interested in F2F work?
[crickets]
[break]
mk: problem we are trying to write file and create file editors. So make possible to write/save, etc.
<dmurph> Explainer: https://github.com/WICG/writable-files/blob/master/EXPLAINER.md
mj: various attempts have been made at this in the past
mc: who else is interested in implementing this?
<ericwilligers> File handlers: https://github.com/ewilligers/file-handling/blob/master/explainer.md
mj: there are a bunch of different use cases that we try to address?
anne: what's the UX for this?
mj: file picker
anne: that doesn't seem acceptable
mk: we are still trying to work out the UX model
mk: the hard part is making this obvious for users.
<Zakim> annevk, you wanted to ask about UX
ew: we application should be able to register themselves to handle certain types of files
mj: what we were thinking is that when you try to write a file, you might show a file dialog
anne: so then you get to pick your same location?
mw: we need something for users to do this, but we still to work out the details
mc: we need to get a standards position from Mozilla
to: I don't know how mature the proposal is, so can't really comment
anne: we probably want to see this more fleshed out, e.g., using streams
mw: we have the file system API in Chrome, so it might be worth experimenting in that API.
ja: it would be useful for IDB for writing files
mk: we were not planning to mix the IDB and files
as: we have this something like this in gecko but we wnat to get rid of it
as: what's the security model around this?
mj: ...sandboxing...
m?: scoping this down to a single directory doesn't solve security problems.
mj: in MacOS there are permissions specific to where apps can write. We could learn from that.
a?: we have something similar in Windows with regards to permissions to where you can write.
mw: tehre are 3 separate use cases, one a web. There is a thing on a disk, but you get the representation on the website. And the third is you get a file from another webpage.
mg: this is not exactly web share target. I'd like to explore for the third use case, where a web page can edit a kind of virtual file that could be on disk or on another website.
<tomayac> s/tehre/there/
<mgiuca> https://github.com/chromium/ballista/ our (very old obsolete) plans around web-to-web two-way editing.
mw: the questions of persistence is relevant
tn: I'd like to get more interest from browser vendors. How can we do that?
to: we are interested to have a look when the proposal is more concrete
as: Mozilla wants the file reader to go away
anne: we should try to see which of these use cases we can do today over existing APIs
<annevk> new Response is great
<marcosc> http://github.com/mozilla/standards-positions/
<annevk> I'm not sure that got minuted correctly. What I meant was trying to add APIs for dealing with files without requiring new UX.
<marcosc> mc: what's the process for bringing new work item in?
<marcosc> mw: you should look at the scope of your charter and make sure that something like this would be naturally in scope.
<ericwilligers> https://wicg.github.io/web-share/level-2/
<mkwst> (Assuming, of course, that folks think this is a problem space the group ought to be interested in (which I think it is))
<marcosc> ehttps://wicg.github.io/web-share/level-2/#usage-examples
<marcosc> https://wicg.github.io/web-share/level-2/#usage-examples
<ericwilligers> https://wicg.github.io/web-share-target/
<marcosc> ....ew explains how it works....
<marcosc> ew: we are interested in sharing files. There is an implementation Chrome and there has been some implementation in Safari in Mac and iOS.
<marcosc> mc: there are two APIS - would it be worth combining them.
<marcosc> mg: we got back feedback from Mozilla that having share without share-target would not be acceptable to Mozilla
<marcosc> mg: the web share target doesn't make sense without web manifest. So it could be that web share target just becomes a thing that's defined as part of web manifest
<marcosc> mc: so there is some interest on from multiple browser vendors
<marcosc> to: sure, tho I don't have any particular feedback on the level 2 stuff.
<marcosc> mg: so I'm looking for interest to see if this should be part of the charter
<marcosc> mw: given the web share is in at least two implementation, it might be appropriate to make sure it's in scope. Graduating web share seems reasonable. But maybe target could use some more incubation.
<marcosc> mg: we plan to ship web share target soon. It's been in Canary for 6 months for the purpose of testing?
<marcosc> mc: have you had feedback from twitter?
<marcosc> ew: they are keen for us to ship it
<marcosc> ty: in Windows, they support a very similar mechanism.
<marcosc> aa: the proposal seems reasonable.
<mkwst> (Ali Alabbas from Microsoft)
<marcosc> mc: we should go back to Mozilla's standards position.
<marcosc> db: we should look at how it overlaps with registerContentHandler()
<mgiuca> https://github.com/WICG/badging
<marcosc> explainer https://github.com/WICG/badging/blob/master/explainer.md
<marcosc> mg: show indicators in icons
<marcosc> mg: on installed PWAs
<marcosc> to: why doesn't this apply to tabs in general?
<marcosc> mg: slightly different - this is supposed to be application level. So it wouldn't work for a web app that doesn't have multiple tabs open that wants to display things numbers per tab.
<marcosc> to: I think it would be weird if they were different APIs.
<marcosc> mg: just want to point out that they are slightly different.
<marcosc> anne: it could be at the origin level
<marcosc> cross talk
<marcosc> mg: we could make a distinction between OS app level and tab level
<marcosc> ...continued explanation of the API in the explainer... simple API with set() and clear(), with string or number
<marcosc> to: what kind of data can you set it to?
<marcosc> mg: trying to restrict it to what platforms support. There is a question around if this should tied to notifications. But we don't want it to be tied to having to call the API over and over to represent the number to be shown.
<marcosc> to: if you are not intended for this to work on Android, why are you planning to work on thiss?
<marcosc> mg: for desktop
<marcosc> to: I would not be interested in different API that would work on both mobile and one on desktop
<marcosc> mg: on Android there is just no way to show a badge. But that's a limitation of that particular OS.
<marcosc> mg: so it would only be set on platforms where it would be supported.
<marcosc> dd: would this work on iOS?
<marcosc> to: I don't think this is deficiency on Android. For notifications, we looked at the cross section of supported things across platforms.
<marcosc> anne: it would be annoying if for a particular use case, twitter had to send notifications to make this work.
<marcosc> anne: for iOS, I don't get notifications, but I do get updated badge numbers
<marcosc> mg: yes, this is what iOS does - it sets the badge number
<marcosc> anne: is there OSs that take a string
<marcosc> mg: on MacOS it does support a string
<marcosc> mg: on windows 10, you can set a specific set of icons for the badge ... I don't want to bake that into the spec, but just for example
<marcosc> anne: there could be potential problems with emojies
<annevk> Please restrict it to secure contexts
<marcosc> to: I really like the use case, but I need to review the design.
<marcosc> to: I think it's a good idea in general
<marcosc> to: it would nice to do it with no script
<marcosc> to: e.g., a declarative push message
<marcosc> pb: there might be race issues with that ... we have looked at that with notifications
<marcosc> mg: the proposal says that the use agent can reset the state
<marcosc> ja: I worry that if you can read it and set it could become racy
<marcosc> mc: one of use will file a Mozilla standards position
<annevk> mgiuca: I also kinda wonder if we shouldn't just stick it on Notification or some such to avoid yet another global
<annevk> mgiuca: or navigator.setBadge
<ada> +present
<dmurph> preset+
<marcosc> ada: WebXR has an interest in Gamepad API
<tink> Zakim: /me If you haven't already, please present+ yourself to be recorded as present.
<marcosc> sa: we've like to get to a 1.0 spec. We'd like to talk about current open issues. And if we have time, do a little demo in Chromium
<marcosc> ... presentation ....
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/MC Marcos/Test-driven development/ Succeeded: s/beforeInstall/BeforeInstallPrompt/ Succeeded: s/employee of Apple/person from my team/ Succeeded: s/mj/mk/ FAILED: s/tehre/there// Succeeded: s/m?/tn/ Succeeded: s/not have share and target/having share without share-target/ Succeeded: s/a?/aa/ Succeeded: s/general/general?/ Succeeded: s/pt/pb/ Present: (tink) Ali_Alabbas Daniel_Murphy Eric_Willigers Fuqiao Giuca Hayato Ito Jake_Is_Hungover Kenneth Léonie Marijn Marijn_Kruisselbrink Matt Olli-Smaug Peter_Beverloo Tess Tomek Tomek_Wytrebowicz Travis Vladimir_Levin Yves bkardell_ chaals dbaron hober marcosc surma tomayac xfq edent cwilso garykac ada david_clarke plinss dmurph jihye jungkees Laszlo_Gombos Found Scribe: chaals Inferring ScribeNick: chaals Agenda: https://github.com/w3c/webplatformwg/issues/120 WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]