See also: IRC log
<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
ZZZ
AAA
BBB
CCC
DDD: France Telecom, Obs
EEE
<Evangelos> Evangelos Vlachogiannis Fraunhofer FIT, observer
FFF: Observer
GGG: Observer
HHH: LG
Mohammed Dadas Orange
<GeunHyung> GeunHyung Kim
JJJ
KKK
LLL: Japan, Observer
<bryan> s/PPP PPZ/ Bill Hsiung, MSTAR Semiconductor
MMM: Oracle
marcosc_: Marcos Caseras, Mozilla
VVV
WWW
XXX Observer
dom: Dominique, W3C
EWQ Softbank
RFE
WQQ
POQ
LMN
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
IQQ
DQQ
[ 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
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?
[ 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
-> 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
[C]haals
[4]
[h]
[x]
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
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 ]
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]