Re: [whatwg] Fullscreen events dispatched to elements
What do you do when element A goes fullscreen and then element B in the same document goes fullscreen on top of it? Do you fire a single fullscreenchange event at B? Or do you fire a fullscreenchange event at A and then at B? Or something else? Rob -- “You have heard that it was said, ‘Love your neighbor and hate your enemy.’ But I tell you, love your enemies and pray for those who persecute you, that you may be children of your Father in heaven. ... If you love those who love you, what reward will you get? Are not even the tax collectors doing that? And if you greet only your own people, what are you doing more than others? [Matthew 5:43-47]
Re: Feedback on Quota Management API
Based on the feedbacks I've updated the draft: http://dvcs.w3.org/hg/quota/raw-file/tip/Overview.html - Got rid of string enum, instead introduced navigator.persistentStorage and navigator.temporaryStorage - Some interface name changes (just for IDL) QuotaStorageEnvironment - StorageQuotaEnvironment StorageInfo - StorageQuota StorageInfoQuotaCallback - StorageQuotaCallback StorageInfoUsageCallback - StorageUsageCallback StorageInfoErrorCallback - StorageErrorCallback I'd like to finalize these naming/interface details while we're here. On Tue, Jun 5, 2012 at 10:03 PM, Kinuko Yasuda kin...@chromium.org wrote: On Mon, Jun 4, 2012 at 6:30 PM, Tobie Langel to...@fb.com wrote: On 6/4/12 11:17 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Jun 4, 2012 at 11:01 AM, Tobie Langel to...@fb.com wrote: Finally, I feel it's slightly misleading to have an interface called info which enables changes (through `requestQuota`). Wouldn't settings or similar be more appropriate? As in: navigator.persistentStorageSettings.queryUsageAndQuota navigator.persistentStorageSettings.requestQuota Thoughts? That seems way long. navigator.storage would be better I think. Or even defining the relevant methods directly on navigator. Agreed. Whether you're targeting persistent or temp storage still needs to appear somewhere, however. So it's either: navigator.persistentStorage.requestQuota or: navigator.storage.requestPersistentQuota or: navigator.requestPersistent(Storage)Quota I'd favor the first one. I like the first one too. The third one sounds neat too but it may become too long for queryUsageAndQuota one (if we include Storage part). By the way even if we take navigator.persistentStorage or persistent.storage I'd still like to avoid using the name 'Storage' for the interface name (which would appear only on IDL), since we use the name for Web Storage and it's confusing. Maybe we could use StorageSettings for the interface name? Or how about StorageQuota (and renaming QuotaStorageEnv to StorageQuotaEnv)? Actually I like the latter one since it's shorter and reflects the API name better. --tobie
Re: Feedback on Quota Management API
On Wed, Jun 6, 2012 at 8:33 AM, Kinuko Yasuda kin...@chromium.org wrote: http://dvcs.w3.org/hg/quota/raw-file/tip/Overview.html I noticed something unrelated to the naming. Because you define asynchronous callbacks, you need to define the methods in terms of the HTML event loop. Otherwise it is unclear how they are invoked relative to other tasks. http://wiki.whatwg.org/wiki/Howto_spec#Callbacks has limited advice on how to do this. (Suggestions on how to improve that wiki page are welcome.) -- Anne — Opera Software http://annevankesteren.nl/ http://www.opera.com/
Re: Feedback on Quota Management API
On Wed, Jun 6, 2012 at 4:27 PM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Jun 6, 2012 at 8:33 AM, Kinuko Yasuda kin...@chromium.org wrote: http://dvcs.w3.org/hg/quota/raw-file/tip/Overview.html I noticed something unrelated to the naming. Because you define asynchronous callbacks, you need to define the methods in terms of the HTML event loop. Otherwise it is unclear how they are invoked relative to other tasks. http://wiki.whatwg.org/wiki/Howto_spec#Callbacks has limited advice on how to do this. (Suggestions on how to improve that wiki page are welcome.) Thanks, ok I will try adding the event loop description and will update this list again. -- Anne — Opera Software http://annevankesteren.nl/ http://www.opera.com/
Re: Feedback on Quota Management API
On 6/6/12 8:33 AM, Kinuko Yasuda kin...@chromium.org wrote: Based on the feedbacks I've updated the draft: http://dvcs.w3.org/hg/quota/raw-file/tip/Overview.html - Got rid of string enum, instead introduced navigator.persistentStorage and navigator.temporaryStorage - Some interface name changes (just for IDL) QuotaStorageEnvironment - StorageQuotaEnvironment StorageInfo - StorageQuota StorageInfoQuotaCallback - StorageQuotaCallback StorageInfoUsageCallback - StorageUsageCallback StorageInfoErrorCallback - StorageErrorCallback I'd like to finalize these naming/interface details while we're here. Thanks for making those changes. This is shaping up quite nicely. I still think queryUsageAndStorage is quite a mouthful but can't think of anything more succinct for now. --tobie
Re: [manifest] Is the Webapp Manifest spec ready for FPWD?
On 6/6/12 2:10 AM, Arthur Barstow art.bars...@nokia.com wrote: I don't recall the group discussing the UCs and requirements the spec addresses. Perhaps it would also be useful to step back a bit and try to get agreement on some high level requirements before proceeding. Agreed. --tobie
Re: [manifest] Is the Webapp Manifest spec ready for FPWD?
On 6 Jun 2012, at 01:10, Arthur Barstow wrote: On 5/30/12 2:36 PM, ext Arthur Barstow wrote: What are people's thoughts on whether or not the Quota Management API spec is ready for First Public Working Draft (FPWD)? (Ooops, cp error above: s/Quota Management/Webapp Manifest/) A rule of thumb for FPWD is that the ED's scope should cover most of the expected functionality although the depth of some functionality may be very shallow, and it is OK if the ED has some open bugs/issues. In addition to the above, one of the side effects of the publication of a FPWD is that it starts the spec's first Call for (patent) Exclusions (see [CfE] for details). Consequently, the FPWD should contain enough information regarding its scope to facilitate a patent search. I mention this because Adam (and others) raised concerns the ED makes some implicit assumptions about the security model. I don't think that concern is necessarily a showstopper for the FPWD. However, such comments indicate to me the spec's scope isn't quite fleshed out yet, at least regarding security considerations. It would be useful for the ED to be more explicit about the concerns that have raised. For example, the ED could contain some type of Issue block and point to this thread. I don't recall the group discussing the UCs and requirements the spec addresses. Perhaps it would also be useful to step back a bit and try to get agreement on some high level requirements before proceeding. (Marcos' requirements document for widgets could provide some useful info [Widget-Reqs].) WDYT? Having looked again at this, I think the easiest approach would not be to publish WebApp Manifest as is, but simply to publish a new draft of the Widget Interface[1] and do a search/replace on widget with webapp. We can then add a section on JSON serialization as a manifest media type, and then take each of the proposed model extensions from Mozilla on their own merit. For compatibility with existing Widgets implementations, all you then need is: window.webapp = window.widget (or vice versa) -AB [CfE] http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Exclusion [Widget-Reqs] http://www.w3.org/TR/widgets-reqs/ [1] http://www.w3.org/TR/widgets-apis/
Re: Publish FPWD of Web Intents spec; deadline June 12
On 06/06/2012 02:26 AM, Greg Billock wrote: On Tue, May 29, 2012 at 10:48 PM, Deepanshu Gautam deepanshu.gau...@huawei.com wrote: Please refer to the email thread below http://lists.w3.org/Archives/Public/public-web-intents/2012May/0054.html Where a consensus was reached to delete the following statement from the Suggestions related text. The User Agent should ignore the suggested services from the intent invocation if the user already has a handler selected. I would like that statement to be delete before FPWD. This is done in my local version. I have a collection of edits that have been suggested as people have looked at the draft more closely. I've been holding off submitting them to maintain a stable version. Shall I go ahead and submit the edited version? Please do; there's no point in holding off clear improvements. Thanks Ms2ger
Re: [manifest] Is the Webapp Manifest spec ready for FPWD?
On 6/6/12 10:27 AM, Scott Wilson scott.bradley.wil...@gmail.com wrote: Having looked again at this, I think the easiest approach would not be to publish WebApp Manifest as is, but simply to publish a new draft of the Widget Interface[1] and do a search/replace on widget with webapp. Republishing the same spec with only this modification and observing adoption would be an interesting social experiment in itself. But I digress. We can then add a section on JSON serialization as a manifest media type, and then take each of the proposed model extensions from Mozilla on their own merit. That shouldn't prevent us from looking at use cases and requirements. Mozilla's proposal seems to essentially target applications distributed through app stores. We'd like to see a solution that also enables providing meta data to bookmarked apps similar to how meta tags work in iOS. --tobie
Re: Implied Context Parsing (DocumentFragment.innerHTML, or similar) proposal details to be sorted out
On Fri, Jun 1, 2012 at 10:25 AM, Jonas Sicking jo...@sicking.cc wrote: I think the SVG working group should learn to stand by its past mistakes. Not standing by them in the sense of thinking the past mistakes are great but in the sense of not causing further disturbances by flip-flopping. For what it's worth, I've not seen any flip-floppying on this. Over the years that I've asked the SVG WG the detailed question on if they prefer to have the parsing model for scripts in SVG-in-HTML I've consistently gotten the answer that they prefer this. At the time when SVG parsing was being added to text/html, vocal members of the SVG working group were adamant that parsing should work the same as for XML so that output from existing tools that had XML serializers could be copied and pasted into text/html in a text editor. Suggestions went as far as insisting a full XML parser be embedded inside the HTML parser. For [citation needed], see e.g. Requirement 1 in http://lists.w3.org/Archives/Public/public-html/2009Mar/0216.html (not the only place where the requirement was expressed but the first one I found when searching the archives) and requirements 1 and 2 as well as the first sentence under Summary in http://dev.w3.org/SVG/proposals/svg-html/svg-html-proposal.html . I'm also not sure how this is at all relevant here given that we should do what's best for authors, even when we learn over time what's best for authors. At this point, what's best for authors includes considerations of consistent behavior across already-deployed browsers (including IE9, soon IE10 and the Android stock browser) and future browsers. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [webcomponents] HTML Parsing and the template element
On Tue, Jun 5, 2012 at 12:42 AM, Ian Hickson i...@hixie.ch wrote: On Wed, 4 Apr 2012, Rafael Weinstein wrote: On Mon, Apr 2, 2012 at 3:21 PM, Dimitri Glazkov dglaz...@chromium.org wrote: Perhaps lost among other updates was the fact that I've gotten the first draft of HTML Templates spec out: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html I think the task previously was to show how dramatic the changes to the parser would need to be. Talking to Dimitri, it sounds to me like they turned out to be less open-heart-surgery and more quick outpatient procedure. Adam, Hixie, Henri, how do you guys feel about the invasiveness of the parser changes that Dimitri has turned out here? I think it's more or less ok, but it has the problem that it doesn't give a way to reset the insertion mode again while inside a template. I still think that breaking the old correspondence between markup and the DOM and shrugging the XML side off is a big mistake. Why would it be substantially harder to check inertness by walking the parent chain (which normally won't be excessively long) as opposed to checking a flag on the owner document? I strongly believe that this template contents should be children of the template element in the DOM instead of being behind a special wormhole to another document while parsing and serializing as if the special wormhole wasn't there. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
CfC: publish FPWD of Quota Management API; deadline June 13
Having seen no negative responses to the Is the Quota Management API spec ready for FPWD? thread [1], this is a Call for Consensus (CfC) to publish a First Public Working Draft (FPWD) of the Quota Management API using the following ED as the basis of the FPWD: https://dvcs.w3.org/hg/quota/raw-file/tip/Overview.html This CfC satisfies the group's requirement to record the group's decision to request advancement. By publishing this FPWD, the group sends a signal to the community to begin reviewing the document. The FPWD reflects where the group is on this specification at the time of publication; it does not necessarily mean there is consensus on the specification's contents. Please send all comments regarding this CfC to the public-webapps@w3.org mail list by June 13. Please note silence will be considered as agreement with the proposal. If you support this CfC, a positive response is preferred and encouraged. -Thanks, AB [1] http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0940.html
Re: [manifest] screen sizes, Re: Review of Web Application Manifest Format and Management APIs
On Sun, May 27, 2012 at 7:45 PM, Anant Narayanan an...@mozilla.com wrote: Well, we haven't received this request from developers explicitly yet, but one can imagine a situation in which a developer makes an app only for mobile phones (Instagram?) and doesn't want users to use it on desktops. Even though it'll technically work, it might look ugly due to scaling. Shouldn't it be up to the user to refrain from using ugly apps instead of the developer preventing them? -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [manifest] Is the Webapp Manifest spec ready for FPWD?
On Wednesday, June 6, 2012 at 9:51 AM, Tobie Langel wrote: Mozilla's proposal seems to essentially target applications distributed through app stores. We'd like to see a solution that also enables providing meta data to bookmarked apps similar to how meta tags work in iOS. I've not much experience with the iOS meta tags, so is there anything missing in W3C Widget's config.xml or in Moz's JSON? Would be cool if one could just do: !-- gimme config in accepted format (xml or json) -- meta config=/config That way, there is no need to repeat meta tags in every page... just repeat it once… or doing something like a fav.ico equivalent that is loaded automagically. … just random thoughts.. -- Marcos Caceres
Re: [manifest] Is the Webapp Manifest spec ready for FPWD?
On 6/6/12 3:35 PM, Marcos Caceres w...@marcosc.com wrote: On Wednesday, June 6, 2012 at 9:51 AM, Tobie Langel wrote: Mozilla's proposal seems to essentially target applications distributed through app stores. We'd like to see a solution that also enables providing meta data to bookmarked apps similar to how meta tags work in iOS. I've not much experience with the iOS meta tags, so is there anything missing in W3C Widget's config.xml or in Moz's JSON? Not in the configuration file itself (what Mozilla calls the Web Application Manifest), but it is not specified how it is delivered to the client in that case. Would be cool if one could just do: !-- gimme config in accepted format (xml or json) -- meta config=/config That way, there is no need to repeat meta tags in every page... just repeat it onceŠ Absolutely, or: html manifest=/path/to/config.webapp and combine appcache and config into a single format. The AppCache manifest format works beautifully in JSON (and I'm sure it would do equally well in XML). See how the sample manifest files provided in the HTML5 spec[1] would look like in JSON: https://gist.github.com/2881982 or doing something like a fav.ico equivalent that is loaded automagically. I'd rather we avoided simultaneously adding an extra http request to all the web pages in the world **and** filling server logs with garbage 404 requests. --tobie --- [1]: http://www.w3.org/TR/html5/offline.html#some-sample-manifests
Re: [manifest] Is the Webapp Manifest spec ready for FPWD?
On Wednesday, June 6, 2012 at 2:58 PM, Tobie Langel wrote: On 6/6/12 3:35 PM, Marcos Caceres w...@marcosc.com (mailto:w...@marcosc.com) wrote: On Wednesday, June 6, 2012 at 9:51 AM, Tobie Langel wrote: Mozilla's proposal seems to essentially target applications distributed through app stores. We'd like to see a solution that also enables providing meta data to bookmarked apps similar to how meta tags work in iOS. I've not much experience with the iOS meta tags, so is there anything missing in W3C Widget's config.xml or in Moz's JSON? Not in the configuration file itself (what Mozilla calls the Web Application Manifest), but it is not specified how it is delivered to the client in that case. Ok, well, at least we potentially have most of the bits we need. Would be cool if one could just do: !-- gimme config in accepted format (xml or json) -- meta config=/config That way, there is no need to repeat meta tags in every page... just repeat it onceŠ Absolutely, or: html manifest=/path/to/config.webapp and combine appcache and config into a single format. The AppCache manifest format works beautifully in JSON (and I'm sure it would do equally well in XML). See how the sample manifest files provided in the HTML5 spec[1] would look like in JSON: https://gist.github.com/2881982 yep, that could also work… though I wonder if it's too late to be swapping manifest formats. or doing something like a fav.ico equivalent that is loaded automagically. I'd rather we avoided simultaneously adding an extra http request to all the web pages in the world **and** filling server logs with garbage 404 requests. True. Spectacularly dumb idea. Is there a way to undo what I said? :)
Re: [manifest] Is the Webapp Manifest spec ready for FPWD?
On 6/6/12 5:02 PM, Marcos Caceres w...@marcosc.com wrote: On Wednesday, June 6, 2012 at 2:58 PM, Tobie Langel wrote: Absolutely, or: html manifest=/path/to/config.webapp and combine appcache and config into a single format. The AppCache manifest format works beautifully in JSON (and I'm sure it would do equally well in XML). See how the sample manifest files provided in the HTML5 spec[1] would look like in JSON: https://gist.github.com/2881982 yep, that could also workŠ though I wonder if it's too late to be swapping manifest formats. The two manifest formats could very well co-existing. Furthermore, since only the structure of the data differs, the AppCache algorithm wouldn't need to change. --tobie
Re: Implied Context Parsing (DocumentFragment.innerHTML, or similar) proposal details to be sorted out
On Wed, Jun 6, 2012 at 3:42 AM, Henri Sivonen hsivo...@iki.fi wrote: On Fri, Jun 1, 2012 at 10:25 AM, Jonas Sicking jo...@sicking.cc wrote: I think the SVG working group should learn to stand by its past mistakes. Not standing by them in the sense of thinking the past mistakes are great but in the sense of not causing further disturbances by flip-flopping. For what it's worth, I've not seen any flip-floppying on this. Over the years that I've asked the SVG WG the detailed question on if they prefer to have the parsing model for scripts in SVG-in-HTML I've consistently gotten the answer that they prefer this. At the time when SVG parsing was being added to text/html, vocal members of the SVG working group were adamant that parsing should work the same as for XML so that output from existing tools that had XML serializers could be copied and pasted into text/html in a text editor. Suggestions went as far as insisting a full XML parser be embedded inside the HTML parser. For [citation needed], see e.g. Requirement 1 in http://lists.w3.org/Archives/Public/public-html/2009Mar/0216.html (not the only place where the requirement was expressed but the first one I found when searching the archives) and requirements 1 and 2 as well as the first sentence under Summary in http://dev.w3.org/SVG/proposals/svg-html/svg-html-proposal.html . I'm also not sure how this is at all relevant here given that we should do what's best for authors, even when we learn over time what's best for authors. At this point, what's best for authors includes considerations of consistent behavior across already-deployed browsers (including IE9, soon IE10 and the Android stock browser) and future browsers. Considering compatible behavior is indeed part of what's best for authors, but we shouldn't extend that to blanket denials of the possibility of change. Flip-flopping is irrelevant. Only what is good for authors is. If deployed content would break as a result of a change, we either find a new way to accommodate the desired change, or drop it. But we need the compat data about that breakage before we can claim that it will occur. The SVGWG would like to make things as good for authors as possible. Past positions don't matter, except insofar as the history of their effects on the specs persists. Compat breakage is painful, but so is manifestly hard-to-use incompatibilities between HTML and SVG. Let's fix those as much as we can. ~TJ
RE: Push API draft uploaded
Comment inline. Thanks, Bryan Sullivan -Original Message- From: Tobie Langel [mailto:to...@fb.com] Sent: Tuesday, June 05, 2012 12:28 PM To: Mounir Lamouri; public-webapps@w3.org Subject: Re: Push API draft uploaded On 6/5/12 4:00 PM, Mounir Lamouri mou...@lamouri.fr wrote: On 05/31/2012 03:28 PM, Tobie Langel wrote: I'm probably missing something here, but notifications don't seem to be going through a system- / browser-wide notification panel from which the user can decide whether or not to navigate to an application. In other words, it looks like we're considering server -- app push notifications, rather than server -- user push notifications. If that's case, how are we planning to handle waking up application A without disrupting the experience of the user currently busy using application B in the foreground (thinking essentially of mobile here)? Are we going to wake up application B but run it as a background app? If so, where is that behavior defined? Is that akin to a WebWorker or more of a headless window? What's the life-cycle of such an app? Also, how can this app alert the user that it has something new for him? Do we also have system level notifications in the work? If a given notification's sole purpose is to advise the user of some information he may or not want to act upon (e.g.: you have new mail), what are the benefits of waking up the application (or even spawning a worker) to do so? That seems like it would drain the battery of mobile devices for little purpose. Finally, aren't we conflating the notion of background work following a remote server or system event with that of push notification to the user? An example of background work following a remote server event would be the background update of daily news for a newspaper application. A remote server would send an event to the system / browser which itself would launch a WebWorker, that worker would perform the necessary io to upload the fresh content and save it in a db. An example of background work following a system event would be a location change event spawning a background worker which itself either stored the coordinates in a db or sent them to a remote server, e.g. for a cycling app tracking your rides. Example of push notifications for the user are things like You've got a new message, It's Emma's birthday today, etc. The user can decide to act upon them (i.e. follow the provided link) or not, but until he does, there's no reason to launch an app or even a worker. Note that similar notifications would also need to be issued by background workers / windows. E.g. The worker spawned above to upload fresh content for the newspaper app would be able to send a notification to the user when it's done (e.g. Today's news are been downloaded.) Sorry if the above feels a bit like a brain dump. I'm really struggling to understand the scope of this proposal. :-/ Actually, our System Message API [1] seems to answer most of those questions: an application will be able to specify a worker or a page to use when handling a message so it will be able to just run stuff in the background and depending on what happened do something like show a notification (via Desktop Notifications) or update a DB, or whatever. [1] https://groups.google.com/group/mozilla.dev.webapi/browse_thread/thread/a3 c6e4c31d04b663/ Thanks for the link! While it's possible to display push notifications to the user via this proposal (push notification spawns a worker which notifies the user via Desktop Notification), on mobile it's probably a quantifiable waste of battery life compared to push notifications that are directly aimed at the user. For applications built in a more traditional way (with server side rendering, etc.), it still feels like providing the data in query params should be investigated before it's dismissed. Overall, I feel like writing down use cases and requirements would be something useful to do at this point. What do you think? bryan Here is the thread for the set of use cases I submitted for this API during the rechartering: http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0008.html. Additional use cases are welcome, and we can capture them and derived requirements on the Webapps wiki. I created a page for this: http://www.w3.org/2008/webapps/wiki/Push_API --tobie
Re: [webcomponents] HTML Parsing and the template element
On Wed, Jun 6, 2012 at 3:50 AM, Henri Sivonen hsivo...@iki.fi wrote:
On Tue, Jun 5, 2012 at 12:42 AM, Ian Hickson i...@hixie.ch wrote:
On Wed, 4 Apr 2012, Rafael Weinstein wrote:
On Mon, Apr 2, 2012 at 3:21 PM, Dimitri Glazkov dglaz...@chromium.org
wrote:
Perhaps lost among other updates was the fact that I've gotten the
first draft of HTML Templates spec out:
http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html
I think the task previously was to show how dramatic the changes to the
parser would need to be. Talking to Dimitri, it sounds to me like they
turned out to be less open-heart-surgery and more quick outpatient
procedure. Adam, Hixie, Henri, how do you guys feel about the
invasiveness of the parser changes that Dimitri has turned out here?
I think it's more or less ok, but it has the problem that it doesn't give
a way to reset the insertion mode again while inside a template.
I still think that breaking the old correspondence between markup and
the DOM and shrugging the XML side off is a big mistake. Why would it
be substantially harder to check inertness by walking the parent chain
(which normally won't be excessively long) as opposed to checking a
flag on the owner document?
I strongly believe that this template contents should be children of
the template element in the DOM instead of being behind a special
wormhole to another document while parsing and serializing as if the
special wormhole wasn't there.
This has pretty bad usability pitfalls.
A template like this:
template
pStamp out copies of me!/p
/template
...is morally equivalent to this:
script type=text/template
pStamp out copies of me!/p
/script
Which is to say, neither of them actually represent page content.
They represent templates of such, which will be used to produce
actual page content.
A call like document.querySelectorAll('p') doesn't *want* to get the
p inside the template. It'll be doing processing on paragraphs in
the page, real paragraph filled with content. Similarly with class
selectors, or other things of similar nature. An id selector probably
*does* want to grab the template element, but using ids inside of a
template is a bad idea anyway, since it will produce multiple elements
with the same id.
The only way to avoid this kind of matching is either to only link in
templates externally, expect all authors to qualify their selectors
sufficiently to never include a template element, or somehow hide the
contents from selectors applied to the main document.
I think the first is bad, I doubt anyone would reasonably think the
second would happen, and so the third is necessary. I think the
current plan (to stash the contents of a template into a document
fragment) is a decent way to accomplish this. Another alternative is
to simply state that they don't match selectors with a scope rooted
higher than their template.
~TJ
Re: Publish FPWD of Web Intents spec; deadline June 12
Done. Thanks for the reality check. :-) On Wed, Jun 6, 2012 at 1:35 AM, Ms2ger ms2...@gmail.com wrote: On 06/06/2012 02:26 AM, Greg Billock wrote: On Tue, May 29, 2012 at 10:48 PM, Deepanshu Gautam deepanshu.gau...@huawei.com wrote: Please refer to the email thread below http://lists.w3.org/Archives/Public/public-web-intents/2012May/0054.html Where a consensus was reached to delete the following statement from the Suggestions related text. The User Agent should ignore the suggested services from the intent invocation if the user already has a handler selected. I would like that statement to be delete before FPWD. This is done in my local version. I have a collection of edits that have been suggested as people have looked at the draft more closely. I've been holding off submitting them to maintain a stable version. Shall I go ahead and submit the edited version? Please do; there's no point in holding off clear improvements. Thanks Ms2ger
Re: [manifest] Is the Webapp Manifest spec ready for FPWD?
On 6 Jun 2012, at 16:10, Tobie Langel wrote: On 6/6/12 5:02 PM, Marcos Caceres w...@marcosc.com wrote: On Wednesday, June 6, 2012 at 2:58 PM, Tobie Langel wrote: Absolutely, or: html manifest=/path/to/config.webapp and combine appcache and config into a single format. The AppCache manifest format works beautifully in JSON (and I'm sure it would do equally well in XML). See how the sample manifest files provided in the HTML5 spec[1] would look like in JSON: https://gist.github.com/2881982 yep, that could also workŠ though I wonder if it's too late to be swapping manifest formats. The two manifest formats could very well co-existing. Furthermore, since only the structure of the data differs, the AppCache algorithm wouldn't need to change. This seems like a pretty convincing use-case for obtaining web app metadata, and extends the existing practices of iOS meta tags and .ico files (both of which are kludges in their own way). The core metadata seems also pretty simple and uncontroversial: id version shortName name description author (aka developer) authorEmail authorHref (aka developer.url) content (aka launch_path) feature (aka required_feature) license We then have some sections that may or may not need some more work: === Locales and localization === This is pretty close to the approach used in Widgets and maps quite nicely, including defaultlocale attribute. === Icons === Responsive images in general are still quite painful to handle, and I know we sort of ducked this one in Widgets. There is also divergence even on aspect ratios (OpenSocial uses 2:1 rather than square, for example.) There have been some discussions on this topic and related areas such as screenshots (cf Native Web Apps and PhoneGap) so this one may need more work. === Rendering hints (orientation, viewmodes, height, width...) === This continues to be a pain, particularly when apps share the screen as in Apache Rave, and you need to make them sit nicely with each other. The orientation property seem similar to how PhoneGap has used Widgets [1]. However in that case it is used to hint to the device which orientations should be enabled by the device, rather than set a launch orientation that may conflict with the orientation of the user's device. Likewise fullscreen is something else that has been used as an extension to Widgets by PhoneGap. However I'm not sure how either of these fits with ViewModes, so this needs thrashing out. === Security (installs_allowed_from...) === This is probably the most controversial area, and relates to a more general process of app store behaviour; this is also something we considered under the general area of embedding, and so there are other things that may fit such as download links for the packaged version of the webapp. It may have to end up in its own spec, or be pushed to the web-app-stores CG. [1] https://build.phonegap.com/docs/config-xml --tobie
Re: Push API draft uploaded
On 6/6/12 6:05 PM, SULLIVAN, BRYAN L bs3...@att.com wrote: Here is the thread for the set of use cases I submitted for this API during the rechartering: http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0008.html. Additional use cases are welcome, and we can capture them and derived requirements on the Webapps wiki. I created a page for this: http://www.w3.org/2008/webapps/wiki/Push_API Thanks for the links, Bryan. Will add use cases. --tobie
[Process] Publishing use cases and requirements as official docs
Hi, I recently stumbled upon a number of use case and requirements docs (such as MediaStream Capture Scenarios[1] or HTML Speech XG[2]) that were published as officially looking W3C documents (for whatever that means, at least, it's not a page on a Wiki). I think that's tremendously useful, especially for authors who can have a much better understanding of the purpose of a specification that way (and therefore use it the right way and for the right purpose). It's also a smart way to get authors involved without corrupting them into thinking like spec writers or implementors. What are the WebApps WG's plans with regards to that (if any)? Thanks, --tobie --- [1]: http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/scenarios.html [2]: http://www.w3.org/2005/Incubator/htmlspeech/live/draft-20110203-requirement s.html
Re: CfC: publish FPWD of Quota Management API; deadline June 13
On 6/6/12 2:01 PM, Arthur Barstow art.bars...@nokia.com wrote: Having seen no negative responses to the Is the Quota Management API spec ready for FPWD? thread [1], this is a Call for Consensus (CfC) to publish a First Public Working Draft (FPWD) of the Quota Management API using the following ED as the basis of the FPWD: https://dvcs.w3.org/hg/quota/raw-file/tip/Overview.html This CfC satisfies the group's requirement to record the group's decision to request advancement. By publishing this FPWD, the group sends a signal to the community to begin reviewing the document. The FPWD reflects where the group is on this specification at the time of publication; it does not necessarily mean there is consensus on the specification's contents. Please send all comments regarding this CfC to the public-webapps@w3.org mail list by June 13. Please note silence will be considered as agreement with the proposal. If you support this CfC, a positive response is preferred and encouraged. -Thanks, AB [1] http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0940.html We support this. --tobie
Re: [Process] Publishing use cases and requirements as official docs
On 6/6/12 1:55 PM, ext Tobie Langel wrote: Hi, I recently stumbled upon a number of use case and requirements docs (such as MediaStream Capture Scenarios[1] or HTML Speech XG[2]) that were published as officially looking W3C documents (for whatever that means, at least, it's not a page on a Wiki). I think that's tremendously useful, especially for authors who can have a much better understanding of the purpose of a specification that way (and therefore use it the right way and for the right purpose). It's also a smart way to get authors involved without corrupting them into thinking like spec writers or implementors. What are the WebApps WG's plans with regards to that (if any)? I think our [Charter] sets a clear expectation that our new specs will have some type of requirements and use cases and as a spec transitions to Last Call, the group should identify the requirements the spec addresses. There a number of ways to document the UCs and reqs. For example, Bryan is using a wiki for the Push API. Anne included requirements and use cases directly in the CORS spec (although I think they were moved out before CR). Marcos took the higher overhead route of publishing widget requirements as a TR. I don't think anyone has done so but a text file in Hg could also be sufficient as would be an email (thread). Which mechanism is used largely depends on how much time the protagonists are willing to spend. If anyone wants to go the TR route, we can certainly do that and we'd use the normal CfC process to gauge consensus. -Thanks, AB [Charter] http://www.w3.org/2012/webapps/charter/#others
Re: [Process] Publishing use cases and requirements as official docs
* Tobie Langel wrote: Hi, (Starting a new thread by replying to a mail and then changing the subject and quoted text is not a good idea; just start a new mail.) I recently stumbled upon a number of use case and requirements docs (such as MediaStream Capture Scenarios[1] or HTML Speech XG[2]) that were published as officially looking W3C documents (for whatever that means, at least, it's not a page on a Wiki). Only documents under http://www.w3.org/TR/ are official publications as far as Working Group's Technical Reports go. The documents above should follow policy http://www.w3.org/2005/03/28-editor-style.html for unpublished drafts, like not using Working Draft branding, but currently don't. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: [Process] Publishing use cases and requirements as official docs
On Jun 6, 2012, at 8:46 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote: (Starting a new thread by replying to a mail and then changing the subject and quoted text is not a good idea; just start a new mail.) Guilty as charged. Sorry, won't happen again. I recently stumbled upon a number of use case and requirements docs (such as MediaStream Capture Scenarios[1] or HTML Speech XG[2]) that were published as officially looking W3C documents (for whatever that means, at least, it's not a page on a Wiki). Only documents under http://www.w3.org/TR/ are official publications as far as Working Group's Technical Reports go. Can't WG release notes? --tobie
Re: [Process] Publishing use cases and requirements as official docs
* Tobie Langel wrote: On Jun 6, 2012, at 8:46 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote: Only documents under http://www.w3.org/TR/ are official publications as far as Working Group's Technical Reports go. Can't WG release notes? Working Groups can publish Working Group Notes as Technical Report, they would go under http://www.w3.org/TR/ aswell. And it can publish postings on a blog or publish some position statement on a mailing list and so on my point was mainly that if an address is not under http://www.w3.org/TR odds are you have stumbled on something that's long since been forgotten and links and dates and other things in and on them might be misleading. (The same is sometimes true for documents under http://www.w3.org/TR but there you should at least be able to follow the latest version links to discover the current status of the work, if that has been published re- cently.) -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: [Process] Publishing use cases and requirements as official docs
On Jun 6, 2012, at 10:04 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote: * Tobie Langel wrote: On Jun 6, 2012, at 8:46 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote: Only documents under http://www.w3.org/TR/ are official publications as far as Working Group's Technical Reports go. Can't WG release notes? Working Groups can publish Working Group Notes as Technical Report, they would go under http://www.w3.org/TR/ aswell. OK, but the process is lighter, no? --tobie
Re: [Process] Publishing use cases and requirements as official docs
On Wed, Jun 6, 2012 at 1:15 PM, Tobie Langel to...@fb.com wrote: OK, but the process is lighter, no? Yes, there is no process besides the WG agrees to publish it. ~TJ
Re: Implied Context Parsing (DocumentFragment.innerHTML, or similar) proposal details to be sorted out
On Wed, Jun 6, 2012 at 3:42 AM, Henri Sivonen hsivo...@iki.fi wrote: On Fri, Jun 1, 2012 at 10:25 AM, Jonas Sicking jo...@sicking.cc wrote: I think the SVG working group should learn to stand by its past mistakes. Not standing by them in the sense of thinking the past mistakes are great but in the sense of not causing further disturbances by flip-flopping. For what it's worth, I've not seen any flip-floppying on this. Over the years that I've asked the SVG WG the detailed question on if they prefer to have the parsing model for scripts in SVG-in-HTML I've consistently gotten the answer that they prefer this. At the time when SVG parsing was being added to text/html, vocal members of the SVG working group were adamant that parsing should work the same as for XML so that output from existing tools that had XML serializers could be copied and pasted into text/html in a text editor. Suggestions went as far as insisting a full XML parser be embedded inside the HTML parser. For [citation needed], see e.g. Requirement 1 in http://lists.w3.org/Archives/Public/public-html/2009Mar/0216.html (not the only place where the requirement was expressed but the first one I found when searching the archives) and requirements 1 and 2 as well as the first sentence under Summary in http://dev.w3.org/SVG/proposals/svg-html/svg-html-proposal.html . Indeed. But every time I asked specifically about the parsing of script issue, I got the answer that it was more important that script-markup could be moved between HTML and SVG-in-HTML. I'm also not sure how this is at all relevant here given that we should do what's best for authors, even when we learn over time what's best for authors. At this point, what's best for authors includes considerations of consistent behavior across already-deployed browsers (including IE9, soon IE10 and the Android stock browser) and future browsers. I think that's a matter of opinion. / Jonas
