*"I am going to offer a cop-out option: maybe we simply don't offer
imperative syntax as part of the spec?"
*
Why would we do this if the imperative syntax is "solid", "nicely
compatible", and relatively uncontentious? Did you mean to say declarative?
Daniel J. Buchner
Product Manager, Developer Ecosystem
Mozilla Corporation
On Tue, Apr 16, 2013 at 2:56 PM, Dimitri Glazkov <dglazkov@google.com>wrote:
> Wow. What a thread. I look away for a day, and this magic beanstalk is all
> the way to the clouds.
>
> I am happy to see that all newcomers are now up to speed. I am heartened
> to recognize the same WTFs and grumbling that we went through along the
> path. I feel your pain -- I've been there myself. As Hixie once told me
> (paraphrasing, can't remember exact words), "All the good choices have been
> made. We're only left with terrible ones".
>
> I could be wrong (please correct me), but we didn't birth any new ideas so
> far, now that everyone has caught up with the constraints.
>
> The good news is that the imperative syntax is solid. It's nicely
> compatible with ES6, ES3/5, and can be even used to make built-in HTML
> elements (modulo security/isolation problem, which we shouldn't tackle
> here).
>
> I am going to offer a cop-out option: maybe we simply don't offer
> imperative syntax as part of the spec? Should we let libraries/frameworks
> build their own custom elements (with opinion and flair) to implement
> declarative syntax systems?
>
> :DG<
>