Re: Implied Context Parsing (DocumentFragment.innerHTML, or similar) proposal details to be sorted out

[Jonas Sicking]

On Wed, Jun 6, 2012 at 3:42 AM, Henri Sivonen  wrote:
> On Fri, Jun 1, 2012 at 10:25 AM, Jonas Sicking  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  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

Re: [Process] Publishing use cases and requirements as official docs

[Tab Atkins Jr.]

On Wed, Jun 6, 2012 at 1:15 PM, Tobie Langel  wrote:
> OK, but the process is lighter, no?

Yes, there is no process besides "the WG agrees to publish it".

~TJ

Re: [Process] Publishing use cases and requirements as official docs

[Tobie Langel]

On Jun 6, 2012, at 10:04 PM, "Bjoern Hoehrmann"  wrote:

> * Tobie Langel wrote:
>> On Jun 6, 2012, at 8:46 PM, "Bjoern Hoehrmann"  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

[Bjoern Hoehrmann]

* Tobie Langel wrote:
>On Jun 6, 2012, at 8:46 PM, "Bjoern Hoehrmann"  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

[Tobie Langel]

On Jun 6, 2012, at 8:46 PM, "Bjoern Hoehrmann"  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

[Bjoern Hoehrmann]

* 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

[Arthur Barstow]

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: CfC: publish FPWD of Quota Management API; deadline June 13

[Tobie Langel]

On 6/6/12 2:01 PM, "Arthur Barstow"  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:
>
>
>
>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

[Process] Publishing use cases and requirements as official docs

[Tobie Langel]

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: Push API draft uploaded

[Tobie Langel]

On 6/6/12 6:05 PM, "SULLIVAN, BRYAN L"  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

Re: [manifest] Is the Webapp Manifest spec ready for FPWD?

[Scott Wilson]

On 6 Jun 2012, at 16:10, Tobie Langel wrote:

> On 6/6/12 5:02 PM, "Marcos Caceres"  wrote:
> 
>> On Wednesday, June 6, 2012 at 2:58 PM, Tobie Langel wrote:
>> 
>>> Absolutely, or:
>>> 
>>> 
>>> 
>>> 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: Publish FPWD of Web Intents spec; deadline June 12

[Greg Billock]

Done. Thanks for the reality check. :-)


On Wed, Jun 6, 2012 at 1:35 AM, Ms2ger  wrote:
> On 06/06/2012 02:26 AM, Greg Billock wrote:
>>
>> On Tue, May 29, 2012 at 10:48 PM, Deepanshu Gautam
>>   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: [webcomponents] HTML Parsing and the element

[Tab Atkins Jr.]

On Wed, Jun 6, 2012 at 3:50 AM, Henri Sivonen  wrote:
> On Tue, Jun 5, 2012 at 12:42 AM, Ian Hickson  wrote:
>> On Wed, 4 Apr 2012, Rafael Weinstein wrote:
>>> On Mon, Apr 2, 2012 at 3:21 PM, Dimitri Glazkov  
>>> 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 .
>
> 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:


  Stamp out copies of me!


...is morally equivalent to this:


  
Stamp out copies of me!


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
 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  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 .

~TJ

RE: Push API draft uploaded

[SULLIVAN, BRYAN L]

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"  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?

 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: Implied Context Parsing (DocumentFragment.innerHTML, or similar) proposal details to be sorted out

[Tab Atkins Jr.]

On Wed, Jun 6, 2012 at 3:42 AM, Henri Sivonen  wrote:
> On Fri, Jun 1, 2012 at 10:25 AM, Jonas Sicking  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  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: [manifest] Is the Webapp Manifest spec ready for FPWD?

[Tobie Langel]

On 6/6/12 5:02 PM, "Marcos Caceres"  wrote:

>On Wednesday, June 6, 2012 at 2:58 PM, Tobie Langel wrote:
>
>> Absolutely, or:
>>  
>> 
>>  
>> 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: [manifest] Is the Webapp Manifest spec ready for FPWD?

[Marcos Caceres]

On Wednesday, June 6, 2012 at 2:58 PM, Tobie Langel wrote:

> On 6/6/12 3:35 PM, "Marcos Caceres"  (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:
> >  
> > 
> > 
> >  
> > That way, there is no need to repeat meta tags in every page... just
> > repeat it onceŠ
>  
>  
> Absolutely, or:
>  
> 
>  
> 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?

[Tobie Langel]

On 6/6/12 3:35 PM, "Marcos Caceres"  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:
>
>
>
>
>That way, there is no need to repeat meta tags in every page... just
>repeat it onceŠ

Absolutely, or:



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?

[Marcos Caceres]

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:  

  


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] screen sizes, Re: Review of Web Application Manifest Format and Management APIs

[Henri Sivonen]

On Sun, May 27, 2012 at 7:45 PM, Anant Narayanan  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/

CfC: publish FPWD of Quota Management API; deadline June 13

[Arthur Barstow]

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:




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: [webcomponents] HTML Parsing and the element

[Henri Sivonen]

On Tue, Jun 5, 2012 at 12:42 AM, Ian Hickson  wrote:
> On Wed, 4 Apr 2012, Rafael Weinstein wrote:
>> On Mon, Apr 2, 2012 at 3:21 PM, Dimitri Glazkov  
>> 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 .

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/

Re: Implied Context Parsing (DocumentFragment.innerHTML, or similar) proposal details to be sorted out

[Henri Sivonen]

On Fri, Jun 1, 2012 at 10:25 AM, Jonas Sicking  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  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: Implied Context Parsing (DocumentFragment.innerHTML, or similar) proposal details to be sorted out

[Henri Sivonen]

On Thu, May 31, 2012 at 7:00 PM, Rafael Weinstein  wrote:
> Do you have a particular concern about making scripts executable?

When a document fragment is inserted into a document and the document
fragment includes multiple external scripts or both in-line and
external scripts, the order in which the scripts execute is not
guaranteed to be the same as when identical markup came from the
network or document.write. I worry that this is a foot gun: the author
is working with markup but the behavior matches the behavior of
working with createElement and appendChild.

I am not suggesting that we should try to change the order in which
the scripts run. I definitely don't want that to be changed. I'm
suggesting that working with markup literals shouldn't be advertised
as a good way to insert scripts into a document.

I see the value of being consistent with jQuery, though. :-(

-- 
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

Re: [manifest] Is the Webapp Manifest spec ready for FPWD?

[Tobie Langel]

On 6/6/12 10:27 AM, "Scott Wilson"  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: Publish FPWD of Web Intents spec; deadline June 12

[Ms2ger]

On 06/06/2012 02:26 AM, Greg Billock wrote:

On Tue, May 29, 2012 at 10:48 PM, Deepanshu Gautam
  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?

[Scott Wilson]

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, c&p 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: [manifest] Is the Webapp Manifest spec ready for FPWD?

[Tobie Langel]

On 6/6/12 2:10 AM, "Arthur Barstow"  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: Feedback on Quota Management API

[Tobie Langel]

On 6/6/12 8:33 AM, "Kinuko Yasuda"  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: Feedback on Quota Management API

[Kinuko Yasuda]

On Wed, Jun 6, 2012 at 4:27 PM, Anne van Kesteren  wrote:

> On Wed, Jun 6, 2012 at 8:33 AM, Kinuko Yasuda  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

[Anne van Kesteren]

On Wed, Jun 6, 2012 at 8:33 AM, Kinuko Yasuda  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/