WebApps WG F2F

28 Oct 2014


See also: IRC log


Brian_Raymor, Art_Barstow, Josh_Soref, chaals, Yves_Lafon, Ben_Peters, Xiaoqian_Wu, Adrian_Bateman, Ali_Alabbas, Mohammed, Dadas, Sam_Weinig, Hiroyuki_Aizu, Shijun_Sun, Sakari_Poussa, Alan_Iida, dom, Kenneth_Christiansen, Jonas_Sicking, Olli_Pettay, Laszlo_Gombos, Israel_Hilerio, Wooglae_Kim, Claes_Nilsson, igarashi, Anssi_Kostiainen, Jungkee_Song, Robin_Berjon, Benjamin_Poulain, Bryan_Sullivan, Dan_Appelquist, Ted_Oconnor, Joerg_Heuer, Marcos_Caceres, Mounir_Lamouri, Sam_Ruby, Stephan_Steglich, Travis_Leithead, Kevin_Hill, miterho, Mikko, Terho, Huawei, Mark_Nottingham, Larry_Masinter, Peter_Linss, Phillipe_LeHegaret, Paul_Cotton, Mike_Smith, Alex_Russel, James_Craig, Michael_Cooper, Richard_Schwerdtfeger, Katie_Haritos-Shea, Janina_Sajka, Norbert_Lindenberg
ArtB, chaals
timeless, Travis, Travis_


<timeless> scribe: timeless

<ArtB> ScribeNick: timeless


chaals: good morning
... We'll wait until 9:30 until we start our first item
... as we traditionally do, we'll go around the room asking people to introduce themselves
... I'm chaals, from Yandex, co-chair of this group

ArtB: Arthur, I work for Nokia
... i'm also one of the chairs

Josh_Soref: Josh Soref, BlackBerry, Scribe, Observer

spoussa: Sakari Poussa, Intel

kenneth_: Kenneth Christiansen, Intel

weinig: Sam Weinig, Apple

<dka> ‘ello

benjamp: Ben Peters, Microsoft

sicking: Jonas Sicking, Mozilla

ShijunS: Shijun Sun, Microsoft

alan-i: Ali, Microsoft

xiaoqian: Xiao, W3 Team Contact

Yves: Yves, W3C

a12u: XXX,

<jcdufourd> jcdufourd: Jean-Claude Dufourd, Institut Mines Telecom, observer

<Louay> Louay Bassbouss

StephanSteglcih: Stephan Steglich, Fraunhofer Fokus, observer

<Dong-Young> Dong-Young Lee (LG)

youngwoojo: youngwoojo, LGE, Observer

<bryan> bryan: Bryan Sullivan

Bill Hsiung, MSTAR Semiconductor,

<alia> s/alia: Alan/alia: Ali

richt: Rich Tibbet, Opera

shoko: Shoko Okuma, Tomo-Digi Corporation, Observer





DDD: France Telecom, Obs


<Evangelos> Evangelos Vlachogiannis Fraunhofer FIT, observer

FFF: Observer

GGG: Observer


Mohammed Dadas Orange

<GeunHyung> GeunHyung Kim



LLL: Japan, Observer

<bryan> s/PPP PPZ/ Bill Hsiung, MSTAR Semiconductor

MMM: Oracle

marcosc_: Marcos Caseras, Mozilla



XXX Observer

dom: Dominique, W3C

EWQ Softbank





Xitong Huang Tencent

<dka> Dan Appelquist: dka, @torgo; WebApps wg member; TAG Co-Chair; URL fan; #FirefoxOS fanboy; also A.C. rep for Telefónica.

<adrianba> Adrian Bateman, Microsoft

dka: Dan Appelquist

adrianba: Adrian, Microsoft



[ Scribe apologizes ]

smaug: Olli Pettay, Mozilla

lgombos: Laszlo Gombos, Samsung

<inserted> anssik: Anssi Kostiainen, Intel

<inserted> rubys: Sam Ruby, Apple


ArtB: we were considering talking with sysapps

marcosc_: let's get it out of the way
... what APIs can be salvaged from SysApps
... brought over to this group

ArtB: put that in at 1pm
... look around for wonsuk
... could one of you send an email to public-sysapps

mounir: marcosc_ would be glad to do that

ArtB: 1-1:30pm

mounir: Permissions API ?
... after the break at 11am?

chaals: yeah...
... anything else for the agenda?
... we could start on Screen Orientation

Screen Orientation

mounir: we just finished a new WD

<ArtB> Screen Orientation ED

mounir: we failed to go to LC
... it's now shipping in Chrome (including for Android)
... i'm not sure if Mozilla will update

<ArtB> Screen Orientation Open Issues

mounir: there are two prefixed implementations
... one from Mozilla, one from Microsoft
... also Tizen has an unprefixed outdated implementation

chaals: marcosc_?

mounir: wrt Open Issues
... the real outstanding one is Animation Frame Task
... it's why we didn't go to LC
... my opinion is that it isn't important
... I think sicking would agree

<ArtB> Issue 40 Use animation frame task

mounir: the problem is that Animation Frame isn't defined anywhere
... we're stalling the spec for something that might not be defined for two years

marcosc_: i was going to echo what he said
... from my perspective, it [the spec], is pretty much done

weinig: can you give us an overview
... i know the security restrictions is a bit vague
... it allows for essentially anything
... do you have an overview of what people have done
... i know that's one of the things that of concern to us

mounir: the spec is vague for that reason
... we want UAs to have their own security decisions on top
... full screen is something on top
... we said that it's optional to require Fullscreen
... this is how Chrome Android behaves on KitKat
... if you have no browser ui, fullscreen is not a requirement

weinig: to be clear,my concern is that the spec does not define that
... and makes it optional
... it defines many ways to do this
... but someone to use this won't know what it will do
... Why did you make it a MAY in the first place?

mounir: we have two different scenarios in Chrome Android
... if you fullscreen, you might not have browser ui
... you're more maximized
... we couldn't require fullscreen

weinig: i'm not sure a UC for a non-browser scenario...

mounir: on the latest Android, Chrome Tabs behave like activities
... it's ok for a tab to change screen orientation
... and any app can lock screen orientation
... in that case, it's ok for an app to lock screen orientation
... we could make it a stronger recommendation
... assuming cases where it isn't required seems
... but a MUST sounds inappropriate

weinig: I disagree
... especially for a security requirement
... taking control of pieces of the browser UI
... that the user thought the user controlled
... and making it less clear
... makes it easy to fishable

sicking: w/ Safari on iOS, the urlbar scrolls away

weinig: that's true, you can get rid of the urlbar
... but you can't control screen orientation

sicking: why is that a security issue

weinig: it increases the ability to phish
... mocking OS UI

mounir: can't you mock this w/o ?

weinig: i haven't seen a good example of that
... but if so, i don't see why to lock to fullscreen

mounir: the reason to lock to fullscreen is for "annoyance"
... it makes a certain amount of user interaction first
... the other bit is chrome UI
... if you change tabs, and everything starts switching, that's problematic
... but once tabs start behaving like apps, it's more ok
... we're not doing that for security, but mostly for UI and annoyance

weinig: we should probably change the term from Security to Something Else

chaals: not probably, but yes
... annoying people is bad design
... the example w/ phish is that you put a 90 degree rotated browser

weinig: I take their example
... that you could detect rotation and

chaals: i agree that you don't need the MUST

weinig: i wouldn't go that far

marcosc: I'm recording an issue on this now

kenneth_: is it possible for users/something to suppress this?

mounir: that's what we do on Chrome Desktop

kenneth_: should that be a MUST?

mounir: the lock request would fail if that happens
... I don't know how to make it a must
... you have the problem of tablets/laptops
... you might imagine that a tablet could lock screen
... but once you dock, it isn't ok

