See also: IRC log
<ArtB> Scribe: Art
<ArtB> ScribeNick: ArtB
<bryan> on the bridge, Bryan Sullivan (AT&T)
<plh> scribe: plh
Art: Clipboard API
... we have a status report as of April 8
... the editor isn't around
Ryo: some discussions on how to
spec the markup
... this will take a couple of years to spec
... seralizing the DOM, including style, is complex
... I'll post more details on the list
... but it will take a long time
Art: if folks are interested in
moving this spec forward, please step up as always
... DOM3 Events
... we don't have the editors around either
... will be a third LC
... 12 bugs
... some concerns since HTML5 has a normative ref for it
... and would make life easier if DOM3 Events was a REC
... since it's not going to happen anytime soon
... I've been pushing this soec to go back to LC
Marcos: what's the dependency?
Robin: it's about the event types
Art: UIEvents is blocked on
... Pointer Events depends on UIEvents
... Glenn expressed interest in moving forward D3E
... plan is to split out features that would prevent it to move forward
Adrian: plan to split out key names/values
<smaug> rniwa: wrong port?
<smaug> rniwa: should be 6665
Adrian: and proceed
... primary reason is that changing will happen to those anyway
... also want to review various mobile platforms and their keyboards
Art: DOM P&S
... pre-LC2 comment period
... last set of bugs submitted by Anne
... in the absence of issues in the next couple of days, we'll start LC2
... CfC to stop work on File API specs.
... no one objected
Ryo: any test on DOM P&S
<ArtB> ACTION: barstow update testing info in PubStatus for DOM P&S spec [recorded in http://www.w3.org/2014/04/10-webapps-minutes.html#action01]
<trackbot> Created ACTION-714 - Update testing info in pubstatus for dom p&s spec [on Arthur Barstow - due 2014-04-17].
Art: FullSccreen API
... last update was 2 years ago
... plan was to copy a somewhat stable version into W3C spec
... whenever they think it's donish
Mike: zero bugs is the best you
get from the WHATWG
... I don't think it's being worked on actively
... it's on a back burner
Art: any concerns?
<Hixie> could we not copy other groups' work, causing forked specs?
Glenn: is there a dependency from HTML 5.0
Robin: Fullscreen is non-normative
Art: [reading Hixie's comments
... let's move that to an admin topic
... (adding to the whiteboard)
... they have one bug left
... will enter LC in Q2
Adrian: we're looking into this
spec. filed a couple of bugs
... so some discussion left
<smaug> (Gamepad will be most probably enabled in FF29)
Art: (going to back to fullscreen)
Tantek: status sounds
... Anne is doing most of the work there
... it's waiting for more implementation feedback
Art: implementation status?
Marcos: status is pretty good
<scribe> ACTION: Art to follow with Tantek and Anne on next steps for fullscreen [recorded in http://www.w3.org/2014/04/10-webapps-minutes.html#action02]
<trackbot> Created ACTION-715 - Follow with tantek and anne on next steps for fullscreen [on Arthur Barstow - due 2014-04-17].
Adrian: everybody does it
... body element fullscreen gets different resutls for example
Art: anybody to look into tests?
<krisk> I can push some tests into github for fullscreen
Kris: I can do it
<krisk> ACTION: krisk push full screen api tests into github [recorded in http://www.w3.org/2014/04/10-webapps-minutes.html#action03]
<scribe> ACTION: Kris to look at tests for Fullscreen [recorded in http://www.w3.org/2014/04/10-webapps-minutes.html#action04]
<trackbot> Created ACTION-716 - Push full screen api tests into github [on Kris Krueger - due 2014-04-17].
<trackbot> Created ACTION-717 - Look at tests for fullscreen [on Kris Krueger - due 2014-04-17].
Art: Aryeh did some good
... and Ryo did some work as well
... should we find a timeslot for this?
Art: ok, 10:30am then
... CR for 9 months
... draft implementation report
... missing data for IE
Kris: I'll give results
Art: we're making progress
... between Josh and Jonas, various discussions on work on v2
<krisk> Yep we were talking at the HTML WG meeting about this and exchanged email
Israel: full text search capability
Josh: guidance on moving forward for v2?
Art: adding IDB at 4pm
Yoshi(?): one bug remaining
<slightlyoff> FYI, I'm going to be at the meeting later today and most of tomorrow so feel free to schedule SW discussion for any time after noon today
scribe: it's 2 documents
... first one is good enough to move forward
... [offset clarification needed]
Adrian: we need to discuss that
one, but we implemented it in IE11 and we were ok with the
... it's in good shape
Art: what about moz?
Yoshi(?): didn't see interest outside MS and GOO
Mike: I can work with Kochi
<falken> ^^^ (Takayoshi Kochi)
Art: Manifest is this
... Pointer Lock, we're in CR
... we have a few tests
... Push API is this afternoon
... quote API. status report on April 9
Yves: TAG is working on review of
... about to be done
Art: any issue?
Yves: one issue on good understanding on type of storage (persistent, etc.)
Art: Screen Orientation?
Mounir: I sent an update to the
... so could address questions
... made some changes, prefix impl from moz and ms, are they ok with them?
Jonas: let's allocate some time
Art: 4:30pm this afternoon
... Server-Sent Events
... draft impl report
... looks like we're close to being done with this. just a few bugs
... there is a PR for the timeout failure
zqzhang: can someone review it?
Art: and we have some
... constructor failures
... probably all the same error
... if someone could take a look at these 4 failures
... from the chrome team
<tyoshino> tyoshino of Chrome team. going to take a look at SSE failure
<scribe> ACTION: tyoshino to look at the failures on Server-Sent Events [recorded in http://www.w3.org/2014/04/10-webapps-minutes.html#action05]
<trackbot> Created ACTION-718 - Look at the failures on server-sent events [on Takeshi Yoshino - due 2014-04-17].
Art: ServiceWorker, we have time
... Stream API
Feras: we have one common API
between Node and the browsers for Stream API in WhATWG
... it's pretty stable for the most part
... but no really big change expected
... some cleaning and then integration back into W3c side
Marcos: we got agreement to move
that spec into W3C proper at some point
... while maintaining the CC0 aspect at the same time
Adrian: the stream topic was
discussed at the summit
... (link to minutes above)
... good discussion there
... sense is that there are still some open questions for the design for the base spec
Art: captured in the github?
Marcos: yes, discussion on the way
Art: ok, looks like this is
... was mentioned earlier
... priority is D3E
<krisk> I think their are tests for URL http://w3c-test.org/url/
... plan is to work on it in webapps
<tantek> plan is for *who* to work on it in webapps?
Mike: I won't be able to be the test facilitator
<tantek> or is this just for testing the URL spec?
Mike: [some discussion on the test suite]
Glenn: is the plan to publish a W3C version of the spec?
... Dan AppelQuist will look into it
Art: Web IDL
... Cameron sent tests
... we came up with comments
... yves has been looking to update the PR
... for the PR, some things are not implemented at all, like ArrayClass
... float has some issues
... since some constructors are not allowed all values to be checked
Yves: two more weeks of work there
Art: plan is CR->LC
Yves: Cameron is pretty close to that
Art: Boris came on board to help.
Anyone else willing to help?
... WebIDL is used in a lot of specs
... is Promises part of v1?
Yves: if publishing v1 takes too
much time, then yes
... as long as we have tests
Art: ok, work is
... Web Messaging
... spec is in CR for 2 years
Kris: still lots of
... I think the tests are accurate
<scribe> ACTION: Art to change WebMessaging test facilitator to Kris [recorded in http://www.w3.org/2014/04/10-webapps-minutes.html#action06]
<trackbot> Created ACTION-719 - Change webmessaging test facilitator to kris [on Arthur Barstow - due 2014-04-17].
Art: Web Sockets
... CR in 2012
... failures in the tests again
... any test case issue?
Kris: similar to Web Messaging. bugs to be fixed.
Art: deployment status?
Robin: works pretty well
... if you stick to the common core
Art: so many people should go
fixing their implementations...
... similar again
... James created an implementation report
<scribe> ACTION: Kris to provide test results for Web Workers [recorded in http://www.w3.org/2014/04/10-webapps-minutes.html#action07]
<trackbot> Created ACTION-720 - Provide test results for web workers [on Kris Krueger - due 2014-04-17].
<marcosc> join #webmob
Art: last is XHR
Jungkee: not much to update
... no particular issue. just working on testing side
... test ratio increasing in blink and gecko
... need some help from MS
... impl report is up-to-date
... around 10 to 20 tests are failing across all browsers
Art: probably more than 20
... back to potential topics
... some admin related stuff
Yves: charter, packaging spec
from the TAG
... might want to work with webapps for that
Art: any news from the TAG f2f or
... workvers v2?
Art: Workers v2 at 5pm
... Admin copying specs at 5:30pm
<adrianba> ScribeNick: adrianba
rniwa: do people from msft have topics other than the two i listed?
BenjamP: sounds good
<ArtB> https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html -> Editing API
rniwa: on the status page it
sounded like i was going to do the whole editing api
... but i actually want to work on extracting selection and put it into its own spec
<ArtB> http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0099.html -> Ryosuke's email re Editing topics
rniwa: so we can unblock other
work that is hand wavy about what selection does
... so i think the priority is for us to work on selection api
... and then maybe do editing after
hober: at the html wg the
consensus was splitting off selection and tackling that first
is a really big win
... having a well defined way to do multiple selection and bidi would be a good win
... having a good understanding of selection would inform future editing work
BenjamP: i agree as well
sicking: i haven't followed this
- i'm very interested if someone figures out contenteditable we
... starting with selection sounds good
... definitely tricky problems where
... not sure how much it helps with contenteditable
rniwa: copy/paste and clipboard
apis is another thing
... there was a discussion of how to serialise styled DOM
... i don't know what the dependency should be here
... should the clipboard api be part of selection api
... it seems weird to specify clipboard in selection
BenjamP: maybe it is important
for clipboard to understand range
... knowing active range
rniwa: are you saying define active selection in selection api
rniwa: but that would block clipboard
hober: i think that's fine
darobin: it makes sense for clipboard to depend on selection
rniwa: copy/paste will be in
clipboard api - is that the right approach
... is there anything else about the selection api split?
ArtB: you are intending to lead the editing?
ArtB: are you looking for assistance
darobin: maybe you can start the new spec in github somewhere and then people can do pull requests
rniwa: if someone from microsoft or mozilla or someone else wants to help that would be great
rniwa: i wanted to move on to
discussing improving contenteditable
... i read the spec and it is really hard to read
... i understand others had problems - it's very algorithmic
... it appears to me that because of historic divergence between browsers a lot of frameworks are depending on specific bugs in certain browsers
<slightlyoff_> (cwilso and I are waiting in the entry)
rniwa: so i think it would be beneficial to talk about a new editing api
darobin: we discussed this in
... i've been talking to editing frameworks and msft has been talking to their teams
... we came to the conclusion people want an editing surface that does less
... and the apps have to block all the capabilities
... we were thinking about maybe a more minimal contenteditable
rniwa: the current editing spec
has some proposals around new input events
... and you get more information about key bindings
... solving that is more important
darobin: wasn't someone working on a higher level event spec
hober: IndieUI would probably be
downstream of this
... it's mostly parallel
rniwa: some apps may already
support some subset of events - you could imagine an attribute
that allows some of those events to still fire
... for example pressing delete could send the delete command
... definitely see connection between IndieUI for a11y and what we need for editing
BenjamP: there is definitely a
connection at some level
... for example they have undo/redo which you would need
hober: if a new spec defined undo/redo as events in the platform then IndieUI would reference them
rniwa: input only fires on editable fields - perhaps we need it on some other things
darobin: one idea for
contenteditable=basic is that it gives you a caret - if it was
there then it would give those events
... but maybe you'd need that elsewhere too
... for example on svg not sure putting contenteditable would work
rniwa: maybe you need something
to make an element caret navigateable
... you don't want to use contenteditable basic but do want events
darobin: makes sense
BenjamP: agree with having basic
editing as a long term goal
... but difficult to do this without better selection first
darobin: we concluded this
... sounds like there will be 3 or 4 features here
dglazkov__: might be good to have a high level explainer first
darobin: like web components?
dglazkov__: i like the way the
discussion is going - in webkit and blink editor is an actor on
the outside of the DOM
darobin: and that is what
... i'm happy to take an action to write an explainer
rniwa: can we invite people to tpac to discuss this - would be good to get web developers to comment
darobin: we can find a way
dglazkov__: doesn't even need to be at tpac - extensible web summit was awesome because real web developers came
darobin: we should do more of that
<darobin> ACTION: Robin to start writing a high level explainer about the pieces that are needed to put together editing [recorded in http://www.w3.org/2014/04/10-webapps-minutes.html#action08]
<trackbot> Created ACTION-721 - Start writing a high level explainer about the pieces that are needed to put together editing [on Robin Berjon - due 2014-04-17].
darobin: bit early to discuss
organising at tpac
... will work on that
rniwa: anything else?
... thank you
arunranga: we should start with
File because it is easier
... issues left that derailed it from LCWD
<ArtB> http://dev.w3.org/2006/webapi/FileAPI/ -> File API spec
arunranga: really problems with
... everyone wants stream but stream isn't coming yet
<ArtB> https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&component=File%20API&resolution=--- -> File API bugs
arunranga: problems with blob,
neutering, and urls
... believe can be fixed by next week
... think we can resubmit it
... not sure if the right people are in the room to sort out the sticky issue of origin of blob
... we could fix by next week and CfC the week after
... any questions?
sicking: the one big issue other
than the origin is how does close behave?
... we have MSFT people here and they implemented close we should ask them
arunranga: there are a number of
discussions about close
... to me those seem solveable but nobody really implemented it yet
adrianba: can you summarise the bugs?
sicking: what happens to blob
after you close
... originally it was defined so that a lot of things would throw
... now we've been moving in the direction of making fewer things throw
... so if you try to read then it would give an error
... the idea being that it creates fewer error conditions
<arunranga> adrianba, here are relevant bugs for you to study — https://www.w3.org/Bugs/Public/show_bug.cgi?id=25302, https://www.w3.org/Bugs/Public/show_bug.cgi?id=25241, https://www.w3.org/Bugs/Public/show_bug.cgi?id=25240
<arunranga> can someone minute adrianba? audio cuts out
adrianba: [summarise IE implementation - fail fast]
sicking: that was our original approach - but it gives more places for failure
arunranga: one of the current
proposals was any time an async operation on a closed blob then
you could work on a structured clone
... the other thing is we wouldn't be throwing, we would just fail later as if the underlying file disappeared
... so we would fail normally
sicking: would be great to get
your attention on this
... clarifies that cloning a closed blob would create another closed clone
adrianba: it sounds okay - it's not what we did but probably okay
arunranga: i will have fixes in
place and commentary in the bugs
... would be good if adrian looked at those bugs and spoke up
... there are some bugs in File API that have dependencies on other things including WebIDL
... maybe that is a caveat - agree with Art's plan
... once that is in place can issue another CfC
ArtB: other than feedback from MSFT is there anything else you need?
arunranga: jonas, is there anyone in the room to help with other issues?
sicking: for the origin we need adam barth and anne to help with that
arunranga: okay, then we should do FileSystem API
arunranga: if we switch gears and talk about filesystem api
<ArtB> http://w3c.github.io/filesystem-api/Overview.html -> Filesystem API
arunranga: EricU from Google -
the Google API will be made into a Note
... and we will work on FileSystem API as WebApps WG deliverable
... then there would not be two API specs in group
ArtB: CfC to move the specs to WG Note ended and there were no objections - will publish this in the next week or two
arunranga: it would be nice to
see if there is concrete implementer support for the FileSystem
API outside Mozilla
... including prioritisation of work
israelh: we're evaluating as part
of planning for IE
... wanted to get more information
... i understood that Google was going to move to this
jsbell: we're looking at it
<jhazen> Speaker is Israel from MS
sicking: think Google didn't want to move until at least two other parties moving
hober: overall we generally like the look of it - was based on a strawman from maciej - will need to do a more thorough review
ArtB: do we want to move towards FPWD or let it sit for a while?
israelh: you have an implementation don't you?
sicking: we have two half
implementations - something that we use in Firefox OS for
reading SD card
... early version that fed into what is here and now we're updating
... not the sandbox thing like this
<ArtB> ACTION: barstow update WebApp's Draft charter to reflect Eric's File specs are moving to WG Notes [recorded in http://www.w3.org/2014/04/10-webapps-minutes.html#action09]
<trackbot> Created ACTION-722 - Update webapp's draft charter to reflect eric's file specs are moving to wg notes [on Arthur Barstow - due 2014-04-17].
sicking: we are eventually going to do sandbox file system, but not started yet
<smaug> ArtB: ^
israelh: do we know how many sites use this based on Google's implementation?
Taiju: google web sites use it
israelh: we're concerned about interop - is there enough usage to go back an implement the old one or are things converging on the new
ArtB: we agreed to stop working on the old one
<tyoshino> AAA = Taiju
israelh: how much continuing
support will Google have for the old one
... when will you have a more complete draft?
arunranga: i think i can probably do it in 2-3 weeks after finishing File API
ArtB: I like that priority
... coming back to the editor's draft you do have out
... are you expecting to add additional features?
... looking for requests and requirements?
arunranga: no longer a question
of features but of how spec'd features should work and how
... if you look at the API from interface perspective then it gives good indication
... raw API without prose
... indication of shape but not detail
... needs flesh on the skeleton
ArtB: includes use cases too which is handy for early review
arunranga: use cases are similar
or idential to the Google API use cases
... it does very similar things
... some things about Google API that we want to reverse engineer as part of this spec including, for example, file system url scheme
... it is promises based instead of callback based system
ArtB: any other comments or questions?
<arunranga> cool :)
ArtB: looking forward to getting
closure on the File API bugs
... in the agenda we said we'd break for lunch at 12.30 but food is already available
... resume at 1 - i'll adjust the schedule
<arunranga> oh hai cwilso__
<krisk> scribe: krisk
<jungkees> Working repo: https://github.com/slightlyoff/ServiceWorker
<ArtB> http://rawgithub.com/slightlyoff/ServiceWorker/master/spec/service_worker/index.html -> Service Workers
group looking at spec posted above...
a draft of service workers exist and we are hoping to have this a webapp working group project
<falken> better formatting: http://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html
scribe: since a number of people can participate more in this group than when just on github
israelh: We have concerns about perf, additonal requests for example
alex: one pattern we have
observed is that webdevs try to preempty this issue
... we are aware and want to get feedback from webdevs and have a number of google props that value performance
... it's a choice of the userAgent to use a service work or not
... so a useragent can choose not to use a service worker (under memory pressure)
... and it's all async
... so once the intial event is fired it can't block since it's async
... so that background processing can do the work
... we have removed all sync apis - xhr, indexeddb
... you can send work to the service worker to help
... you can warm up dns w/o a service worker
... we think we have done a good first pass on perf and want to get good data from real systems and then do another pass
... we have options but need more use cases
... For example a lifetime header you could help
... Further we have discussed creating a map or longer term cache, but are not planning for this api in V1
... we can imagine a few scenarios, ask for online then upon fail use offline..
... but we have at google incountered that http status codes didn't help make this call
israelh: Where are you keeping this possible plans for the future?
alex: The spec text is mostly normative, maybe a seperate doc in github
israel: how does this work with appcache?
alex: We don't know what will
have as service work gains adoption and appcache remains
... one could be that no app cache if service work
... another could be that app cache gets first access
israel: I was wondering about how other eventing could plug in?
alex: I want to be very clear
that the service worker will have normative requirement about
... web sites should work with or without a service work
... we hope that others can write mixins
... we have a bug that will explain how to add a no-opt event
... we think this would be an attractive spot for other specs that would want to do background work
... for v1 we expect to move others out (fetch)
... any other qs?
israel: when is the right time to get plugged in?
alex: we have list of issues, but
we are not blocked on anything
... once the wg declares this is a formal activity we can start talking
hober: what about fixme?
alex: I think we are in good shape..
artb: We think that this is part
of app cache and is in scope and will be expanded in the next
... so that we could indeed publish a FPWD in webapps
... any disagreement?
... If anyone objects to doing this publish?
<scribe> ACTION: artb CFC for FPWD for service workers [recorded in http://www.w3.org/2014/04/10-webapps-minutes.html#action10]
<trackbot> Created ACTION-723 - Cfc for fpwd for service workers [on Arthur Barstow - due 2014-04-17].
UNKNOWN_SPEAKER: no one objects
israel: what about media ones?
alex: we have a few ones (rtc,
... we have a design challenge here to handle this types..
... hopefully as the stream apis expand they could be used in another manner
... we fought really hard about promises at tc39, whatwg and this took much longer and am happy to let someone else fight this battle
artb: any more comments of questions about service workers?
israel: Are you sharing code with Moz?
alex: no only working on the design
artb: if nothing else on service workers let's move on..
<ArtB> https://dvcs.w3.org/hg/push/raw-file/tip/index.html -> Push API
bryan: The current editor draft...
* zakim be nice to bryan...
* thank you zakim..
bryan: Their are a number of changes that I listed in the email
<ArtB> http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0108.html -> Bryan's Push API status
Some of the discussion were offline with moz, google
scribe: some are old from last
... in the mean time we have shelved some items..
... add message body
... discussion about supporting other systems but not change the api
... I can go over the changes or introduce them right now
<ArtB> https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&component=Push%20API&resolution=--- -> Bugs for Push API
sicking: I think we should talk about issue with the spec, since walking through each item would take a long time
bryan: I have started to add
service work useage
... I added persistance to registration from TAG feedback
... and some other TAG feedback (express permission)
... does anyone have any comments on this draft spec?
israel: Can you explain how push api uses/relates to service worker
alex: We don't want a page to
live longer that the page is visible
... push should only run when browser is shutdown
... when we surface a push to a tab
... the service work allows use to support both scenarios
... for example should an IFRAME be able to reg for push events?
... this is a good question that I don't think we'll figureout today
israel: From what I was reading, when the app is not running, page loaded the service work acts as a proxy and does the work and waits until UI
<MikeSmith> ArtB, queue
alex: you could image that you
could provide an alert then possibly open/launch the app
... this should be ua dependent
sicking: I just sent to the list
... on the topic of passing additonal things to the service call
... we have concerns with this..
... we have a client side api that we are working on standardized an the server side stopped.
... later we had not use a standard for client side api
... so it seem that this is not really getting standardized
alex: Some push api's require meta data to not get overloaded
<bryan> I would not say that we have given up on standardizing the Push Server API, the message I got from discussions is that this does not seem a short-term opportunity for some operators of Push services.
alex: how is moz going to deal with this?
sicking: I can't comment on how
this would work on android
... the current solution is not a standard, apis are diff and a dev has to use different apis for different devices
alex: chrome for iOS will use an apple environment, but on android it will be differenet
sicking: I don't see how this is a standard solution
alex: sure it is
sicking: it doesn't seem we are creating a standard that is actually a standard
alex: the registration call is optional and ua dependant
<bryan> IMO the detailed variance in the configuration parameters of different systems is analogous to the codec issue in HTML5 video or WebRTC - the API is a mechanism to expose a particular media, in this case a delivery system, that may differ in details opaque to the API, and do in fact require different app/content designs per browser - that is not a show stopper for HTML5, why should it be for
<bryan> this API?
alex: I'd like to hear how you are doing this on android
sicking: I'll have someone follow back with this feedback, the person was not able to attend
<Zakim> bryan, you wanted to ask jonas, by "different APIs", I guess you mean different end-to-end system designs, not the API exposed in the browser, correct?
bryan: what do you mean by
... see my comment in IRC above..
... the systems in place won't get changed right away
... we have apis' that are standardized an will require devs to adopt and change
... html5 video is a good example that we should follow
sicking: I'm not just talking
about northbound api
... I'm taking about southbound apis
... since they now also have to have different apis
bryan: in the browser
alex: are you proposing something?
sicking: we had a proposal and it
got shot down.
... we decided to start with the client side (browser) to start and then it got worse and required this to be changed again
alex: to be clear this in on different systems
bryan: how do you see that these are different
alex: we have a number of
sicking: how does this new stuff
add value as what we had in the past
... different ua's need different stuff to be passed in and required argument is need and will be different
alex: maybe we can have something off navigator
sicking: you'll still end up with differences..
alex: having a standard that covers a large portion in mostly the same way has alot of value
mounir: we are looking to not having to pass a sender id
sicking: at least then we would accomplish something
alex: if we all agree that what you propose then great
<smaug> (html5 video is bad example to follow. It has been a great mess.)
sicking: we are building something that is not a standard and will have to have a big case statement
alex: I agree though in the short term this is a good start
hober: He is asking how this improves over the status quo
<Hixie> smaug: (side note: please tell the <picture> guys that!)
how would one right tests if test has to support different calls for each browser
alex: it's about a better future direction which would at some point require no need to call register
israel: It sounds like you have figure out who and what is supported and then make the calls.
sicking: It seem that this has no value and we should just tell webdev everyone is differend and to expect to use diff calls
hober: what I hear sicking saying is that it seems that we don't need to standardized this small bit given all the other parts are not standardized
bryan: I disagree, we do this in other parts...
sicking: this api has three parts
most complex is the server side
... next is the registration part..
we are giving up on standardizing these two..
scribe: and now that we are giving up the last one..
sicking: I agree that this is
alot like html video
... but it's not working in practice and it's resulting in no video, less video or webdevs resorting to using flash
... But in the video spec the api is quite large and works across various browser
... if it was truely optional and would work then I would be OK
... To be clear it needs to work
alex: well you can call it but it will fail
sicking: the registration calls are a problem
artb: we have exceed the time for this topic so lets wrap it up...
sicking: you have 30 seconds, alex 30 seconds..
artb: thanks and continue on mail list and bugzilla
<bryan> The registerOptions and body are both optional in the current draft - they are intended to be truly that and if there is any reason this optionality is suspect or a problem for developers, let's clarify how. At this point I see little if any problem with the variance in systems between browsers.
<ArtB> http://w3c.github.io/manifest/ -> Manifest spec
marcos: I wanted to open this up
... we are looking at this as an enhancment for webapps
... basically give you base metadata for the app (icons, pin to screen)
Looking at example 1
marcos: it has icons, start url,
... it's just json
... this is where we are at right now..
... the idea of progressing this and open to new asks
... we have tried to keep this simple and it's about as simple as possible
... builds upon metatags from Opera/IE
... also provides fall back to legacy items..
jhazen: Microsoft/IE is indeed
looking at this and we are intrested in these scenarios and
... but also for packaged webapp from the Store on Windows
... at first I think oh yeah and could see adding more items
<tantek> just added rel=manifest as defined in w3c.github.io/manifest section 5.12 to the HTML rel registry: http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions
<genelian_> link: http://w3c.github.io/manifest/
jhazen: I think we need to get agreement on some more items that would be needed
israel: do you expect other extensions to be listed?
... I think we need to cover sync - store manifest vs site manifest
jhazen: we would rather have this
be on the website and have the 'store' suck in this
... not sure how the 'store' platforms work but this seems like the best approach
<chaals> [chaals wonders why we need to handle the store/live content synching, rather than let that be an implementation detail for stores]
benjamp: It seem that if it's in both then it's going to get messy
marcos: that is why we want to work together
sicking: I wanted to share our
plans for this manifest
... we have a store with a manifest version and will update our store with this format
... you need to send our store your manifest
... I'm not sure when/how we re-download this manifest
... but we want to have out package apps to have the same manifests
<chaals> [Sure it gets messy in principle, but that's the store's problem as a trade-off for collecting and reproducing information in the first place (assuming that the store does some kind of checking, and only reflects checked content).]
sicking: we tried in sysapps to standardize the full end to end scenarion and it became to complex so are starting from a smaller use case
jhazen: that is our plan
sicking: indeed this is not fully enough but is a good start
<Zakim> mounir, you wanted to say that Google has plans to implement manifest in Blink
marcos: see the readme it has the v2 goals
artb: one question - the editor doesn't have a link on where to participate?
<chaals> [The widget update spec essentially dealt with this problem, too. Maybe you could copy/paste that for JSON, and then the store's synch becomes a case of what to do with changes and how often to poll (which are implementation decisions, although the latter is presumably related to normal cache management…)]
sicking: public-webapps would be fine
marcos: sure I'll update this..
artb: seems like we have alot of
excitement about this stuff!
... looks like we are all done with this topic for the day..
we'll have coffe now until 3pm
* thanks chaals - doah!
<darobin> rniwa: for calendaring reference, this is fun :) http://www.amazon.com/Calendrical-Calculations-Nachum-Dershowitz-ebook/dp/B00GA22KBE/ref=sr_1_1?ie=UTF8&qid=1397165334&sr=8-1&keywords=calendar+algorithms
<jsbell> Handy IndexedDB "v2" links:
<cwilso> scribenick: cwilso
<ArtB> http://www.w3.org/2008/webapps/wiki/IndexedDatabaseFeatures -> IDB v.Next Features
jsbell: dropped links (above) on
... not comprehensive, but between buglist and wiki, pretty good.
... lots of ideas for things that will require more discussion - full text indexing, etc. We want to write these down in "iDBv2".
jsbell: volunteers as editor,
looks for co-editor: ali raises hand
... if there's anything other features you want to see in there, please contribute.
art: this could be the first time
we've start v2 work, so a couple of questions
... 1) should we issue a call for feature requests?
... 2) we have a relatively large list here, should we prioritize?
... 3) in terms of the spec itself, do you intend to incorporate v1, or have a delta spec?
jsbell: I agree with your questions. On 3, I'd welcome feedback.
art: if we did a copy, we might be duplicating bugs that need to be fixed (in v1 and v2), but would like to hear if anyone has experience doing deltas vs incorporating.
ade: how extensive is what needs to be done? If it's mostly additive, an extension spec would make sense.
jsbell: the v1 spec doesn't really specify extension hooks, unfortunately.
ade: that was my question: if it's changing algorithms...
jsbell: more like inserting steps [in extant algorithms].
jonas: from a spec-writing point of view, since we'd be inserting additional steps, that might be messy. We could try that way and back away if it's too messy.
art: all for letting jsbell and ali experiment.
sicking: when it comes to features, I'd like to see us add features when multiple people agree on the feature.
marcos: is there a feature list? (yes)
jsbell: art is proposing we broadcast that we're starting on the list, ask for prioritization and other features.
<scribe> ACTION: jsbell to broadcast to the list with alia that we're starting on iDB2, ask for prioritization and feature suggestions. [recorded in http://www.w3.org/2014/04/10-webapps-minutes.html#action11]
<trackbot> Created ACTION-724 - Broadcast to the list with alia that we're starting on idb2, ask for prioritization and feature suggestions. [on Joshua Bell - due 2014-04-17].
israelh: what about Promise compatibility?
jsbell: current model is pretty tied to event model. It may be fairly extensive changes, although there is the desire to do it. We don't have an answer yet.
israelh: we've talked about iDB as the API to be used for caching (e.g. offline). Have you seen adoption of this pattern? The Outlook Web Access uses ??? to cache. Have you seen similar patterns?
jsbell: Google Docs uses it to cache for offline and editing.
marcos: met with a team who had problems because they couldn't batch the way they wanted to, so it was too slow.
jsbell: jonas and I were having a
conversation about this before - promises might naively push
people into this .then().then().then() pattern...
... but promises.all would enable this. We should have this on the list - batching.
action on jsbell to add batching to the wiki list.
<trackbot> Error finding 'on'. You can review and register nicknames at <http://www.w3.org/2008/webapps/track/users>.
action jsbell to add batching to the wiki list.
<trackbot> Created ACTION-725 - Add batching to the wiki list. [on Joshua Bell - due 2014-04-17].
israelh: when we set out to do indexeddb, we expected that libraries would be built on top of idb primitives as abstractions. Curious if that's happened.
jsbell: should have a good answer to this, but don't right now. No one super-successful library that I know of.
sicking: WRT the main things we've seen requests for: getting update notifications, mostly small things like opening a key cursor on an object store and performance.
jsbell: also, the fact that clear browsing data wipes iDB has forced some other notifications we've done, want to get those documented.
israelh: one more last question: how are you thinking about max limits?
sicking: what matters is the usage, we don't want to limit rows per store, but we do need to limit total store size, cache size,.... unified quota.
slightlyoff: would like to see an API that lets us see how much quota you're "paying" for.
jsbell: should be able to prioritize frequently visited sites, etc., too.
<mounir> https://dvcs.w3.org/hg/screen-orientation/raw-file/tip/Overview.html -> Screen Orientation API
<mounir> https://www.w3.org/Bugs/Public/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=Screen%20Orientation&list_id=34844&product=WebAppsWG -> open bugs for screen orientation
<ArtB> http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0038.html -> Mounir's Screen Orientation status
mounir: last week I updated the
specs to reflect requests (e.g. from Mozilla)
... if you have any questions or implementation feedback, please speak up
sicking: test suite?
marcos: I'm working on that.
sicking: I'd be excited to remove our prefix.
israelh: I think we're in the same boat as Mozilla WRT locking.
mounir: now you can lock to any of four types; not arbitrary angle.
sicking: other feedback I don't
feel quite as strongly about: some websites assume angle=0
means portrait. On many tablets, zero is actually landscape; so
implementation may force you to hold device in the wrong
... my understanding is the use case for the angle is to add that to device orientation events, so you get an orientation relative to the device not the screen (?)
mounir: not sure how to respond to that feedback.
sicking: don't call it
orientation, call it something else
... but don't break back compat.
marcos: I believe this is possible
mounir: <expresses skepticism at the size of the necessary monkeypatch> :)
tantek: what's the use case driving this feedback?
mounir: I get many small use cases for angle: only real strong use case was device orientation will give you angle to the screen, but if your screen is in a different mode "up" means something else. (?)
tantek: if so, expose the lock state.
mounir: no, you want to expose the angle the screen's currently on
sicking: the use case here is if
you have a racing game where you tilt the screen; if the screen
is unlocked, if the user holds the device one way you'll get
orientation events one way you get events in the range 85-95,
flipped the other way 265-275
... now that it's been shipping for a few years we can't change it.
mounir: do we expose an angle
that lets developers correct for it, or do we expose a new set
of events that works the right way?
... maybe we should do both.
... in case there's something else they want to do with the angle.
sicking: except people will do silly things with it.
mounir: you're concerned people
will read angle instead of type
... ? they do that today because they don't have an option.
sicking: I don't share your
... we should definitely give enough rope for people to hang themselves, unless we're only giving them the rope in order TO hang themselves.
... unless we have a strong use case, we should just do both events and figure people who would need this use case can subtract angles.
israelh: seems like people would want to see the native orientation of the screen.
mounir: you can get this from
type and angle.
... not sure what the purpose is; this is pretty easy to determine.
israelh: just seems like most APIs that do this expose the native orientation.
marcos: cheap and easy! Instant win!
mounir: it's ONE LINE, dude!
sicking: it's not even a new event, it's one property. It's wafer-thin.
mounir: <you have failed to beat me into submission yet>
sicking: it should be easier to do the right thing.
mounir: I would prefer if we
consider these issues as orthogonal.
... most systems can't tell what the default orientation is, particularly when locked. that's why I shied away from exposing here.
art: were there other points to raise, other questions? Only other thing I had was a message from Lars...
art: someone from the group should reply to Lars. Marcos, did you agree to reply?
marcos: I think I told him before the core IG would take that up, because I think that is quite vital.
<scribe> ACTION: marcos to reply to Lars [recorded in http://www.w3.org/2014/04/10-webapps-minutes.html#action12]
<trackbot> Created ACTION-726 - Reply to lars [on Marcos Caceres - due 2014-04-17].
art: I think we're done with this topic, then.
<hober> Hixie: ^^
<ArtB> http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0442.html -> Discusion on p-webapps
art: there was some discussion in
Shenzhen about WWv2; Travis agreed to take up the action, but
nothing much occurred.
... don't know what the priority of this would be.
adrianba: I think the concern at SZ was that we were getting blocked on shared workers, so wanted to crack that out; but that seems to have unblocked.
sicking: we don't have event source at all in workers; somewhat behind on shared workers
art: what should we talk about? you guys wanted to add this.
sicking: interested in blob:
situation, don't know if that needs v2 or just
... interested in synchronous message passing for dedicated workers; don't need if that needs further discussion, since we are the only ones that have committed to implement.
sicking: maybe it's too early to start a v2 at this point, just need to clarify the blob: url conversation.
art: sounds like we're done with
this topic, then.
... only other topic for today was administrative stuff:
robin: I volunteer to scribe tomorrow morning.
<scribe> scribenick: mounir
ArtB: I don't think there is anything else than Web Components... anything else?
ArtB: ok, lets do Web Components tomorrow
marcos: there are a bunch of spec
copying from another standards
... organization to this organization and they fall out of date
... anything people search for stuff they end up looking
... at the wrong specification
... the idea is to have "one spec to rule them all"
ArtB: is it a webapp specific issue?
marcos: yes, because webapps in the worse offender
ArtB: can we quantify that?
marcos: I would like people to voice their concerns
darobin: I agree it is a problem
Yves: is it a problem because specs are no longer up to date?
marcos: the spec on TR is from
2012 but was updated a lot
... since then and its hard to know if its up to date or not
... generally speaking
ArtB: I agree that it's not
really... there is a general problem
... we might want to have a rule that say that we should not
... do this anymore in webapps unless someone commit to
... keep it out of date
tantek: it's a waste of time
ArtB: maybe we could say in the
header that we would never
... publish this thing ever again until the spec is updated?
darobin: I agree it's probably
the best we can do at the
... webapps level but we could do better at the w3c level
... if you are interested, feel free to contact me or tantek
... we are looking for input and suggestions
tantek: marcos, we should list
the different issues to find
... solutions because some might be easy and some hard
... for example, changing google search results
marcos: we had issues with specs
being rejected because they
... were referring whatwg specs
tantek: I believe we work on that
at a AB level
... for example, if there is a reference in mounir's spec
... to an old spec, we should fix that
... I think that we should not find an editor just for
... copying whatwg specs, it's a waste of time
ArtB: I haven't said it's a good option, but that it is an option
tantek: this said, it's worth
noting that having WD
... helps with IP stuff so we might want that
... I don't know of any other steps?
phl: it's actually when most of the IPR happens
ArtB: something we could do is
having something in the spec
... saying "we are only publishing this for attorneys, if you
... are not an attorney, look at this instead"
... I'm not saying it's a good option but it's a solution
ryosuke: linking to the latest
spec isn't always the right
... thing because sometimes you want to link to something
... that are also two years old
marcos: as an editor, it's your
responsibility to check
... for reference changes
... the entire points to version thing is not a good idea
ArtB: any other comments about
that particular topic?
... any other admin stuff?
... that will be it for today, thanks everyone
<ArtB> Scribe: Art, Philippe, KrisK, ChrisW, Robin, Adrian, Mounir
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/ize/izing/ Succeeded: s/last &sysreq// Succeeded: s/woth/with/ Succeeded: s/Koshi/Kochi/ Succeeded: s/URL// Succeeded: s/Zhihang/zqzhang/ Succeeded: s/Web IDL/URL/ Succeeded: s/weel/well/ Succeeded: s/ккыфпутеб вкфае ьштгеуы// Succeeded: s/we have to look again/overall we generally like the look of it/ Succeeded: s/AAA:/Taiju:/ Succeeded: s/can comment/can't comment/ Succeeded: s/to call register/to pass a sender id/ Succeeded: s/possile/possible/ Succeeded: s/these/deltas vs incorporating/ Succeeded: s/change/update/ Succeeded: s/any of four angles/any of four types/ Succeeded: s/at all/at all in workers/ Succeeded: s/.. I/... I/ Found Scribe: Art Found ScribeNick: ArtB Found Scribe: plh Inferring ScribeNick: plh Found ScribeNick: adrianba Found Scribe: krisk Inferring ScribeNick: krisk Found ScribeNick: cwilso Found ScribeNick: mounir Found Scribe: Art, Philippe, KrisK, ChrisW, Robin, Adrian, Mounir Scribes: Art, plh, krisk, Art, Philippe, KrisK, ChrisW, Robin, Adrian, Mounir ScribeNicks: ArtB, plh, adrianba, krisk, cwilso, mounir Default Present: [Paypal], Olli_Pettay, Bryan_Sullivan, arunranga, +1.425.264.aaaa, bryan, +1.650.946.aabb, Bin_Hu Present: Adrian_Bateman Ali_Alabbas Arnaud_Braud Art_Barstow Ben_Peters Dave_Raggett Feras_Moussa Glenn_Adams Hiroyuki_Aizu Israel_Hilerio John_Hazen Laszlo_Gombos MikeSmith Mounir_Lamouri Philippe_Le_Hegaret Phillipe_LeHegaret Robin_Berjon Ryoskue_Niwa Takeshi_Yoshino Yves_Lafon krisk Anssi_Kostiainen Zhiqiang_Zhang Matt_Falkenhagen Dominic_Cooney Jungkee_Song Bryan_Sullivan opoto Janusz_Majnert Wonsuk_Lee Xiaoqian Jinsong Zhiqiang Baoping Tantek Ted Brad Jonas Dimitry arunranga Chris_Wilson Alex_Russell Chaals_Neville(remote) Joshua_Bell Ted_OConnor Regrets: Chaals Agenda: https://www.w3.org/wiki/Webapps/April2014Meeting Got date from IRC log name: 10 Apr 2014 Guessing minutes URL: http://www.w3.org/2014/04/10-webapps-minutes.html People with action items: art artb barstow charter draft jsbell kris krisk marcos robin s tyoshino update webapp[End of scribe.perl diagnostic output]