h 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, pe
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 becau
On Sat, Nov 23, 2013 at 1:51 AM, Jonas Sicking wrote:
>
>
> It would technically be possible to define that
On Fri, Nov 22, 2013 at 8:22 AM, Daniel Buchner wrote:
> Personally I don't have any issues with this solution, it provides for the
> use-cases we face. Also, it isn't without precedent - you can opt for a
> sync XMLHttpRequest (not much different).
>
> The best part of an explicit 'sync' attribu
o giving developers
> the ability to choose what's best for them. Right now I don't see a way for
> a developer to choose to have a custom element block rendering, as opposed
> to be backfilled later. Do we think this is important? (I think so.) If so,
> what's a go
Ok, so my 2 cents: it's ok but it gives a very Web 1.0 solution. We had to
invent AJAX so developers could control the user experience in the face of
significant network delay. As I said earlier, most apps will turn this
problem over to the design team rather than cause users to leave while the
bro
> names, it would block rendering until the associated link import has
> finished loading and registering the containing custom elements.
>
> Thoughts?
>
> - Daniel
>
>
> On Wed, Nov 20, 2013 at 11:19 AM, Daniel Buchner wrote:
>
>>
>> On Nov 20, 2013 11:07
On Wed, Nov 20, 2013 at 7:34 PM, Ryosuke Niwa wrote:
> On Nov 21, 2013, at 10:41 AM, Hajime Morrita wrote:
> > Seems like almost everyone agrees that we need better way to
> > modularize JavaScript, and ES6 modules are one of the most promising
> > way to go. And we also agree (I think) that we
On Wed, Nov 20, 2013 at 10:41 AM, Daniel Buchner wrote:
> Dimitri: right on.
>
> The use of script-after-import is the forcing function in the blocking
> scenario, not imports.
>
Yes.
> Let's not complicate the new APIs and burden the overwhelming use-case to
> service folks who intend to use th
Another alternative:
First let's agree that Souder's example must block:
...
var link = document.querySelector('link[rel=import]');
var content = link.import.querySelector('#imported-content');
document.getElementById('import-container').appendChild(content.cloneNode(true));
If we don't bl
Now a correction:
On Tue, Nov 19, 2013 at 4:25 PM, John J Barton
wrote:
> Last is an asynchronous "declarative" model (quote because such solutions
> are not declarative).
>
Broadly I am advocating using ES6 modules with HTML imports. The
particular example I made up ea
nfusion
by simulating imperative actions with declarative syntax.
FOUC is a sign of the failing of this kind of solution: the unstyled
content hits the rendering engine in the wrong order, before the JS that it
depends upon. If our dependency design is correct, we only deliver useful
content to the
On Tue, Nov 19, 2013 at 2:07 PM, Rick Waldron wrote:
>
>
>
> On Mon, Nov 18, 2013 at 7:14 PM, Jonas Sicking wrote:
>
>> Hi All,
>>
>> Largely independently from the thread that Dimitri just started on the
>> sync/async/-ish nature of HTML imports I have a problem with how
>> script execution in t
On Mon, Nov 18, 2013 at 3:06 PM, Scott Miles wrote:
> >> I'll assert that the primary use case for JS interacting with HTML
> components ought to be 'works well with JS modules'.
>
> You can happily define modules in your imports, those two systems are
> friends as far as I can tell. I've said th
On Mon, Nov 18, 2013 at 2:33 PM, Scott Miles wrote:
> >> I love the idea of making HTML imports *not* block rendering as the
> default behavior
>
> So, for what it's worth, the Polymer team has the exact opposite desire. I
> of course acknowledge use cases where imports are being used to enhance
Maybe Steve's example[1] could be on JS rather than on components:
System.component("import.php", function(component) {
var content = component.content
document.getElementById('import-container').appendChild(content.cloneNode(true));
});
Here we mimic System.load(jsId, success, error). Then m
Aren't ES6 modules is a good-enough solution for this issue? They make
global collision rare and likely to be what the author really needed.
jjb
On Mon, May 20, 2013 at 1:00 PM, Aaron Boodman wrote:
> Hello public-webapps,
>
> I have been following along with web components, and am really exci
On Wed, May 15, 2013 at 11:03 AM, Dimitri Glazkov wrote:
> On Wed, May 15, 2013 at 10:59 AM, Jonas Sicking wrote:
> > On Wed, May 15, 2013 at 10:21 AM, John J Barton
> > wrote:
> >>
> >>
> >>
> >> On Tue, May 14, 2013 at 8:04 PM, Jonas Sick
On Thu, Apr 18, 2013 at 11:11 PM, Dominic Cooney wrote:
> On Wed, Apr 17, 2013 at 12:01 AM, John J Barton <
> johnjbar...@johnjbarton.com> wrote:
>
>> I wonder if there may be a "cultural" difference involved in our
>> different points of view. As a C++
rote:
> On Sat, Apr 13, 2013 at 12:03 PM, John J Barton <
> johnjbar...@johnjbarton.com> wrote:
>
>> While I completely understand the beauty of having any JS object bound to
>> an inherit functions that make that object 'be an element', I'm
>> unsur
include a jQuery plugin
> script at the bottom of the body that 'upgrades' various elements on the
> page after render - basically, it's an unfortunate case of That's Just Life™
>
>
> Daniel J. Buchner
> Product Manager, Developer Ecosystem
> Mozilla Cor
this appropriately for our application.
>
Gee, that's not very encouraging: this is the most important kind of issue
for a developer, more so than whether the API is inheritance-like or not.
>
>
> On Mon, Apr 15, 2013 at 1:46 PM, John J Barton <
> johnjbar..
On Mon, Apr 15, 2013 at 11:29 AM, Scott Miles wrote:
> Thank you for your patience. :)
>
ditto.
>
>
> > ? user's instance code? Do you mean: Running component instance
> initialization during document construction is Bad?
>
> My 'x-foo' has an 'init' method that I wrote that has to execute bef
On Mon, Apr 15, 2013 at 10:38 AM, Scott Miles wrote:
> Dimitri is trying to avoid 'block[ing] instance construction' because
> instances can be in the main document markup.
>
Yes we sure hope so!
>
> The main document can have a bunch of markup for custom elements. If the
> user has made eleme
On Mon, Apr 15, 2013 at 9:44 AM, Scott Miles wrote:
> >> Why do the constructors of component instances run during component
> loading?
>
> I'm not sure what you are referring to. What does 'component loading' mean?
>
> >> Why not use standard events rather than callbacks?
>
>
> I'll some of the
Why do the constructors of component instances run during component loading?
Why not use standard events rather than callbacks?
Thanks,
jjb
On Apr 15, 2013 9:04 AM, "Scott Miles" wrote:
> Again, 'readyCallback' exists because it's a Bad Idea to run user code
> during parsing (tree construction)
While I completely understand the beauty of having any JS object bound to
an inherit functions that make that object 'be an element', I'm
unsure of the practical value.
To me the critical relationship between the JS and the element is JS object
access to its corresponding element instance without
On Thu, Apr 11, 2013 at 7:57 AM, Erik Arvidsson wrote:
> The problem here is how do you register `My_yay` as the class that goes
> with the tag name `my_yay`. One option could be to use the completion
> value but it seems too magical/unreliable. It also does not scale well. I
> would like us to b
On Wed, Apr 10, 2013 at 3:30 PM, Daniel Buchner wrote:
> @John - in my opinion, is the wrong
> direction. You should be declaring which *template* an *element* uses, not
> which element a template captures. Having templates latch onto element
> types from afar breaks the one-to-many case, preven
On Thu, May 17, 2012 at 10:10 AM, Tab Atkins Jr. wrote:
> On Thu, May 17, 2012 at 9:56 AM, John J Barton
> wrote:
>> On Thu, May 17, 2012 at 9:29 AM, Rick Waldron wrote:
>>> Consider the cowpath metaphor - web developers have made highways out of
>>> sticks, g
On Thu, May 17, 2012 at 9:29 AM, Rick Waldron wrote:
> Consider the cowpath metaphor - web developers have made highways out of
> sticks, grass and mud - what we need is someone to pour the concrete.
I'm confused. Is the goal shorter load times (Yehuda) or better
developer ergonomics (Waldron)?
On Wed, May 16, 2012 at 9:53 AM, Dimitri Glazkov wrote:
> I think it's a great idea. Shipping less code over the wire seems like
> a win from any perspective.
How about a cross-site secure (even pre-compiled) cache for JS
libraries as well? We almost have this with CDN now, if it were
formally s
On Tue, Feb 14, 2012 at 10:39 PM, Jonas Sicking wrote:
...
> The problem is when you have functions which call yieldUntil. I.e.
> when you have code like this:
>
> function doStuff() {
> yieldUntil("x");
> };
>
> now what looks like perfectly safe innocent code:
>
> function myFunction() {
> ...
On Tue, Feb 14, 2012 at 11:14 AM, David Bruant wrote:
> Le 14/02/2012 14:31, Arthur Barstow a écrit :
> Another addition will be promises.
> An already working example of promises can be found at
> https://github.com/kriskowal/q
Just to point out that promises are beyond the working example stag
On Mon, Feb 13, 2012 at 12:57 PM, Ian Hickson wrote:
> On Fri, 10 Feb 2012, John J Barton wrote:
>> >
>> > Why would the connectivity part of this be the hard part?
>>
>> Because the existing information on cross-domain iframe communications
>> is inco
On Mon, Feb 13, 2012 at 11:44 AM, Ian Hickson wrote:
> On Thu, 17 Nov 2011, Joshua Bell wrote:
>>
>> Wouldn't it be lovely if the Worker script could simply make a
>> synchronous call to fetch data from the Window?
>
> It wouldn't be so much a synchronous call, so much as a blocking get.
>..
> Any
On Fri, Feb 10, 2012 at 1:37 PM, Ian Hickson wrote:
> On Fri, 10 Feb 2012, John J Barton wrote:
>> On Fri, Feb 10, 2012 at 10:58 AM, Ian Hickson wrote:
>> > On Fri, 10 Feb 2012, John J Barton wrote:
>> >>
>> >> Just to clarify, I want to see the layer
On Fri, Feb 10, 2012 at 10:58 AM, Ian Hickson wrote:
> On Fri, 10 Feb 2012, John J Barton wrote:
>> >
>> > What I meant was just to do this on the receiving side (inside the
>> > iframe), after the onmessage handler has been set up (which we are
>> > assu
On Fri, Feb 10, 2012 at 10:58 AM, Ian Hickson wrote:
> On Fri, 10 Feb 2012, John J Barton wrote:
>>
>> Just to clarify, I want to see the layer you just outlined be standard
>> so we can design iframe components and apps to mix and match. This can
>> be two simple laye
On Thu, Feb 9, 2012 at 11:53 PM, Ian Hickson wrote:
> On Thu, 9 Feb 2012, John J Barton wrote:
>> On Thu, Feb 9, 2012 at 4:42 PM, Ian Hickson wrote:
>> > On Thu, 9 Feb 2012, John J Barton wrote:
>> >>
>> >> However the solution has two significant probl
On Thu, Feb 9, 2012 at 4:42 PM, Ian Hickson wrote:
> On Thu, 9 Feb 2012, John J Barton wrote:
>>
>> However the solution has two significant problems:
>> 1. There is no way to know if portToOtherWindow is connected before
>> you issue postMessage()
>
> Just have
On Thu, Feb 9, 2012 at 11:49 AM, Boris Zbarsky wrote:
> That doesn't help with the second problem, of course
Ok here are some ideas, riffing off the web messaging doc
1 To iframe element add:
readonly attribute MessagePort port;
'message' events from the iframe to the containing window
On Thu, Feb 9, 2012 at 11:49 AM, Boris Zbarsky wrote:
> On 2/9/12 1:15 PM, John J Barton wrote:
>>
>> This leads developers to look for events that will tell them about
>> 'load' on iframes, and that leads them to try
>> iframe.contentWindow.addEventList
Recently I've been working with iframe messaging. The postMessage
solution has a lot of advantages and good traction across iframes,
WebWorkers, and browser extensions, with lots of overlap with Web
Sockets.
However the technology has two significant problems. First is the
"contentWindow that is
On Thu, Feb 9, 2012 at 10:01 AM, Boris Zbarsky wrote:
> On 2/9/12 12:43 PM, John J Barton wrote:
>>>
>>> The drawback is that your fallback behavior in UAs without support for
>>> the
>>> new feature is quite different. Is that a problem? Develop
On Thu, Feb 9, 2012 at 9:22 AM, Boris Zbarsky wrote:
> On 2/9/12 12:04 PM, John J Barton wrote:
>>
>> As far as I can tell, a cross-domain iframe contentWindow has only one
>> valid property, postMessage(). By no stretch of anyone's imagination
>> is the object a
I've been working with cross-domain iframes. This technology has a lot
of potential, but the current API is very difficult to use. Just
search the web for cross-domain iframe info and you can read how many
developers are confused.
I believe a simple change could make a huge difference. My suggesti
On Thu, Oct 27, 2011 at 12:35 AM, Kentaro Hara wrote:
>
> ...
> John-David wrote:
> > Something like Element('') is so so soo nice compared with more
> > verbose alternatives and you can still add attributes to elements via
> > a second argument. I know some prefer smth like Element('div#foo') ->
On Thu, Sep 22, 2011 at 2:36 PM, Ian Hickson wrote:
> There's no difference between two people coming up with the name "foo" and
> two people coming up with the name "http://webintents.org/foo";, unless
> you're saying you're confident that people won't use the prefix the spec
> uses for its verbs
On Thu, Sep 22, 2011 at 5:22 PM, Charles Pritchard wrote:
>> I don't see why. Just have a wiki page that people can list their verbs on
>> and then point to their documentation.
>
> I agree here. The "standard" is sufficient for stewardship.
Why won't I create a bot that fills with wiki with a di
On Thu, Aug 25, 2011 at 1:41 AM, Olli Pettay wrote:
> One thing missing is some kind of declarative way to define
> shadow trees, similar to XBL1's .
>
> I think this omission is a big plus. XBL1 is mysterious. If a
dev tool wants to add support for building Components from declarative
markup, a
I'm still trying to digest this, but it seem pretty clear the 'confinement'
is the "clear scope" thing I was asking about on es-discuss. According to
that discussion, this means needs to fit with the 'modules' thing on
ecmascript. That seems to be where you are headed, but basing a new proposal
on
On Wed, Aug 24, 2011 at 7:50 PM, Dimitri Glazkov wrote:
> > Independent of our different point of view on control, shadow DOM needs
> > debug APIs. So much the better if these are available to extensions.
>
> Let me see if I can capture this into a feature: user scripts may have
> access to shado
On Wed, Aug 24, 2011 at 2:30 PM, Dominic Cooney wrote:
> On Thu, Aug 25, 2011 at 2:03 AM, Dimitri Glazkov
> wrote:
> > Yes, shadow DOM gives the author an extra lever to control visibility
> > and hackability of their code. It's up to them to use this lever
> > wisely.
>
Maybe I grew up on to m
On 7/8/2011 1:18 PM, Dimitri Glazkov wrote:
As a background for the wider Component Model discussion, I put
together an overview of the general behavior attachment problem on the
Web:
http://wiki.whatwg.org/wiki/Behavior_Attachment
Please take a look. Comments, additions, and critique are appre
On 7/7/2011 6:38 PM, Jonas Sicking wrote:
On Thu, Jul 7, 2011 at 5:23 PM, Rafael Weinstein wrote:
So yes, my proposal only solves the usecase outside mutation handlers.
However this is arguably better than never solving the use case as in
your proposal. I'm sure people will end up writing buggy
Olli Pettay wrote:
On 07/08/2011 01:43 AM, John J Barton wrote:
Rafael Weinstein wrote:
On Thu, Jul 7, 2011 at 1:58 PM, Ryosuke Niwa wrote:
On Thu, Jul 7, 2011 at 12:18 PM, Jonas Sicking
wrote:
I don't think John J Barton's proposal to fire "before mutation
notification
Rafael Weinstein wrote:
On Thu, Jul 7, 2011 at 1:58 PM, Ryosuke Niwa wrote:
On Thu, Jul 7, 2011 at 12:18 PM, Jonas Sicking wrote:
I don't think John J Barton's proposal to fire "before mutation
notifications" is doable.
I concur. Being synchronous was one of the reasons why t
Jonas Sicking wrote:
We are definitely
short on use cases for mutation events in general which is a problem.
1. Graphical breakpoints. The user marks some DOM element or attribute
to trigger break. The debugger inserts mutation listeners to watch for
the event that causes that element/attri
On 7/6/2011 6:06 PM, Allen Wirfs-Brock wrote:
I'd much prefer to see code that looks like:
try {doSomeDOMStuff() }
catch (e) {
switch (e.name) {
case "NoNotificationAllowedError": ...; break;
case "HierarchyRequestError": ...; break;
On 7/6/2011 5:38 AM, Boris Zbarsky wrote:
On 7/6/11 4:27 AM, Dave Raggett wrote:
How does that scale to the case where you set the observer on the
document or on a div element acting as a contained for content editable
content? If I am not mistaken you would have to keep a copy of the
document,
On 7/4/2011 6:39 PM, Boris Zbarsky wrote:
On 7/4/11 12:23 PM, John J. Barton wrote:
By restricting mutation listeners to explicitly avoid DOM mutation, the
most sophisticated case is no different than the simple case. Then all
three can be accommodated.
If such a restriction were feasible
On 7/4/2011 6:34 PM, Boris Zbarsky wrote:
On 7/4/11 12:09 PM, John J. Barton wrote:
In the current proposal, the DOM API is manipulated while the
onModelChange mutation listeners run.
Citation please? I see nothing like that in the proposal.
http://www.mail-archive.com/public-webapps@w3.org
On 7/4/2011 9:38 AM, Olli Pettay wrote:
On 07/04/2011 07:23 PM, John J. Barton wrote:
On 7/3/2011 1:23 PM, Boris Zbarsky wrote:
On 7/3/11 2:43 PM, John J. Barton wrote:
I'm not sure what you're asking... The whole point of the proposed
model is that if someone tries to do a mu
On 7/3/2011 1:23 PM, Boris Zbarsky wrote:
On 7/3/11 2:43 PM, John J. Barton wrote:
I'm not sure what you're asking... The whole point of the proposed
model is that if someone tries to do a mutation the mutation _will_
happen and will complete. _Then_ listeners, if any, will b
On 7/3/2011 10:26 AM, Ryosuke Niwa wrote:
On Sun, Jul 3, 2011 at 8:41 AM, John J. Barton
mailto:johnjbar...@johnjbarton.com>> wrote:
On 7/2/2011 8:50 PM, Boris Zbarsky wrote:
On 7/2/11 1:46 PM, John J. Barton wrote:
2) element transformation. The replacement
On 7/3/2011 10:25 AM, Ryosuke Niwa wrote:
On Sun, Jul 3, 2011 at 10:04 AM, John J. Barton
mailto:johnjbar...@johnjbarton.com>> wrote:
The only part that is async in the Mutation Event replacement is
further DOM events.
No! Consider execCommand. To notify scripts of node re
On 7/2/2011 12:36 PM, Ryosuke Niwa wrote:
On Sat, Jul 2, 2011 at 10:46 AM, John J. Barton
wrote:
1) break on mutation. In Firebug we add DOM mutation listeners to
implement graphical breakpoints. The replacement would work fine for
local, element observation breakpoints like add/remove
On 7/2/2011 8:50 PM, Boris Zbarsky wrote:
On 7/2/11 1:46 PM, John J. Barton wrote:
2) element transformation. The replacement fires "after" a mutation.
Library or tools that want to transform the application dynamically want
to get notification "before" the mutation. A com
Olli Pettay
Tue, 28 Jun 2011 04:32:14 -0700
These are *not* DOM-Event listeners. No DOM Events are created, there
are no capture phases or bubbling phases. Instead you register a
listener on the node you are interested in being notified about, and
will get a call after a mutation takes place.
Ian Hickson wrote:
On Wed, 29 Apr 2009, John J Barton wrote:
So why call the property |length|? Wouldn't an enumerable JS host object
be just as fabulous with getNumberOfItems()?
All the other host objects use |length|.
For purposes that I hope are
Ian Hickson wrote:
On Wed, 29 Apr 2009, John J Barton wrote:
Ian Hickson wrote:
On Thu, 30 Apr 2009, Sean Hogan wrote:
sessionStore[2] = "howdy";
print(sessionStore[2]); // prints null?
print(sessionStore["2"]); // prints "howdy"
To my knowle
Ian Hickson wrote:
On Thu, 30 Apr 2009, Sean Hogan wrote:
sessionStore[2] = "howdy";
print(sessionStore[2]); // prints null?
print(sessionStore["2"]); // prints "howdy"
To my knowledge that's not consistent with any other object or interface
in the browser.
Unless I'm
Anne van Kesteren wrote:
On Wed, 29 Apr 2009 20:51:33 +0200, John J Barton
wrote:
Yes and Firebug has to have special code for HTMLCollection because
this mistake
was made in the past. Now we will have to have different special code
for
Storage. Rather than modeling new API on old mistakes
Ian Hickson wrote:
On Wed, 29 Apr 2009, John J Barton wrote:
Yes and Firebug has to have special code for HTMLCollection because this
mistake was made in the past. Now we will have to have different special
code for Storage. Rather than modeling new API on old mistakes, consider
Ian Hickson wrote:
On Wed, 29 Apr 2009, John J. Barton wrote:
I reiterate my criticism: using a length property in this type is
inconsistent with _javascript_ and with developers expectations about
objects. Every time we use this object we will make pointless mistakes
because
Ian Hickson wrote:
On Tue, 28 Apr 2009, John J. Barton wrote:
And then afterwards the |length| is ? one? three?
One.
If I iterate
for(var i = 0; i < sesssionStore.length; i++) foo(i, sessionStore[i]);
what can I expect in foo()?
(0, null), (1, n
Ian Hickson wrote:
On Tue, 28 Apr 2009, John J. Barton wrote:
I could not figure out from the WebIDL what happens in this case:
sessionStore[2] = "howdy"; // no other keys in sessionStore
I guess this does not work like _javascript_ arrays or objects, rather I
expec
Ian Hickson wrote:
On Tue, 28 Apr 2009, John J Barton wrote:
Sorry, I don't follow what you mean. The loop is possible of course, but
what should the result be? If I have a sessionStorage object |s| with 10
items, the length will be 10. Should I expect |s[i]| for i=0,.
Ian Hickson wrote:
On Tue, 28 Apr 2009, John J. Barton wrote:
Hi. I work on Firebug, a web page debugger for Firefox
(http://getfirebug.com).
In attempting to show developers relevant information about all objects
in their program I was trying to display window.sessionStorage
;.
Using the term "enumeration" to mean "property enumeration" is also
confusing, but I suppose ECMA script made that mistake too long ago.
jjb
--
__
John J. Barton email: johnjbartonjohnjbarton.com
http://www.johnjbarton.com
81 matches
Mail list logo