kenneth_: i was just wondering
... in chrome, you can go back in history
... if i do that and orientation changes, that's confusing

<marcosc> filed: https://github.com/w3c/screen-orientation/issues/82

kenneth_: [Back action]
... I was on a locked orientation page
... I transition to a page that doesn't have a locked orientation
... and then I click back

mounir: doesn't that happen on mobile already?

kenneth_: that's what I'm talking about when i click on browser chrome

mounir: that's why we don't want it for non fullscreen
... i don't know if it's the role of a spec to make a mandate

sicking: in all mobile platforms
... there are things where you bookmark a homepage
... it opens a page in minimal/no chrome
... in that scenario there's no reason not to allow it
... but in some cases there's some chrome
... it can be annoying in that situation
... but in FirefoxOS, we decided if a user moves to the homescreen, the user trusts it
... and allow them to fullscreen/orient

<ArtB> New Screen Orientation issue based on Sam's feedback

chaals: Mozilla, any plans

sicking: yes

chaals: Microsoft?

adrianba: I imagine we'll snap to the spec when we get around to it
... i don't know when

marcosc: our concern
... we've changed the spec significantly
... if that's ok with you guys

chaals: weinig, you expressed concern - do you want to give any more detailed info here?

weinig: we'll give a more detailed response to the spec in email

marcosc: mounir said it's already in chrome
... we'll want to update soon
... early feedback is always better

weinig: obviously

chaals: ArtB wants to know when we're going to LC
... and you have to restart LC if you have issues
... unless we do the new process

[ chaals is plugging Process-2014]

weinig: we understand you want to move it
... we'll give feedback soon

chaals: any more comments/questions?

[ Silence ]


<marcosc> https://github.com/w3c/manifest/issues

<ArtB> Manifest ED

marcosc: manifest is moving along
... we're doing it in two phases
... not formally, but...
... a simple v1
... to see what would be needed
... this has since shipped in Chrome Beta on Android
... and I'm implementing the spec in Gecko
... with intent to have it in FirefoxOS at some point
... the spec has
... issues
... there aren't many open issues
... mostly feature requests
... it's really simple
... the biggest aspect, are issues in v2
... we need discussion about
... "what is a web application"
... "what is the scope of a web application"
... in url space, "what is the scope of a web application"
... how does that work with service workers
... also in coordination w/ WebAppSec WG
... where can i load the app from, where can I load icons from
... no major issues
... discussions on github page
... everyone's happy
... questions, comments?

<Zakim> chaals, you wanted to feature creep

chaals: we regard the inability to internationalize to be an issue, not a feature
... issue #208 / issue #211

marcosc: the issues are there
... we're discussing various models
... the approach we're taking
... we need to look at how apps are made today
... you don't have internationalized html elements

<ArtB> Manifest Issue 208

marcosc: you don't have a paragraph in english, and then a paragraph in japanse

<ArtB> Manifest Issue 211

marcosc: a question of a single page / one for each language
... that's the problem space for the

kenneth_: the server could return different answers

marcosc: html doesn't do that (multiple languages in a single document)

mounir: manifest v1 goal was feature parity with add-to-homescreen that all browsers were doing
... nearly every mobile platform supported in their own ways

<scribe> ... new meta tags

UNKNOWN_SPEAKER: that was a mess
... feature parity was the most important goal
... i18n would be the most important next step
... i think we should do that now
... we should iterate from here, instead of the best solution that will never happen in the next decade

chaals: i don't think we need to aim for the perfect solution
... we should aim for problematic
... doing as badly as you can do in html isn't a goal

<Zakim> chaals, you wanted to feature creep

chaals: another thing that is feature creep
... is a source for updated tags
... in Tableaux, in Yandex, open your screen and get your favorite sites
... you can put your text label
... the widget will go and fetch some data
... update the number of email messages

[ examples ]

chaals: this feature is quite common in places

marcosc: Speed Dial?

chaals: yes
... being able to do that so your application icon shows how many waiting emails

[ ... or missed phonecalls ]

chaals: url spits back a bit of json
... Opera has something similar
... we'd like to add that
... we'd be happy if you took our api

marcosc: file a feature request
... we can discuss it

Josh: Sounded like someone said they didn't see a particular need to have all languages handy, but I did a demo where I asked you to switch, and you may have gone offline. The usecase of switching language offline isn't so unlikely

marcosc: we don't have data about how often this happens
... it might be rare or common
... i don't know

mounir: i doubt it's common

kenneth_: same problem w/ service worker
... i remember working in Gnome Desktop
... we added i18n
... .desktop files
... it became a problem w/ loading
... it needs to be separate files

mounir: isn't there something for json-imports?

Claes: we had a discussion on the CSP field
... trying to understand how it works
... if I want to specify CSP per CSP spec
... can i do that in Manifest?

marcosc: you can, not today
... we have a separate spec, we're hoping to fold

<ArtB> Content Security Policy

marcosc: you can see Example.com has a CSP policy, and that controls where the manifest is loaded from

<kenneth_> http://w3c.github.io/manifest-csp

marcosc: where you can get your icons from
... and where you can load your manifest from
... we're adding,
... a spec anssik is working on
... to add a csp added to the origin/html file
... so you can tighten the policy of the html document

Claes: i don't see that here

[ Link dropped by kenneth_ ]

[ marcosc reads 1.1 Example 1 ]

marcosc: you can have one from http, one from meta
... then also from here

Claes: thanks

marcosc: for people interested in the spec
... should we fold this into the spec proper?
... we can do this for FirefoxOS

kenneth_: for this, we need to fix the URL scope

marcosc: yeah
... right now it would apply to just start-url

mounir: don't you have issues
... where manifest is not loaded, and then this won't apply?

marcosc: yes
... primary case is
... but yeah, we need to solve that
... primary case was for packaged apps
... not super ideal
... it's why it's sitting outside
... the main UC is packaged
... we need to consider those UCs more fully
... PhoneGap uses this

[ Cordova ]

mounir: if we have more and more of this
... this CSP thing
... it only works if you load the webapp from the manifest
... in a packaged web app scenario
... or FirefoxOS
... but in normal web browsing scenario
... but the spec is clear that you don't need the manifest
... it has to be done lazily
... which means the CSP rules aren't active
... but if we have more UCs for eager loading of Manifest
... maybe we could make it happen

marcosc: we've been very careful to not put Manifest on the critical path for performance reasons

chaals: to kenneth_, we understand that for i18n, you could have horrible things
... we have bilingual markets
... Khazakhstan/Ukraine
... .ua, it would have Khazakh and Russian

marcosc: how does user today select preferred language?

chaals: button on page

marcosc: why not rewrite the page/url then?
... this is part of a lazy load
... by that point you've made your decision

kenneth_: maybe we should have spec text

marcosc: curious case of dynamically changing
... if you kicked off a manifest load
... and you change your link-rel
... maybe you need to cancel the manifest and get a new one

<ArtB> The curious case of the vanishing\mutating link element

marcosc: I agree, but there are signals from user to web app
... we have pressure from Mozilla
... need to consider UCs

kenneth_: would it help to have base manifest + per language manifest?

chaals: sort of a pain in the butt
... one model in the issue is a fairly lightweight approach
... names+icons

<darobin> --- HTML 5 is a REC --- :)

chaals: lazily do it
... do it only for locales
... having to do this as 2 lines is better than 6
... but thousands of lines will be bad

marcosc: requests i have is scope creep
... but then define languages the app supports
... then the data isn't complete
... what does it mean

chaals: you don't need to list them, just look through the JSON
... i'm arguing for a dual model
... we have yandex.ua, yandex.kz, yandex.ru
... they have the appropriate languages for those locales built in
... we probably wouldn't include Turkish in the Ukrainian Manifest

kenneth_: can't you just generate the manifest?

