Re: Fixing appcache: a proposal to get us started
The web is server + client sides. Trying to fix issues you have with client technologies only (appcache, JavaScript, ...) will always be a bad choice. I disagree, Javascript and web browsers are becoming powerful enough to delegate servers to their barebones, just offering storage or databases or specific web services, being able to delegate all the operatibility to the client-side code. In the new web, web servers are just plain ol' APIs. -- Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton de sitios diferentes, simplemente escribe un sistema operativo Unix. – Linus Tordvals, creador del sistema operativo Linux
[Bug 23787] Clarify that which HTTP entity body is referred in ProgressEvent spec
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23787 Anne ann...@annevk.nl changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Anne ann...@annevk.nl --- https://github.com/whatwg/xhr/commit/ab6ba77f2c559a5e23b0b28fa642d76e348e1330 -- You are receiving this mail because: You are on the CC list for the bug.
Re: Fixing appcache: a proposal to get us started
The web is server + client sides. Trying to fix issues you have with client technologies only (appcache, JavaScript, ...) will always be a bad choice. I disagree, Javascript and web browsers are becoming powerful enough to delegate servers to their barebones, just offering storage or databases or specific web services, being able to delegate all the operatibility to the client-side code. In the new web, web servers are just plain ol' API It's not that much a question of available power, it's just operations that needs to be done before any file hit the device. To be available offline, the device has to hit a server first, then the appcache magic happens. No reason the server couldn't prepare / select what to send to the device: iOS won't support WebM anytime soon, there is no reason to constantly ask iOS device the same info again again. That just makes no sense, and force devs to produce device/os specific files (manifest) anyway. And it's not AppCache job to do so. Its job is just make a web document available offline + make updates simple easy. Example : Not being able to update one single file keeping the others cached is a structural mistake. Sub-manifests sounds like an over-engineered fix to me, just making things more complicated for developers, browser vendors for future evolution of this specification. -- Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton de sitios diferentes, simplemente escribe un sistema operativo Unix. – Linus Tordvals, creador del sistema operativo Linux
Re: Fixing appcache: a proposal to get us started
To be available offline, the device has to hit a server first, then the appcache magic happens. Obviously. No reason the server couldn't prepare / select what to send to the device: iOS won't support WebM anytime soon, there is no reason to constantly ask iOS device the same info again again. That just makes no sense, and force devs to produce device/os specific files (manifest) anyway. And it's not AppCache job to do so. Its job is just make a web document available offline + make updates simple easy. I'm not talking about remove the servers functionality, I only disagree with your statement about using only client-side technologies is bad, giving the impression that servers are necesary. Not today, they are necesary for bootstraping and access content on a reference place, but we should remove the idea of a centralized web as far as possible. AppCache here is a good tool for this, but here the server is only neccesary to generate the custom manifest file, no more, and also probably this manifest could be generated directly on client-side (don't know if it could be done with today technologies, but at least with ServiceWorkers it will be possible, and using them probably the AppCache manifest becames useless in this case of use). -- Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton de sitios diferentes, simplemente escribe un sistema operativo Unix. – Linus Tordvals, creador del sistema operativo Linux
Re: Fixing appcache: a proposal to get us started
Your manifest file should be dynamically generated by your server, based on what you know about the user's browser. Now you have one single manifest file which is easier for updates, + server-side language comments so documentation is easy. The web is server + client sides. Trying to fix issues you have with client technologies only (appcache, JavaScript, ...) will always be a bad choice. I would contest this point as now you're suggesting that the right thing to do is to force everyone to maintain custom browser detection libraries on their servers again in order to guess what the browser's capabilities are. As we know from much experience with this technique already, it is brittle and must be constantly monitored and updated as new browser versions are released. Why not attempt to give the browser-side manifest functionality the ability to feature test for file support instead? Then the browsers can be the trusted source instead of everyone having to create new divergent browser file support inference hacks. Sincerely, James Greene On Mon, Nov 25, 2013 at 9:30 AM, pira...@gmail.com pira...@gmail.comwrote: To be available offline, the device has to hit a server first, then the appcache magic happens. Obviously. No reason the server couldn't prepare / select what to send to the device: iOS won't support WebM anytime soon, there is no reason to constantly ask iOS device the same info again again. That just makes no sense, and force devs to produce device/os specific files (manifest) anyway. And it's not AppCache job to do so. Its job is just make a web document available offline + make updates simple easy. I'm not talking about remove the servers functionality, I only disagree with your statement about using only client-side technologies is bad, giving the impression that servers are necesary. Not today, they are necesary for bootstraping and access content on a reference place, but we should remove the idea of a centralized web as far as possible. AppCache here is a good tool for this, but here the server is only neccesary to generate the custom manifest file, no more, and also probably this manifest could be generated directly on client-side (don't know if it could be done with today technologies, but at least with ServiceWorkers it will be possible, and using them probably the AppCache manifest becames useless in this case of use). -- Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton de sitios diferentes, simplemente escribe un sistema operativo Unix. – Linus Tordvals, creador del sistema operativo Linux
Re: Fixing appcache: a proposal to get us started
Why not attempt to give the browser-side manifest functionality the ability to feature test for file support instead? Then the browsers can be the trusted source instead of everyone having to create new divergent browser file support inference hacks. This seems to me that this is some kind of add scripting habilities to the AppCache manifest, while we already have Javascript, and allowing it to do that will lead us to something fairly similar (in fact, a sub-set) of what ServiceWorkers can do. Why duplicate efforts then? Manifest files are good for static content, but for other cases there are better tools. -- Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton de sitios diferentes, simplemente escribe un sistema operativo Unix. – Linus Tordvals, creador del sistema operativo Linux
Re: Fixing appcache: a proposal to get us started
Le 25 nov. 2013 à 17:27, James Greene james.m.gre...@gmail.com a écrit : Your manifest file should be dynamically generated by your server, based on what you know about the user's browser. Now you have one single manifest file which is easier for updates, + server-side language comments so documentation is easy. The web is server + client sides. Trying to fix issues you have with client technologies only (appcache, JavaScript, ...) will always be a bad choice. I would contest this point as now you're suggesting that the right thing to do is to force everyone to maintain custom browser detection libraries on their servers again in order to guess what the browser's capabilities are. As we know from much experience with this technique already, it is brittle and must be constantly monitored and updated as new browser versions are released. Why not attempt to give the browser-side manifest functionality the ability to feature test for file support instead? Then the browsers can be the trusted source instead of everyone having to create new divergent browser file support inference hacks. Sincerely, James Greene I'm not rejecting anything or trying to state something is good or bad. Just like i'm not rejecting the server side as a devil to kill. Current AppCache state is not THAT bad for static document cache. It's pretty much 100% client-side, and with a little bit of extra work to fix how it handles files updates, it might be ok, still easy to deal with. (file by file update without complete manifest swip, grouped files versionning, end of validity datetime, …) Then for further / more complicate / specific use cases, some server-side scripts might be needed. And trying to do everything only from the client-side is a bad choice, just like previous things we did thinking server-side only was a bad choice too. Remi
Re: Fixing appcache: a proposal to get us started
This seems to me that this is some kind of add scripting habilities to the AppCache manifest, while we already have Javascript, and allowing it to do that will lead us to something fairly similar (in fact, a sub-set) of what ServiceWorkers can do. Why duplicate efforts then? Manifest files are good for static content, but for other cases there are better tools. Yes and no. Primary differences: 1. I'm not advocating for full scriptability, just basic support detection, e.g.: `if accepts(audio/ogg) ...` The main problem I'd see there is if the browser also needs to know what plugins (or even JS libs, I suppose) are capable of consuming. 2. AFAIK, using ServiceWorkers requires that the resources are programmatically fetched *by* the ServiceWorker. This is different than a manifest which is capable of figuring the cache out on the fly as resources are loaded. I'm not opposed to just punted and saying that ServiceWorker is the way to deal with this, though. I have no personal use cases at the moment for this functionality... just playing devil's advocate for the OP. :) Sincerely, James Greene On Mon, Nov 25, 2013 at 11:05 AM, pira...@gmail.com pira...@gmail.comwrote: Why not attempt to give the browser-side manifest functionality the ability to feature test for file support instead? Then the browsers can be the trusted source instead of everyone having to create new divergent browser file support inference hacks. This seems to me that this is some kind of add scripting habilities to the AppCache manifest, while we already have Javascript, and allowing it to do that will lead us to something fairly similar (in fact, a sub-set) of what ServiceWorkers can do. Why duplicate efforts then? Manifest files are good for static content, but for other cases there are better tools. -- Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton de sitios diferentes, simplemente escribe un sistema operativo Unix. – Linus Tordvals, creador del sistema operativo Linux
[Bug 13913] Attributes don't have an order
https://www.w3.org/Bugs/Public/show_bug.cgi?id=13913 Bug 13913 depends on bug 13912, which changed state. Bug 13912 Summary: What order are attributes in? https://www.w3.org/Bugs/Public/show_bug.cgi?id=13912 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 13913] Attributes don't have an order
https://www.w3.org/Bugs/Public/show_bug.cgi?id=13913 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME |--- -- You are receiving this mail because: You are on the CC list for the bug.
Re: Fixing appcache: a proposal to get us started
1. I'm not advocating for full scriptability, just basic support detection, e.g.: `if accepts(audio/ogg) ...` Some kind of basic scriptability like the one on CSS, isn't it? Ok, it's good. The main problem I'd see there is if the browser also needs to know what plugins (or even JS libs, I suppose) are capable of consuming. More or less why I was going down the full Javascript path :-) 2. AFAIK, using ServiceWorkers requires that the resources are programmatically fetched by the ServiceWorker. This is different than a manifest which is capable of figuring the cache out on the fly as resources are loaded. Not really, ServiceWorker doesn't mandate that all resources go though it, but it's being showed as the main use case (not mine, I want to combine it with ProtocolHandler to create my own protocols and manage them on client-side...). I'm not opposed to just punted and saying that ServiceWorker is the way to deal with this, though. I have no personal use cases at the moment for this functionality... just playing devil's advocate for the OP. :) Lol! Ok :-) -- Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton de sitios diferentes, simplemente escribe un sistema operativo Unix. – Linus Tordvals, creador del sistema operativo Linux
RE: publish LCWD of DOM Parsing and Serialization; deadline November 25
I've finished the major updates. Today's ED draft at: https://dvcs.w3.org/hg/innerhtml/raw-file/tip/index.html should be ready to use as the baseline for the Last Call CfC. Thanks, Travis -Original Message- From: Travis Leithead Sent: Monday, November 18, 2013 11:26 AM To: Webapps WG Subject: RE: publish LCWD of DOM Parsing and Serialization; deadline November 25 If possible, I'd like to delay this CfC, for a week--I have some major updates to the ED in-flight, and I want to make sure we base the CfC on the right ED content :-) Hopefully this is workable to the group. Thanks! - From: Arthur Barstow [mailto:art.bars...@nokia.com] Sent: Monday, November 18, 2013 4:00 AM This is a Call for Consensus (CfC) to publish a LCWD of DOM Parsing and Serialization, using the following ED as the basis: https://dvcs.w3.org/hg/innerhtml/raw-file/tip/index.html This CfC satisfies the group's requirement to record the group's decision to request advancement for this LCWD. Note the Process Document states the following regarding the significance/meaning of a LCWD: [[ http://www.w3.org/2005/10/Process-20051014/tr.html#last-call Purpose: A Working Group's Last Call announcement is a signal that: * the Working Group believes that it has satisfied its relevant technical requirements (e.g., of the charter or requirements document) in the Working Draft; * the Working Group believes that it has satisfied significant dependencies with other groups; * other groups SHOULD review the document to confirm that these dependencies have been satisfied. In general, a Last Call announcement is also a signal that the Working Group is planning to advance the technical report to later maturity levels. ]] Currently, this spec has one Editorial bug [18939] that is open and Travis will fix this before the LCWD is published. If you have any comments or concerns about this CfC, please send them to public-webapps@w3.org by November 25 at the latest. Positive response is preferred and encouraged and silence will be considered as agreement with the proposal. The proposed review period for this LC is 4 weeks. Assuming this CfC passes, if there are any specific groups (e.g. HTMLWG, TAG, I18N, WAI, Privacy IG, Security IG, etc.) we should ask to review the LCWD, please let me know. -Thanks, AB [18939] https://www.w3.org/Bugs/Public/show_bug.cgi?id=18938 Original Message Subject:ACTION-701: Start a cfc to publish lcwd of dom parsing and serialization (Web Applications Working Group) Date: Mon, 11 Nov 2013 01:59:39 + From: ext Web Applications Working Group Issue Tracker sysbot+trac...@w3.org Reply-To: Web Applications Working Group public-webapps@w3.org To: art.bars...@nokia.com ACTION-701: Start a cfc to publish lcwd of dom parsing and serialization (Web Applications Working Group) http://www.w3.org/2008/webapps/track/actions/701 On: Arthur Barstow Due: 2013-11-18 If you do not want to be notified on new action items for this group, please update your settings at: http://www.w3.org/2008/webapps/track/users/7672#settings
Cross Origin Web Components: Fixing iframes
Hi, I have been having informal discussions of our earlier proposal for cross-orign use cases and declarative syntax for web components, and I realized there was a lot of confusion about our motivations and decision decisions. So I wanted to explain why/how we came up that proposal in this email. Problem: A lot of websites embed SNS widgets, increasing the security surface of embedders. The old version of techcrunch.com, for example, had 5+ social share buttons on each article. If any one of those SNS websites got compromised, then the embedder will also get compromised. What if we used iframe? What if we replaced each such instance with an iframe? That would give us a security boundary. On the other hand, using an iframe for each social button is very expensive because each iframe loads a document, creates its own security origin, JS global object, and so forth. Initializing new script context (a.k.a. VM, world, isolate, etc…) for every single SNS widget on a page is quite expensive. If we had 10 articles, and each article had 5 social buttons, we'll have 50 iframes, each of which needs to load megabytes of JavaScript. iframe is also heavily restricted in terms of its ability to layout itself. Comment widgets (e.g. DISQUS) for example need to stretch themselves to the height of its content. We also need a better mechanism to pass arguments and communicate with cross-origin frames than postMessage. What if we made iframe lighter used seamless iframe? The cost of iframe could be reduced substantially if we cached and internally shared each page's JavaScript. However, we still have to instantiate its own script context, document, and window objects. We can also use seamless iframe to address the comment widget use case. What if we let each iframe create multiple views? The problem with using an iframe for a cross-origin widget is that each iframe creates its own document, window, etc… even if there are multiple widgets from the same origin. e.g. if we had a tweet button on 10 different articles, we have to create its own document ,window, etc… for each tweet button. We can reduce this cost if we could share the single frame, and have it render multiple views. Naturally, each such view will be represented as a separate DOM tree. In this model, a single iframe owns multiple DOM trees, each of which will be displayed at different locations in the host document. Each such a DOM tree is inaccessible from the host document, and the host document is inaccessible from the iframe. This model dramatically reduces the cost of having multiple widgets from the same origin. e.g. if we have 10 instances of widgets from 5 different social networks, then we'll have only 5 iframes (each of which will have 10 views) as opposed to 50 of them. What if we provided a declarative syntax to create such a view? Providing a better API proved to be challenging. We could have let page authors register a custom element for each cross-origin widget but that would mean that page authors have to write a lot of script just to embed some third-party widgets. We need some declarative syntax to let authors wrap an iframe. Furthermore, if we wanted to use the multiple-views-per-iframe, then we'll need a mechanism to declare where each instance of such a view is placed in the host document with arguments/configuration options for each view. A custom element seemed like a natural fit for this task but the prototype/element object cannot be instantiated in the host document since the cross-origin widgets' script can't run in the host document and prototype objects, etc… cannot be shared between the host document and the shared iframes. So we'll need some mechanism for the shared iframe to define custom element names, and have the host document explicitly import them as needed. At this point, the set of features we needed looked very similar to the existing custom element and shadow DOM. Each view of the shared iframe was basically a shadow DOM with a security boundary sitting between the host element and the shadow root. The declarative syntax for the view was basically a declarative syntax of a custom element that happens to instantiate a shadow DOM with a caveat that the shadow host is inaccessible form the component, and the shadow DOM is inaccessible from the host document. It also seemed natural for such an shared iframe to be loaded using HTML imports. You can think of our proposal as breaking iframe down into two pieces: Creating a new document/window Creating a new view and providing a mechanism to do 2 without doing 1 (or that doing 2 multiple times after doing 1 once), and making it usable with a declarative syntax. - R. Niwa
RE: [testing] Seeking Test Facilitator(s) for Indexed Database API
From: Arthur Barstow [mailto:art.bars...@nokia.com] Sent: Saturday, November 23, 2013 2:58 AM Please contact me if you can commit to helping with this effort and you have `relevant` experience. After reconsidering your invitation at TPAC about this, I would like to take this role and to review the submissions from next week. BTW, I will backup Tina Zhao, the Test Facilitator for Server Sent Events, for about half a year during her maternity leave. Please contact me if you have any matters related to SSE. Thanks, Zhiqiang
