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 <dan...@mozilla.com> wrote:
> JJB, this is precisely why the <paint> 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 <dan...@mozilla.com>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:
>>>
>>> <head>
>>><paint policy="blocking"> *// "non-blocking" would be the
>>> default policy*
>>> <link rel="import" href="first-load-components.html" />
>>> <script>
>>>
>>> *// Some script here** that is required for initial setup of or
>>> interaction*
>>> * // ** with the custom elements imported from
>>> first-load-components.html*
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *// content here is subject to default browser paint flow*
>>>
>>>
>>>
>>>
>>>
>>> *// this content is essentially designated as low-priority, // but
>>> framerate="5" could also be treated as a lower-bound target.*
>>>
>>>
>>>
>>>
>>>
>>>
>>> Here's what I intended in the example above:
>>>
>>>- A element would allow devs t