RE: Lions and tigers and bears, oh my...

On Sep 14, 2013 1:47 PM, "François REMY" <francois.remy.dev@outlook.com>
wrote:
>
> Ok, finally found some time to share my thoughts here :
>
>
>
> (1)    I believe the BufferedParser thing should be replaced by a CSS
Selector Observer, that gives us more freedom and I stay confident we will
have one very soon. The CSS Selector Observer would resolve asynchronously,
and feature both “startMatching” and “stopMatching” events.

So, i suppose maybe I didn't make things clear enough. Obviously i am pro
some kinda ways for css to become extensible.  Filters are a natural
extension point - let css do the heavy lifting and then merely filter a
subset.  i worked thorough a lot of stuff on how with tab and borris z a
long time back - suppose we should write it up and some point but there are
numerous ideas around that and i want to collect them before i spend
copious amounts of time there.  The imperative API might have something
like you are saying but it would definitely have to be an observer rather
than a listener and it would likely have to neuter some of your dom powers
lest it be impossibly easy to hose.

That all said, the next obvious question to me is how would that play in
this use case.  It's a difficult question and i don't know the answer.
This is actually why i named something new, it can help flesh out use cases
by giving us something to play with and lead to detailed talks on where it
goes and how it works.  For example: no mechanism i can find happens prior
to DOMContentLoaded - i explain why that is a problem in the readme... So,
it would work fine as part of mutation observers if we could figure that
out, it could use something like a css observer, etc... But what we would
really need for now is something that works and gives us ways to develop
use cases/patterns to propose... Maybe this is too granular, maybe not
enough...maybe it deserves its own abstractions, maybe it fits somewhere
else.  In extensible web fashion, i am merely trying to throw a useful
starting point out there.

>
> (2)    I’m not against the LINK stuff but I believe a declarative API is
not needed in this case. We could as easily spec a function
XMLHttpRequeset.download(url, options) that would return a promise and use
Promise.all(…….) to await multiple downloads to finish.
>
> What do you think?
>
That is under this as well via rsvp - we could spec it
eventually...surprised if it isn't started already.  I see a number of use
cases for link - very notably htmlimports is one - most of the examples
illustrated are based off stuff on whatwg and twitter as recently as a few
weeks ago.  Declarative is an end-game for a lot of things - and thinking
about it helps flesh out what needs to go beneath.

>
>
>
>
>
>
>
>
>
> https://github.com/bkardell/BufferedParseObserver/blob/master/README.me