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
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23787
Anne ann...@annevk.nl changed:
What|Removed |Added
Status|REOPENED|RESOLVED
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
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
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
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
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
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
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
https://www.w3.org/Bugs/Public/show_bug.cgi?id=13913
Ian 'Hixie' Hickson i...@hixie.ch changed:
What|Removed |Added
Status|RESOLVED|REOPENED
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
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
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
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
14 matches
Mail list logo
