Re: Fixing appcache: a proposal to get us started

[pira...@gmail.com]

Json manifest seems a nice solution to me :-)

Send from my Samsung Galaxy Note II
El 28/11/2013 07:21, "eli"  escribió:

> >> 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.
>>
> Could the problems of not being able to update one single file in the
> cache, and not sending WebM files to iOS devices, both be solved by adding
> additional file info to the cache manifest?
>
> For example, if the manifest were in JSON:
>
> {'CACHE': [
> {'file':'index.html','timestamp':'2013-11-27 00:00:00','expires':'2013-12-02
> 00:00:00','type':'text/html'},
> {'file':'video.webm','timestamp':'2013-11-27 00:00:00','expires':'2013-12-02
> 00:00:00','type':'video/webm'},
> {'file':'video.mp4','timestamp':'2013-11-27 00:00:00','expires':'2013-12-02
> 00:00:00','type':'video/mp4'}
> ],
> 'NETWORK':'*',
> 'FALLBACK':[['online.jpg','offline.jpg'],['online.htm','offline.htm']],
> 'SETTINGS':'prefer-online'}
>
> This way, a browser can compare a file's timestamp in the newly downloaded
> manifest to the one in its stored manifest to determine whether or not to
> download a new version. And an iOS device could ignore 'video/webm'
> file-types.
>
> -Eli
>
>
>> > --
>> > "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

[eli]

>> 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.
Could the problems of not being able to update one single file in the 
cache, and not sending WebM files to iOS devices, both be solved by 
adding additional file info to the cache manifest?


For example, if the manifest were in JSON:

{'CACHE': [
{'file':'index.html','timestamp':'2013-11-27 
00:00:00','expires':'2013-12-02 00:00:00','type':'text/html'},
{'file':'video.webm','timestamp':'2013-11-27 
00:00:00','expires':'2013-12-02 00:00:00','type':'video/webm'},
{'file':'video.mp4','timestamp':'2013-11-27 
00:00:00','expires':'2013-12-02 00:00:00','type':'video/mp4'}

],
'NETWORK':'*',
'FALLBACK':[['online.jpg','offline.jpg'],['online.htm','offline.htm']],
'SETTINGS':'prefer-online'}

This way, a browser can compare a file's timestamp in the newly 
downloaded manifest to the one in its stored manifest to determine 
whether or not to download a new version. And an iOS device could ignore 
'video/webm' file-types.


-Eli



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

Controling style of elements in Injection Points

[Enrique Moreno Tent]

Hello, I have been experimenting with Web Components and I have an issue,
which I think I have represented fairly clear here:

(Tested on Chrome)
http://codepen.io/dbugger/pen/Hyihd

If I understood correctly, one of the points of web components is to
control the presentation of our component. That is why we have the Shadow
Boundary. BUT what happens with the elements that are represented with
? They are not considered part of the shadow, therefore the styles
that the author decides to apply on them, will "invade" the Web Component.

Any thought on this?

-- 
Enrique Moreno Tent, Web developer
http://enriquemorenotent.com

Re: Allow javascript: URIs for registerProtocolHandler

[Ian Hickson]

On Wed, 18 Sep 2013, Anne van Kesteren wrote:
> On Tue, Sep 17, 2013 at 4:34 PM, pira...@gmail.com  wrote:
> > Really :-) I though the same, but since its a "GET equivalent 
> > operation" just like XHR and in fact Google Charts creates on-demand 
> > graphics based on the data on the URL query, so why not? So I created 
> > a custom fake protocol, set it inside the  tag and after 
> > registering and removing the fake protocol several times, I saw it 
> > only showed the image using the fake protocol when it was registered 
> > :-)
> 
> """ This section does not define how the pages registered by these 
> methods are used, beyond the requirements on how to process the url 
> value (see above). To some extent, the processing model for navigating 
> across documents defines some cases where these methods are relevant, 
> but in general UAs may use this information wherever they would 
> otherwise consider handing content to native plugins or helper 
> applications. """
> 
> Ian, was it ever the intent that these methods affect the way Fetch 
> works? Either way, this could use some tightening up as the current 
> language is quite vague. I think we should only let them affect the 
> navigate algorithm. Either way, we should clarify where the URL 
> translation happens as that will affect Service Workers (latest name of 
> Navigation Controller).

An interesting question.

http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2663

Safari doesn't support navigator.registerProtocolHandler().
I couldn't test IE but research suggests it doesn't support it.
Chrome supports it at the Fetch level, as a redirect.
Firefox supports it at the Navigation level, as a redirect.

Chrome's support is certainly attractive. The test above uses a custom 
protocol (web+twocats:) to register a URL that shows a picture, which can 
then be used in an . I tried using XMLHttpRequest, and it didn't 
work, but only because "Cross origin requests are only supported for 
HTTP", which seems like something we could extend, especially in the case 
of registered protocol handlers that "expand" to HTTP URLs.

There are certainly use cases for supporting these in  and XHR. For 
example, a TIFF -> PNG convertor could be registered for a content 
handler, in theory, enabling TIFF images to be used in . A site could 
allow itself to be themed by defining a "protocol" that was used to expose 
images and style sheets that it would then link to using this protocol. A 
site could expose itself as a cloud storage provider, and then files could 
be actually downloaded from that provider using XHR, without the client 
site knowing which provider was being used. There's plenty of interesting 
possibilities if you do this at the fetch level.

That's not to say that it'd be especially usable, as an API. If we really 
wanted to support these use cases, we might be better off doing it more 
explicitly, at the JavaScript level, providing ways for sites to spin up 
background cross-origin workers on demand, providing sites with a 
full-service API.

I don't really see any security issues with doing it at the fetch level; 
security issues would be the prime suspect for a rationale for doing 
things only for navigation. For example, we've limited javascript: now to 
only being done for navigation. (As a side note, javascript: is a 
non-starter for register*Handler(), because it would let script get run in 
the context of the source of the link. So the original topic of this 
thread is somewhat moot.)

Anyway. I think we should probably put this logic into Fetch, really.

As far as Service Workers go, I would hope the service worker for the 
domain of the source of the URL (as opposed to the domain of the 
registration) would never see the URL at all, since it'd be cross-origin.


On Wed, 18 Sep 2013, pira...@gmail.com wrote:
>
> I find the fact of being able to use custom protocols on  and 
> 

Re: [HTML Imports]: Sync, async, -ish?

[John J Barton]

What if:

...

...


...


  
...
was instead:


  
If I want to avoid FOUC, I precede this code with style that fill
app-loading or that display:none pi-app, then pi-app.html changes the
styles.
If I want to block script on pi-app I use load events.  If I want script to
block pi-app loading, I put that script before pi-app.

I'm just suggesting this, as a "dependency - driven" model where the
dependency is attached directly to the dependent rather than floating up in
. This is similar to JS modules where the importer says "import", not
.html saying .

(There are lots of HTML Import things that this may complicate, it's just a
suggestion of another point of view).



On Wed, Nov 27, 2013 at 12:32 PM, Daniel Buchner  wrote:

> JJB, this is precisely why the  concept seemed like a good idea to
> me:
>
>- Easy to use in just one or two places if needed, without a steep
>cliff
>   - The choice shouldn't be: either put up with the browser's default
>   render flow, or become a low-level, imperative, perf hacker
>   - Enables load/render/paint tuning of both graphical and
>non-visible, purely-functional elements
>- Flexible enough to allow for complex cases, while being (relatively)
>easy to grok for beginners
>- Doesn't require devs to juggle a mix of declarative, top-level
>settings, and imperative, per-element settings
>
> - Daniel
>
> On Wed, Nov 27, 2013 at 12:19 PM, John J Barton <
> johnjbar...@johnjbarton.com> wrote:
>
>> I just can't help thinking this is whole line of reasoning all too
>> complicated to achieve wide adoption and thus impact.
>>
>> The supposed power of declarative languages is ability to reason from top
>> to bottom. Creating all of these exceptions causes the very problems being
>> discussed: FOUC occurs because HTML Import runs async even though it looks
>> like is it sync.  Then we patch that up with eg "elements" and "paint".
>>
>> On the other hand, JS has allowed very sophisticated application loading
>> to be implemented. If the async HTML Import were done with JS and if we
>> added (if needed) rendering control support to JS, then we allow high
>> function sites complete control of the loading sequence.
>>
>> I think we should be asking: "what can we do to have the best chance that
>> most sites will show reasonable default content while loading on mobile
>> networks?" A complex solution with confusing order of operations is fine
>> for some sites, let them do it in JS. A declarative solution where default
>> content appears before high-function content seems more likely to succeed
>> for the rest. A complex declarative solution seems like the worst of both.
>> HTH,
>> jjb
>>
>>
>> On Wed, Nov 27, 2013 at 11:50 AM, Daniel Buchner wrote:
>>
>>> Right on Dimitri, I couldn't agree more. It seems like an involved (but
>>> highly beneficial) pursuit - but heck, maybe we'll find an answer quickly,
>>> let's give it a shot!
>>>
>>> Alex, I completely agree that declarative features should play a huge
>>> role in the solution, and I love the power/granularity you're alluding to
>>> in your proposal. WARNING: the following may be completely
>>> lol-batshit-crazy, so be nice! (remember, I'm not *really *a CS
>>> person...I occasionally play one on TV). What if we created something like
>>> this:
>>>
>>>  
>>>  *// "non-blocking" would be the
>>> default policy*
>>>  
>>>