sicking: i agree there's a need to be able to upload multiple languages in the same thing
... i don't think we should solve client side localization for the web
... in it
... Mozilla has done complicated localization investigation
... Plural
... Gender
... 2, 3 count
... this becomes very hairy
... we've researched for years
... we've done localization for manifest
... i don't know if it's used at all
... it's so lacking in capabilities

mounir: why do you need that if you're just localizing the title
... i assume it's just the fields in the app title

chaals: name and icon
... no need for count/gender
... marcosc says "please don't use the clunky FirefoxOS model"
... i'm sympathetic to "let's not create the ultimate client localization thing in manifest"

sicking: is it worth doing something really crappy
... i'd rather people work on how to do client side localization
... i don't see w3c working on it
... i'd love someone to do it

chaals: action sicking to write it up?

[ laughter ]

Kevin_Hill: for l10n discussion
... I'd hate to see localizing the app
... i could see localizing Offline
... and basic fields

chaals: absolutely
... i don't think anyone is suggesting that
... other things you want feedback on?
... or other feedback people want to give you?

marcosc: we need to
... what we have here
... doesn't let you define
... all the things you need to make a web app you can take offline
... / install locally
... we need to have that discussion
... we need the right people in the room
... we need to work out scope issue
... -- the biggest blocker
... how it relates to ServiceWorkers (SW)
... it lets you relate to homescreen
... the bits that are there, it's pretty cool
... Chrome/FirefoxOS

mounir: the next big thing is Scope/SW Scope
... we need Manifest and SW define Scopes [compatibly]
... maybe Manifest defines Scope and SW uses it

chaals: i agree modular i18n, it's nice/small/handy
... let's try to get it shipped
... before we boil the ocean
... we can do that in v1.1

marcosc: we need to have these discussions
... come talk to us this week
... we have time

chaals: i'd invite you to talk to those guys directly
... on our side, they're in Russia and Ukraine

marcosc: i put some ideas

<jhund> just added my comments on loc to https://github.com/w3c/manifest/issues/211

marcosc: worth having a look at that

chaals: any more on this?

Permissions API

[ Break until 11am ]

[ chaals searches for a Chair ... since everyone with Chair experience is going to the AC meeting ]

chaals: ok, marcosc will chair

<Travis> scribe: Travis

<scribe> scribeNick: Travis

<mounir> http://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0389.html

mounir: It is very simple.
... whether to know if a site has access to a specific permission.
... [describes the API shape]
... Many API defintions require permission and try to abstract the permissions--creates a poor user experience.
... many developers will try to find workarounds.
... WebRTC is an example.
... Abstracting permission status for website worked well when sites used new features but not often.
... now it's more common. Cite: hangouts needs WebRTC (it's required)
... Issues: Should we have a specific permissions API or add permissions to every API that needs it.

richt: If I've never been to the site, I don't know if I have permission (obviously).
... if I just store something like a cookie, why isn't that sufficient?

mounir: That seems hacky.
... There could be an issue if you inject ads.
... They could just use your permission if they find your cookie. It's a security issue.

richt: This can be solved...

mounir: you inject a script in your own origin. If you put your token in local storage they can just read it.

richt: any idea on how to solve the security issue.

marcosc: well, you know the effective script origin... you could block it.
... on iOS it tells you if some app is using something in the background--you can detect and control it.
... You could move it to the server, or try to prevent on the client.

richt: in GUM, I could just set a flag and read it when I come back...

marcosc: You should be able to clear permissions separately from cookies, etc.

mounir: Cookies is not really the right solution to the problem.
... another solution is to sandbox the ad-injection.

marcosc: We talked a bit about use-cases. Was there an idea about being able to group permissions?
... example: I need geo and camera access. How does that work.


mounir: something that is planned: permissionchanged event.
... there was a sec permission meeting in paris: they discussed this API
... in WebRTC context, you don't have camera, but do have mic.
... camera icon could be enabled/disabled based on permission status.
... as soon as you are allowed to read permission status, you are allowed to track it.
... Any implementer feedback?

sicking: I think this looks good

marcosc: any concern about this?

sicking: no. It's syntax. It doesn't really matter where it lives.

ShijunS: Suggest take topic to WebRTC meeting for feedback
... there is no "middle" layer in WebRTC

sicking: Well, that doesn't change anything...
... site could add nav.permission.has('camera') and it would know whether it would succeed or not.
... many sites want to be aware before the implementation would throw a permission prompt to the user.

ShijunS: Scenario: visit a page, then navigate back. It doesn't necessarily mean the user wants to automatically grant permission.

marcosc: What would you folks like to see? More than what we have here?

ShijunS: Can work through offline before talking to WebRTC.

mounir: I will circulate more widely. Web Apps may not take this (scope question). Perhaps it will go to webappsec?

??: Would it apply to packaged apps?

mounir: packaged apps may be out-of-scope.

sicking: I see no reason why it wouldn't work. You can use this to ask for permission, just to check for position.

mounir: depends on how your packaged apps work. Perhaps you don't want to allow this for your packaged apps.

richt: Let's say I ask, and get a 'denied'. Now my app has to tell the user how enable permission (there's no way to be re-prompted)

marcosc: If you could re-request it, that might work...

mounir: Our data shows that people that deny really mean it. Otherwise they ignore it.
... In many browsers, there's a third option (just ignore it)

richt: I'm talking about the iOS shortcut into the apps permission settings.

mounir: If you say no, it means no/never. This is a UA specific problem (about UX)
... I expect it will change in the future.

richt: My point is that its very hard to undo a permission reject.

adrianba: I agree with Rich. I think that this is a problem.
... If I visit a site, and wasn't expecting a prompt and now I click on no-never, then I'm stuck.
... another example: facebook asking for location. But then I change my mind... how do I (as the developer) do that?
... Does the app do the query?
... Does the app have to have a database of the 1000's of mobile devices and show the user how to disable/enable.
... Perhaps a time-based model--if you just asked 5 minutes ago, don't re-prompt, if its been a year, maybe re-ask.
... the point of the API is to not show he prompt if its rejected. There's nothing for the UA to do here.

sicking: I also agree that this is a problem--not necessarily with this API. It's not in the 'has' request--it's in the asking (say in Geoloc.)

<npdoty_> sicking proposes iReallyReallyMeanIt parameter

mounir: I think Ade meant that with this API folks wouldn't even bother asking. Whereas before they might ask again because they wouldn't know.
... I think we may be able to solve that problem later.

richt: 1st step: accept that there is a problem

mounir: Agree, it is a problem. I don't know the # of people who deny, but I think it's soo low, it's practically no one.
... Basically, there's just one guy who presses deny.
... it's not an even distribution.

richt: I also have some data (it's different than your data)

mounir: 90% of folks are saying "i don't know"
... adding something to Geolocation for "I really really need this permission"--> then everyone will use that!
... now my problem is explaining how to undo that.
... it would be great if users could access the permissions to review/change the permissions.
... rather than having each UA explain the process.
... I think it's a bad idea to have a way to access Chrome settings.

adrianba: I agree we don't have to do this immediately.
... Like Jonas' point, it's interesting to have the 'no I really need it' that could be called after a deny.
... and if you did have such a centralized method, what would it do? Maybe taking the user to the settings would be OK?

mounir: The 'i really mean it' means that they would ask for permission after they were denied, right? Seems not very useful at that point, because you have to trust the website...

sicking: You could treat the has() to a call to the underlying API...

Kevin_Hill: I'm probably that one guy clicking deny.

<npdoty> if we treat has() as a call to the API, that sounds a lot like the current situation (with geolocation at least), and has some advantages

Kevin_Hill: If the site says it can't provide the experience.
... The time factor is pretty important.
... It's not a yes/no decision for all time.

mounir: I don't think the API is going against that. It's a decision the browser has to make for its user.

Joannes: If I denied something, maybe I just want to be reminded that I denied and want to be reminded.

<npdoty> that's often how popup blockers work

richt: Lots of browsers do provide that... icon next to the URL--but browsers all do this differently.
... would be nice to point the user to the same place across devices. Can be done in a couple of clicks.

npdoty: Came late... treating the has() call to a call to the underlying API.
... current way this is done: by calling the geolocation directly and getting a callback. It's easier for the UA to decide based on heuristics.
... at least for a while on iOS/Safari, it wouldn't deny forever; at least for 24 hours.
... Another advantage: it requires some cost. It may have to show something to the user.
... if you could determine whether someone else had asked, you could avoid the call. Many sites are conscious about being the source of a permission prompt.

marcosc: We could track the effective origin of the call to the permission access and make a decision based on that.

npdoty: It's been hard to do that tainting.
... It's hard to be sure.

marcosc: next steps?

mounir: I started writing an official draft; not done yet, but soon.
... need implemation feedback. We have some security issues. Clear Apple is not supporting.

<npdoty> mounir: because an embedded script can create a new script element on the page, and that script element will have the effective origin of the host page

mounir: in Chrome we are interested in implementing by EOY, but not shipping. We want something experimental and to know if it can ship next year.
... Finding a home for this is important. Probably webappsec. DAP also volunteered to host.

<Zakim> npdoty, you wanted to remind about use cases

npdoty: If we could document the use cases (a concise list) of things we want to fix, and perhaps we can explore an alternate proposal? Seems like DAP had a permission spec a while ago...

<lgombos> link to DAP spec that i also helped to edit - http://dev.w3.org/2009/dap/perms/FeaturePermissions.html

mounir: Not a big fan of solving use cases one-by-one. Will create a mess.
... we should definitely solve privacy issues.

npdoty: [not an expert] effective script origin is hard.

mounir: The origin-mixing problem just makes it very hard to safely ask permissions.

marcosc: The tracking may not be a bad practice for some sites...they may want to collect this data!

<npdoty> yes, I would like if we could move away from ever embedding scripts from another origin in the same browsing context, but I think we're a long, long way from that

marcosc: The assumption that the web will be locked down by CSP may contradict some business goals.

<npdoty> that there are other security issues currently is not a reason to ignore new privacy/security issues we might introduce.

marcosc: Any final thoughts/comments?
... no?
... that's a wrap.

<Yves> lunch break

<ArtB> scribenick: ArtB

SysApps specifications

-> http://www.w3.org/2012/sysapps/#roadmap SysApps Spec Roadmap

AB: this is informational session re SysApps WG

MC: my personal observation is that most of SysApps specs are not progressing very well

… the group is starting the process of rechartering

… Mozilla is thinking about if it still wants to be part of SysApps

… We see value in at least 2 of SysApps' APIS

… Task Scheduler and TCP UDP Sockets

… We would like to test the water, so to speak, to see if these could fit into WebApps' charter

ML: I agree with Marcos

… there is also Background Sync on GH

… I don't think that is within a WG yet

… but it is something to consider too

… so those 3 specs

JS: think Scheduler is a good fit

… not sure about Task Scheduler

… uses a security model that is not consistent with the Web

… thus I think that will be problematic

LG: Samsung is editor of Task Scheduler

… we recently made some updates

… part of the lack of progress is the Service Worker dependency

… but that is becoming resolved

… so I think Task Scheduler can now progress

… want it to progress regardless of where the spec "live"

… would like to get more feedback

AB: perhaps someone from SysApps can ask WebApps to review the specs?

CN: re the TCP UDP Sockets spec

… this API can't be exposed to any web site because of sensitivity

… the sec model can't be solved here

<anssik> http://www.w3.org/2012/sysapps/tcp-udp-sockets/#security-and-privacy-considerations

… hosted web app sec model needs work

… to reuse the Web's security model

… re the API itself, provides interfaces to UDP and TCP sockets

… within the last month I have re-written the spec to use WHATWG's Streams spec

… the API is now mostly complete

… still needs work on secure Web sockets

… need to also add support for TLS

SP: we have implemented quite a few of SysApps' specs

… mostly experimental in Tizen but also some Android versions too

… App URI implemented by us

MC: if we have >=2 impls, then by all means we should move them forward

… but if we don't should drop them

… we need to discuss this in SysApps

… for App URI the test suite is complete

CL: re SysApps deliverables, there is a Phase 1 list and a Phase 2 list

… high on the priority list is Media Storage

… we are implementing it on Chromium Android

… will ask SysApps this week to take that on

ML: during SysApps' meeting, a topic is what could be moved to WebApps

MS: I don't think Media Storage is web safe

… I think the only specs that could move to WebApps are those specs that use Web security model

… SysApps' original charter assumes Adam Barth was going to write Security Model spec for these classes of apps and a Runtime spec

… that didn't happen and isn't going to happen

<spoussa_> q

… therefore, these specs would need to be refactored to fit into the Web sec model

… don't think we want to WGs specifying Web APIs

JS: the Sockets API isn't clear how to expose to Web apps

… we learned alot, v-a-v FirefoxOS re runtime sec models

<Zakim> MikeSmith, you wanted to comment

… want to make things as Web like as possible with only minor changes

… f.ex. some events

… We don't want and diffs

… My hope is that what Adam had envisoned isn't actually needed

MS: unless there is a compelling reason, think all Web APIS should be moved to WebApps
... SysApps wants to drop specs

MC: for all specs with 2 or more impls, we want those to advance

AK: I want to poll people at the meeting about moving more experimental work back to the incubation phase

… WG is not appropriate place for incubation

… Is there interest in moving some of SysApps' specs in a less formal setting

… f.ex. a Comm Group

MC: that's already happening with Bluetooth

AK: true; but what about some others and is a new CG the best way

… if/when SysApps closes, useful bits should be redirected

MC: I think that should happen by market pressure

… don't want to create a CG unless there is some critical mass to move a spec forward

… that's what's happening with BT CG

AK: there could be some other specs to move

… and advance them

… if something has already been published, an issue is how to relicense the spec

… Chairs need to start discussions about those

MC: we also need to get Legal advice

ML: Chairs are OK to do that

AK: want to get the widest participation

… Manifest was one that already moved to WebApps

… Could be some other candidates

… f.ex. Raw sockets and Task Scheduler could go the same way

<Zakim> anssik, you wanted to gauge interest in moving some of the experimental SysApps work (that do not fit into WebApps' scope) back to the incubation phase into a "SysApps Community

LG: we should not speculate here what SysApps will do

… but would be good to get some WebApps feedback

AB: seems like SysApps should decide what it wants to move forward and then ask WebApps about their interest in taking them

LG: that sounds fine

<dka> Intersting URL Factoid

<dka> Will.i.am’s name is also a URL.

<dka> In the future, all names will also be URLs.

<dka> So we’d better get this right.

<rubys> https://tools.ietf.org/html/draft-ietf-appsawg-uri-scheme-reg-04


<Travis> scribe: Travis

<scribe> ScribeNick: travis

<scribe> scribeNick: Travis

<ArtB> Scribe+ ArtB, Travis

MikeSmith: We are gathered here together... to talk URL
... There was objection that URLs were being specified in HTML.

<dka> @brkadell_ looks like it’s just http.

MikeSmith: Adam Barth wrote a draft in IETF then lost interest.

<ArtB> WHAT WG URL spec

MikeSmith: Larry become interested in an update to IRI
... it was rechartered. They didn't make much progress [ correction] "nothing was done" (by me)
... We still needed a spec for URLs.
... Anne went ahead and wrote a spec for URLs
... And now we're done.
... Ok. Maybe not.
... Some folks aren't happy with Anne's spec.
... Suggested we create a spec that we can be happy with.
... rubys is taking a closer look at test results of URLs

rubys: Will be pasting some links

<rubys> https://url.spec.whatwg.org/#url-writing

rubys: This is the living standard. A scheme must be registered... (not done)

<dka> relevant to the discussion, a TAG resolution taken on 1-october of this year on this topic: “We welcome present and future moves of the WHATWG to move toward a process which adheres to the openstand principles, and we note that in the case of URL spec, there has been a lot of cross talk, input from other groups, and a Bugzilla and GitHub-based process allows an openness to input which is valuable. In principle there is no barrier to W3C documents referencing WHATWG

<dka> documents normatively. In the specific case of URL being referenced from HTML5, we would prefer that the W3C HTML5 spec should reference the WHATWG URL specification and that between W3C and WHATWG we should continue to resolve any remaining technical and editorial issues in the spec.”

<rubys> https://tools.ietf.org/html/draft-ietf-appsawg-uri-scheme-reg-04

rubys: It is obvious that more work needs to be done.
... This defines how you register new things. It references the work being done in URL and vice-versa.
... Seems like they could link to one another. Progress?

Larry: Timing is right to review this new process document.
... goal is to make it easier.
... There is provisional and permanent.
... Permanent is expert reivew

<ArtB> Guidelines and Registration Procedures for URI Schemes

<ArtB> draft-ietf-appsawg-uri-scheme-reg-04

Larry: Provision is more lenient
... Time is right to look this over and review.

markN: We talked about this back in London.
... It appears a unanimous decision was not to have competing specs in WHATWG and W3C.
... Way forward was to use W3C process to move forward.

Dan: Resolution is specifically about URL and for this case.
... It's being developed with good intentions by Anne.
... We were happy to recommend the reference to the WHATWG spec.
... I take issue with the W3C spec as a copy. I see it as a reprint.

marcosc: Director makes a decision and was part of the decision.

<Yves> not using his director's hat

rubys: I'm not interested in that discussion. I'm interested in the technical work.
... I do want an opportunity to discuss the technical work
... [clapping]

<rubys> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25946

rubys: This bug was filed by Anne. "Rewrite the URL parser"

<rubys> http://intertwingly.net/projects/pegurl/url.html#url

rubys: He found a RUST based implementation and thought he might be able to port.
... Now, I have done some work to grammar-tize the parser.

<rubys> http://intertwingly.net/projects/pegurl/urltest-results/

rubys: (Reiterates that he's solving real technical problems)
... Test results by user agent.
... shows the gaps in consensus.

<rubys> https://github.com/rubys/url/

rubys: I would like to see the spec updated based on places that seem like browser behavior doesn't match the spec
... I invite others to review the work.
... Please test it out yourself.

<rubys> http://intertwingly.net/projects/pegurl/liveview.html

rubys: page show what the browser does with a URL and what rubys's implementation does (per the URL spec)

<dka> Validates on http://will.i.am.

rubys: Soon it will show hard/soft parsing errors.
... Thank you

MarkN: Thanks to Sam for taking this on.
... IETF area director is visiting. What is this working group going to tell them about where the work is being done.
... Are you deferring to the TAG for this decision.

ArtB: We have two formal objections to publishing under W3C.

Dan: It's possible that TAG + WebApps joint deliverable should be working together to get feedback to Anne.

paulc: Where are the formal objections kept?
... FO's are not meant to be a threat; they are to be logged as technical objections.
... this does not make sense to me.
... HTML5 had 25 formal objections.
... I would like folks to look at the URL reference in today's REC HTML5 doc.
... I'm concerned about people saying: "Tim was there" it was unanimous. I'm of the opinion that Tim may have changed his mind...!

<plh> http://www.w3.org/TR/html5/references.html#refsURL

paulc: This is what the director expects will happen (reading from the HTML5 rec)

marcosc: I think it's fantastic what MarkN is proposing.

Dan: We need to think about how to do this in the future.
... I want positive collaboration and good cross-linking as appropriate.
... but we also need to think about the IPR story.
... the original reason for the re-print of URL was to have a strong story about IPR.
... My lawers at Telefonica said doing URL in webapps would be a strong story. But agreed that WHATWG community licensing was a step in the right direction.
... That's why I agreed on the option for direct-ref to WHATWG.
... We should discuss

Larry: There are some technical issues.
... IRI's partial failure was no participation with dealing with technical issue.
... primarily for non-ascii domain names.
... Someone needs to lead to propose something to follow.
... The technical issues _do_ need to be resolved. Please don't get hung up in the politics.
... Please review the proposal and give feedback. Let's do some work.

marcosc: I was going to agree; I agree. Let's focus on the technical work.
... Half the web platform is owned by the WHATWG

ArtB: We're getting off topic.

<Zakim> rubys, you wanted to say that I don't think we have an answer to mnot's question, nor will we likely have one by tomorrow

rubys: I don't think we can give an answer.
... I've showed you something I'm working. If the director wants it in W3C or not, I'm happy.
... If there's IPR work, I'm happy to do it.

markn: I wasn't aware of what Paul brought up. So, thank you.

ArtB: Any further comments? Queue is empty.

Dan: One thing we've discussed is whether we need a TF for URL to represent the community. E.g., Data on the web which is using URIs (what they call them)
... I think this is an important constituency to consider for the TAG
... We need to take into account the work Larry describes for registries.
... Does it make sense to form a TF from TAG, this working group, other communities?
... I'm happy to put energy into making this happy.

rubys: The keyword is "technical" input.
... I've seen lots of groups jump on this to help with non-technical input.
... Does Anne feel he needs a TF?
... Does Sam need one (me)?
... We need pull requests.

<ArtB> WHAT WG Github repo

Dan: Just want to make sure we're doing something useful. Not married to the TF idea.

ArtB: PLH?

plh: At the end of the day, we want to see URL working on the web.
... Whatever we can do to help we will.
... Now we are in this mess as IETF outreach didn't help in the past.
... So where should the work happen?
... I want the work to happen :-)
... I don't see enough browser involvement right now. I don't want it to be wasted effort.
... IETF has had trouble getting browser involvement.

paulc: I compliment Sam to take the time to tackle the technical work.
... (while they worked with the director on HTML5)
... I think this WG needs a plan for a plan to publish a W3C working draft.
... I noted that FO don't stop things from happening.
... But we should know what state we want URL to be in before another heartbeat.

<Travis_> scribe: Travis_

MarkN: Lots of communities involved.

Dan: I do not disagree with you.
... Point: Spec should explicitly scope itself to not include URI/URL outside it's scope.
... Feedback that the URL spec does not take into account other consituents.

MarkN: IETF is not angry with W3C on this.
... we recognize that we dropped the ball.
... State of IETF is patiently waiting to see what will happen.

rubys: Just want to reiterate that I volunteer.
... paulc said get a plan for a plan.
... Now, I'm in the Webapps WG I can help
... I'm here all week.

Larry: To reduce heat: URI can be stable while IRIs needed updating.
... you are producing a replacement for the IRI spec.
... You'll get less push-back if your replacing 3987 (vs. 3986)

MarkN: IETF is saying "don't worry about us"

ArtB: This concludes the discussion. Thanks all.

<timeless> scribe: timeless


chaals: Editing and friends are the topic
... i'll give it to benjamp

benjamp: today we have a wrap up of Intentions
... we have some requests from Indie UI
... and then editing for the last hour
... objections?

[ None ]

rich: Rich Schwerdtfeger, IBM
... we were talking about the tie-in with Selection
... also Craig had mentioned multiple people w/ access to selection
... also the end-event
... benjamp ?

benjamp: i have those notes, and i should be able to make bugs/update the spec
... if there are things you want to cover in this meeting...

rich: we'd like to see avoided
... -- we'd like to know about the type of object w/ which you're interacting
... we have ARIA
... we'd like to make it more mainstream
... we'd like Dual-benefit
... if you run into a slider, you need the current value of the slider
... max, min, increments (we don't have yet)
... to do device-independent interaction
... for Accessibility, we need APIs for this

benjamp: sounds great, i'll file bugs for those
... I went to the Indie UI meeting earlier
... we went over some requests
... some ways to merge
... I have things to consider, they'll all be on the ML
... Indie UI seems to be willing to take the Events we're considering in WebApps/CSS
... Scrolling/Selection
... and let them be driven by these WGs
... and continue on with the rest of their events
... using the events structure

rich: we may move things over

janina: we don't need to go into it now
... process point, we'd like to keep ourselves all coordinated
... not useful to join multiple lists
... how to structure work together
... so communication flows more smoothly
... we had a structure set up
... but we aren't using it the way it was intended
... with multiple lists, people aren't necessarily on the right list
... maybe chairs should discuss how to do this

chaals: yeah
... helpful

<Zakim> jcraig, you wanted to discuss Element.computedRole() and Element.computedLabel()

<ArtB> ACTION: charles make sure WebApps has good communication flow with IndieUI group re Editing [recorded in http://www.w3.org/2014/10/28-webapps-minutes.html#action01]

<trackbot> Created ACTION-756 - Make sure webapps has good communication flow with indieui group re editing [on Charles McCathie Nevile - due 2014-11-04].

jcraig: we had a discussion about Events this morning
... i'd like to mention other topics
... three that I remember...
... Selection API ... ComputedRole, ComputedLabel
... an accessor for UserSettings
... IndieUI UserContext
... Element.computedRole, Element.computedLabel
... input.type=submit, input.type=button -> roles are both Button
... Role = Switch
... Switch is ARIA 1.1
... css can't tell how to deal w/ this
... This morning, CSS approved a role-selector
... alex@mozilla Element.accessibility, Element.role - a way to get the accessible version, or the object
... to me it makes sense to get direct from the DOM

Travis: Agreed (direct)

rniwa: i think computedStyle / ...
... should go to HTML, as opposed to WebApps

chaals: DOM is being done in HTML, but it's sort of WebApps
... and you could it straight in IndieUI
... if we're talking w/ WebApps and API people and same people in HTML in this room
... you can do specing in IndieUI
... say IndieUI is specing Element.computedRole
... and HTML would know
... I don't care either way

jcraig: if you think this is appropriate to HTML WG
... I'd probably push it to ARIA, rather than IndieUI

rich: the SVG WG is now
... building off the HTML Element
... and get computedRole label there
... not sure we'd want it on Element

jcraig: does MathML inherit from Element?

paulc: I want to encourage you to do the work, don't worry about where it ends up
... we'll meet in 6 months, I'll buy you all a beer

rniwa: my point was that I don't want this to be part of Intentions, or Editing, it's clearly not Intentions/Editing

jcraig: there are a few unrelated topics

<jcraig> ARIA 1.x

rich: I don't think anyone will have problems writing spec text
... who do we send it to?

chaals: write it up, send it to WebApps+HTML, "what do you recon"
... we'll say "g, looks good to me"

rich: is anyone working on MathML right now?

chaals: I don't think they are

janina: I think they're in maintenance

<jcraig> jcraig to spec: partial interface Element { String computedRole(); String computedLabel(); } (already a PF Action)

chaals: it would make sense to write to them as well

joanie: for Generated Content
... I wasn't planning on it, but i'll toss it out
... in talking w/ benjamp, i'll file issues
... some of the problems we're having w/ generated content
... from an Accessibility issue
... it isn't selectable
... Apps might do this and put small bits of text :before/:after
... assistive technology user can't copy it
... which is fine
... the assistive technology would need to put up a workaround
... but it would need an API "is this selectable?"

chaals: Generated content is "not part of the DOM"
... if you're doing a Rich Selection into the clipboard
... you could maintain that separation, HTML + style
... if you're doing a straight text selection
... please can we have What-You-See-as-What-You-Select
... be What-You-Get-in-the-Clipboard
... analogous to background-css sprite stuff
... "technically it's not part of the page"
... but the only people who know that are those people using "inspect element" to see the page
... everyone else says "it's there, I can see it, it's part of the page"
... you should be able to see it, you should be able to select it, you should be able to pick it up

Travis: on generated content selection
... we unfortunately had to fix a bug recently
... for Interop on the live web
... pasting generated content broke the site
... i'm of the opinion, that if you see it, you should be able to select it, and copy it, and paste it
... Due to technical limitations in IE, you can only select the entire generated hunk

benjamp: in 8 minutes, I need the meeting for Editing

rniwa: in some browsers, you can't select generated content
... that's something we (WebKit) need to fix
... we either need to put it in Selection API
... or ...
... there could be technical issues we need to resolve
... what's important is that when you select it and copy it, it needs to include the generated content
... I think that involves specing in the text

chaals: I thought Travis was going to do it
... Text and Keyboard is easy

jcraig: the 1.0 Selection API should note "it's going to include generated content", or "it's not going to include generated content"
... if it should be somewhere else, we should know where

chaals: we should put in the 1.0 draft that "you should be able to"
... if that's a problem, "it would be nice if you could do this, currently there's no way to do this, but it is the goal"
... we can push wishes for the future into the spec

jcraig: what is the users
... inverted color settings
... do they have capability of keyboard
... ability to get captions enabled
... seems like a dom change
... we have a draft of it
... in Indie UI
... based on rniwa ...

rniwa: we brought this up @Shenzhen last year

jcraig: several of the things that make sense
... are in the drafts

<jcraig> http://www.w3.org/TR/indie-ui-context/

jcraig: one of them
... section 5.3
... subtitles are preferred
... subtitles available to the user, English + Spanish
... not needed for HTML5 video
... but custom video, flash video
... you'd need these to detect

chaals: you're doing that in IndieUI
... keep doing it
... we're happy not to take work from you
... that it?


benjamp: yesterday we talked about a common shape for our API
... having thought about that a bit more
... the goal of the intentions explainer
... 1) explain to browsers/standards bodies how things should work
... selection, scrolling, input
... a unified concept
... 2) explain to web developers what they are
... how they should build their sites
... how to deal w/ new input modalities
... how to make their sites accessible
... w/o doing more work
... if the explainer can do this, i think that's good

chaals: +1

janina: +1

<jcraig> +1

ArtB: +1

benjamp: alright


benjamp: how Editing plays into Intentions
... how we're going to solve Editing
... Editing was the original thing that came up here, it was on a lot of people's minds
... we've been discussing contentEditable
... the next version of that, or something to replace it
... darobin suggested keeping "true" as a value
... but adding new values
... to enable various levels of behavior
... or various intentions that have default behavior from the browser
... X.contentEditable = "cursor"
... just a blinking cursor, no enter, no delete
... just gives you events
... downside is inline-IMEs would not work
... you'd get a partial composition, and it won't be connected back to the IME
... to finish the composition
... in CJK
... we may be able to solve the problem
... there are some web developers interested in this w/o an interaction to that
... next
... X.contentEditable = "typing"
... no newlines, no formatting, no deleting
... that's a happy medium
... we do the hard parts, IMEs, text insertion
... w/o dealing w/ standardizing/being consistent on newline/delete/etc.

chaals: my understanding is, there are developers of Plugins, RichTextEditors on blogging
... the 5, 6, or 9 groups of developers making that horrible mess of JS code
... not millions of individuals
... but a handful of projects

benjamp: yes, a handful of projects used by many sites

chaals: not to preclude another individual from writing an editing system

benjamp: X.contentEditable="multiline"
... X.contentEditable="deletion"
... these names are random, we can change them
... they're here to talk about
... X.contentEditable="formatting"
... XXX or "formating"
... cursor/typing/multiline/deletion
... we need to think about the order in which to tackle them
... is typing the one to tackle first?
... typing is harder to spec than cursor, but more useful
... feedback?

rniwa: difference between typing/multiline?

benjamp: X.contentEditable="typing multiline deletion"

[ like X.classList ]

benjamp: typing is basically "insertion works, like <input type=text>"
... but the element itself supports full html/css but only modifiable by script, not by user input
... paste would have to be handled separately

rniwa: i have a hard time believing you want these different types
... i feel there are very few UCs where you want typing
... but not ...
... i feel like it would be better to have "multiline" and then offer cancel for newlines

chaals: +1
... seems to be the logical place to start

benjamp: the reason i'm considering typing
... we don't have Intention events
... it will take time to spec those
... even if we spec those
... if we could get typing
... people could use existing dom apis
... typing is easier to spec
... true is supported, and you get intention events
... cancel some events, and let it run

rniwa: i don't think "typing is easy"
... it's very hard
... typing includes IME, spellcheck, autocorrection, grammar, dictation, accessibility
... specing typing would take as much time as typing if not more
... IMO, it doesn't make much sense to spec type=typing concurrent w/ Intention
... hoping that Intention is before intentions
... I think typing is much harder than Intentions

chaals: Intentions is "generate an event"
... that seems simpler than "specing typing"
... i'm w/ rniwa

Travis: benjamp can you clarify the difference between
... X.contentEditable="typing" and what you get w/ <input>

benjamp: they're similar, except you deal w/ HTML
... X.contentEditable="typing" would be an input tag except
... pressing <enter> does nothing
... selection and replacing does nothing
... the developer would have to figure out what to do

chaals: you select across a boundary involving <b>
... and press <del>
... the editor has to decide what to do

benjamp: which would be the case if you handled the keys and canceled events
... if you handle only delete, you could
... -- you can't insert over a non-empty-selection

Norbert: my experience is that
... typing itself is often very hard
... spellchecking is hard/spell correction
... an application can not add much value
... whether it would make sense
... to draw a boundary around typing
... say that typing w/in one #TextNode is handled by the browser
... anything around it is handled by my application

benjamp: that's what x.contentEditable="typing" is

Norbert: if you say <backspace> is not part of "typing"
... but <backspace> w/in a #TextNode is

benjamp: that's ambiguous

Norbert: we'd have to define when control returns from the Platform to the page

rniwa: suppose you type "hello"
... <space>
... <ctrl>+b
... type "world"
... now you hit <del>
... maybe it's in the #TextNode
... when you've deleted the "world"
... what happens when you press <del> again (near <ctrl>+b)

chaals: if you hit <del> and you're not trying to delete w/in a node
... it should be handled
... we generate a <del> intention when the browser won't handle the text on its own
... when you're in the element, you hit delete
... as soon as the element is empty, it deletes the text
... now you have <del> event fired and the application has to figure out what to do
... <span>[hello]</>[ ]<b><span>[world]</span></b>

rniwa: the browser has to understand the state

benjamp: if we do this
... we're doing the easy parts, and leaving the hard parts to the frameworks
... if it's inconsistent and sometimes don't fire events, that's really confusing

chaals: conservatively do deleting
... if you know where you are, and you can be really sure,
... not perfectly interoperable
... then you delete
... user presses <del> at end of <b/>
... you fire off intention
... and the web page looks at where you are
... and the web page decides what to do

benjamp: we've talked about having the Delete Intention say what it would delete
... browser makes a guess
... gives it to the app
... if the page disagrees, it can change it
... and then it can be modified

rniwa: <span>[heello]</>[ ]<b><span>[world]</span></b>
... if i go back to heello, i should be able to go back
... the browser needs to know that it was something that the user just typed
... there's contextual information the user needs to get out of the text

benjamp: this is why we want to include "what we're about to insert"
... if you hit <ctrl>-b, we should include an empty thing
... we need to provide the contextual data
... may-be more contextual data
... they just typed it, we need to spellcheck it
... crazy UCs, like end-of-word and spellchecking
... we need to think about it
... as long as we handle each individual action
... typing character
... deletion
... handle each of them, it should be clear what we're supposed to be doing

<Zakim> timeless, you wanted to ask why?

timeless: Just because the user didn't write something
... doesn't mean they don't want spelling corrections
... i frequently copy other peoples' texts
... and use spell correction

jcraig: on Contextual information
... sometimes, what's available is
... what's misspelled
... the contexts of what they've typed
... the candidates of what they've typed
... likewise w/ dictation
... similar phonemes vs. keyboard shifts

rniwa: not putting autocorrection is a feature is a specific feature we added
... we keep track of which pieces the user typed and which the user didn't
... we specifically avoid it
... it isn't that we're treating text as typed differently
... because we were careless
... it was intentional

[ timeless thinks this is stupid ]

rniwa: to avoid autocorrecting a reply
... to an email
... i don't think it's sufficient for a browser to know
... just the surrounding text
... in the case of auto correction on a mac
... you should be able to select any text, and the browser should be able to correct the text
... the browser needs context
... the browser needs to be able to initiate where to start correcting

chaals: that's an important UC
... but is that problematic?
... yes i should be able to deal w/ that
... but i don't see where
... this is cases where you're sure

rniwa: to benjamp 's earlier point
... giving context of where things are typed

[ scribe clarifies, benjamp 's context is to the webapp ]

[ the browser has everything ]

chaals: the webapp can autocorrect what it sees
... but do we need to provide this ... as a v1 thing

benjamp: when a browser makes a decision about what it's about to do
... user types a letter [A]
... browser knows what's selection
... we need to provide the webapp what the browser planned to already do
... they need the context data that the browser was using to make these decisions
... context data = {current word, what's selected, ... }
... we can figure out what that is
... hand it to the web app as an Intention event
... the web app can decide to change it

rniwa: apps need to inform browsers what parts are / aren't editable

benjamp: then it should be X.contentEditable=false

[ chaals goes to drawing board ]

chaals@[yandex.ru] <- browser inserted this

chaals: app needs a way to tell browser don't let delete

benjamp: that's what X.contentEditable=false

chaals: it's selectable because it's text

benjamp: it's selectable unless it's a picture

[ or if it's CSS selectable:false ]

rniwa: we don't let users select across editing boundary

[ is that a bug? ]

chaals: we use :after{content:"yandex.ru"}
... this is how we handle identities on our Intranet

benjamp: maybe we should have a session on problems to solve
... if people think there's a problem w/ having the context the browser would use
... apps can make the decisions they want to make

chaals: i think so
... it seems like there's a model for typing which works
... we need to sit down w/ UCs and check the model
... everytime you're not sure, give the app an intention event
... everytime you're sure, the browser should be able to just-do-it
... it's unclear there'd be any problems

Travis: i think it will screw up a JS state machine
... if you're a web app and you're managing this experience
... and you only get things for the hard case
... you're probably missing context
... i support giving the context for the simple thing

benjamp: agreed

chaals: simple thing is text-inserted; text-inserted; text-removed
... i agree you should get events when things change
... complicated

benjamp: before-input "inserttext"
... vs. "format"
... or "insertnewline"

Norbert: it sounds like you want complete state

benjamp: i'm planning to give context data
... spelling should be handled by the browser
... unless you want to handle it in the app

chaals: we're trying to make it possible to build an editor
... where the ordinary stuff (Text in/out) is handled by the browser
... and editors handle everything else
... if you want to screw up the basic stuff, we won't make that easy in this version

<Zakim> jcraig, you wanted to mention the IME and dictation examples

jcraig: selection crosses a boundary
... a case where you handle stuff to the webapp
... in IME/dictation case
... there's a psuedo entering selection that comes and goes away
... Romaji, "toayou", there's a candidate for "to, kyo"
... while you're talking, it's rendering things
... but the whole insertion is rendered
... but if you're selected over a word boundary
... the app will perform a change
... the way i'm hearing this
... nothing would happen while you're typing
... you wouldn't see visual feedback

chaals: you'd see the IME
... you'd see the input method has control
... when the IME hands the text back, you'd get the event
... you'd have to decide how to deal w/ the text

jcraig: we'd render it as if we're changing the dom?

chaals: no





chaals: you'd see the browsers IME saying here's stuff
... until you select the character you want
... the cursor sits there waiting until you're done w/ the IME

jcraig: i understand the characters

chaals: we're not talking about client imes
... only Host IMEs

benjamp: this UC can be solved w/ inline updates
... if we're firing ALL intentions
... IME, or other input-method
... it inserts and removes text many times
... they can handle it, or let us handle it

Katie_Haritos_Shea-Shea: what about an Observe?

benjamp: all events are Observe unless you interfere

rniwa: when user types, there are specific underlines, and that needs to be done by the browser

chaals: absolutely
... IME is figuring out what i want
... the intention is "replace this" with

benjamp: when you get a text-input event
... you normally let it happen
... if you want to insert extra stuff
... you can do that, because you know text was just inserted
... but generally you let the text insertion happen
... there's an editor at microsoft
... Visual Studio Online Code Editor
... they're using a floating text area to do insertion
... they can't style it
... we need to provide them to let them monitor what gets inserted, but style it
... they want IMEs to be handled
... we're all in agreement about that

rniwa: i think darobin's proposal
... using a Shadow DOM attached to the caret
... into which the browser inserts text nodes
... might be something close to a workable solution

benjamp: 12 mins
... next steps
... obviously lots of problems to solve
... one of the big ones is Input
... input is incredibly complicated
... before-input and input are in DOM Level 3

[ Travis is laughing ]

benjamp: i want to propose to them
... that we take that in the Editing TF
... because we're solving these problems
... I don't care what spec it's in
... we should be solving them in intentions

Travis: don't look at me

chaals: what's the problem?
... not done until DOM3 (heat death)
... it's not done until (heat death of next universe)

benjamp: alright, see what we can do
... next, priorities
... what do we want to go solve
... in what order?
... X.contentEditable = typing
... as a concept, i think it's the baseline
... it enables IMEs, spellchecking
... disables formatting, newlines

[ Agreed ]

benjamp: Developer Momentum
... CK Editor is a group we're working w/
... we need to continue to build, get feedback, UCs, testing
... i'm working on that @MS
... i'm sure the others are working on this in their own companies
... @Extensible Web last month
... two groups came to me
... we need a strategy

chaals: if we start doing the work and say "you're welcome to come do this"
... and they want this to happen
... hopefully they'll come
... we can't force them to come
... we can't force them to spend time

benjamp: everyone interested in this, please tell them to come

chaals: usual thing at the end of a meeting

benjamp: what do we do with these documents?

chaals: when ready, publish as notes
... we can publish as drafts first
... when we're done scribbling on it, we publish as a note

benjamp: not yet

darobin: you publish to get feedback

chaals: a group of editors in a room
... would be pleased if they had a stable-ish draft that didn't change every day
... so they could give comments

benjamp: target that a couple of months out

Next Meeting

chaals: somewhere in north in spring

benjamp: we have Friday calls, we don't use it regularly
... it's been once every month or two
... it's 8am this time zone (Pacific)
... we can do adhoc
... we use #webapps

[ Adjourned ]

ArtB: thanks timeless

chaals: thanks timeless

[ Applause ]

Summary of Action Items

[NEW] ACTION: charles make sure WebApps has good communication flow with IndieUI group re Editing [recorded in http://www.w3.org/2014/10/28-webapps-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2014-10-28 23:57:46 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/Charles_Neville/chaals/
Succeeded: s/Joans/Jonas/
Succeeded: s/Alan/Ali/
FAILED: s/alan-i: Alan/alia: Ali/
Succeeded: s/QQ/Stephan Steglich, Fraunhofer Fokus, observer/
Succeeded: s/RRR/Okuma, Tomo-Digi Corporation, Observer/
Succeeded: s/alan-i/alia/
FAILED: s/PPP PPZ/ Bill Hsiung, MSTAR Semiconductor/
Succeeded: s/PPP: PPZ/Bill Hsiung, MSTAR Semiconductor/
Succeeded: s/nic/nique/
Succeeded: s/FSQ/Xitong Huang/
Succeeded: s/Applequest/Appelquist/
Succeeded: s/Topic: Agenda//
Succeeded: s/III:/Mohammed Dadas/
Succeeded: i/topic/anssik: Anssi Kostiainen, Intel
Succeeded: s/+igarashi/Present+ igarashi/
Succeeded: i/topic:/rubys: Sam Ruby, Apple
Succeeded: s/two/two prefixed/
Succeeded: s/concern/concern - do you want to give any more detailed info here?/
Succeeded: s/chaals/scribe/
Succeeded: s/SOunded/Sounded/
Succeeded: s/manifest is loaded/manifest is not loaded/
Succeeded: s/??/Joannes/
Succeeded: s/adds/ads/
Succeeded: s/IOS/iOS/
Succeeded: s/pasted/pasting/
Succeeded: s/IndyUI/Indie UI/
Succeeded: s/QQQ/Schwerdtfeger/
Succeeded: s/ComputedRule/ComputedRole/
Succeeded: s/extension/intention/
Succeeded: s/X.contentEditbable/X.contentEditable/
Succeeded: s/stupdi/stupid/
Succeeded: s/"yandex.ru/:"yandex.ru"/
Succeeded: s/Katie/Katie Haritos-Shea/
Succeeded: s/Katie Haritos/Katie_Haritos/
Succeeded: s/Katie_Haritos/Katie_Haritos_Shea/
Succeeded: s/using Shadow DOM/using a Shadow DOM attached to the caret/
Succeeded: s/... create hidden node//
Found Scribe: timeless
Found ScribeNick: timeless
Found Scribe: Travis
Inferring ScribeNick: Travis
Found ScribeNick: Travis
Found ScribeNick: ArtB
Found Scribe: Travis
Found ScribeNick: travis
Found ScribeNick: Travis
Found Scribe: Travis_
Inferring ScribeNick: Travis_
Found Scribe: timeless
Inferring ScribeNick: timeless
Scribes: timeless, Travis, Travis_
ScribeNicks: timeless, Travis, ArtB, Travis_
Present: Brian_Raymor Art_Barstow Josh_Soref chaals Yves_Lafon Ben_Peters Xiaoqian_Wu Adrian_Bateman Ali_Alabbas Mohammed Dadas Sam_Weinig Hiroyuki_Aizu Shijun_Sun Sakari_Poussa Alan_Iida dom Kenneth_Christiansen Jonas_Sicking Olli_Pettay Laszlo_Gombos Israel_Hilerio Wooglae_Kim Claes_Nilsson igarashi Anssi_Kostiainen Jungkee_Song Robin_Berjon Benjamin_Poulain Bryan_Sullivan Dan_Appelquist Ted_Oconnor Joerg_Heuer Marcos_Caceres Mounir_Lamouri Sam_Ruby Stephan_Steglich Travis_Leithead Kevin_Hill miterho Mikko Terho Huawei Mark_Nottingham Larry_Masinter Peter_Linss Phillipe_LeHegaret Paul_Cotton Mike_Smith Alex_Russel James_Craig Michael_Cooper Richard_Schwerdtfeger Katie_Haritos-Shea Janina_Sajka Norbert_Lindenberg
Agenda: https://www.w3.org/wiki/Webapps/November2014Meeting#Agenda_Tuesday_October_28
Got date from IRC log name: 28 Oct 2014
Guessing minutes URL: http://www.w3.org/2014/10/28-webapps-minutes.html
People with action items: charles

[End of scribe.perl diagnostic output]