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
- 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
On Sat, Nov 23, 2013 at 1:51 AM, Jonas Sicking jo...@sicking.cc wrote:
It would technically be possible to define that script elements
inside the imported documents also run inside a scope object the same
way that modules do. This way imported documents would be less
likely to pollute the
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 good way to let web devs make custom elements block?
-Steve
On Thu, Nov 21, 2013 at 3:07 PM, John J Barton
: scripts that want to run after Import
already have an effective and well known mechanism to delay execution,
listening for load events.
- Daniel
On Nov 22, 2013 8:05 AM, John J Barton johnjbar...@johnjbarton.com
wrote:
I agree that we should allow developers to set 'sync' attribute on link
elements tag
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 dan...@mozilla.comwrote:
On Nov 20, 2013 11:07 AM, John J Barton
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
On Wed, Nov 20, 2013 at 10:41 AM, Daniel Buchner dan...@mozilla.com 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
On Wed, Nov 20, 2013 at 7:34 PM, Ryosuke Niwa rn...@apple.com wrote:
On Nov 21, 2013, at 10:41 AM, Hajime Morrita morr...@google.com 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
On Tue, Nov 19, 2013 at 2:07 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Mon, Nov 18, 2013 at 7:14 PM, Jonas Sicking jo...@sicking.cc 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
, John J Barton
johnjbar...@johnjbarton.com wrote:
On Mon, Nov 18, 2013 at 3:06 PM, Scott Miles sjmi...@google.com 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
Now a correction:
On Tue, Nov 19, 2013 at 4:25 PM, John J Barton
johnjbar...@johnjbarton.comwrote:
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
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
the LINK's onload handler for that.
-Steve
On Mon, Nov 18, 2013 at 10:16 PM, John J Barton
johnjbar...@johnjbarton.com wrote:
Maybe Steve's example[1] could be on JS rather than on components:
System.component(import.php, function(component) {
var content = component.content
only
suggesting a solution that always synchronizes just those blocks of JS that
need order-of-execution and thus never needs 'sync' or 'async' and which
leads us to unify the module story for the Web.
jjb
Scott
On Mon, Nov 18, 2013 at 2:58 PM, John J Barton
johnjbar...@johnjbarton.com wrote
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 a...@google.com wrote:
Hello public-webapps,
I have been following along with web components, and
On Wed, May 15, 2013 at 11:03 AM, Dimitri Glazkov dglaz...@chromium.orgwrote:
On Wed, May 15, 2013 at 10:59 AM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, May 15, 2013 at 10:21 AM, John J Barton
johnjbar...@johnjbarton.com wrote:
On Tue, May 14, 2013 at 8:04 PM, Jonas Sicking jo
On Thu, Apr 18, 2013 at 11:11 PM, Dominic Cooney domin...@google.comwrote:
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++ developer I think your point
...@google.comwrote:
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 element inherit functions that make that object 'be an element', I'm
unsure of the practical value.
To me the critical
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 sjmi...@google.com wrote:
Again, 'readyCallback' exists because it's a Bad Idea to run user code
during parsing
On Mon, Apr 15, 2013 at 9:44 AM, Scott Miles sjmi...@google.com 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
concerns blocking component documents on their own
script tag compilation. Maybe I misunderstood.
jjb
On Mon, Apr 15, 2013 at 9:54 AM, John J Barton
johnjbar...@johnjbarton.com wrote:
On Mon, Apr 15, 2013 at 9:44 AM, Scott Miles sjmi...@google.com wrote:
Why do the constructors
have an x-foo instance in it's markup, and element tags or link
rel=import just like the main document.
Indeed, however the relative order of the component's script tag processing
and the component's tag element is all I was talking about.
On Mon, Apr 15, 2013 at 11:23 AM, John J Barton
, more so than whether the API is inheritance-like or not.
On Mon, Apr 15, 2013 at 1:46 PM, John J Barton
johnjbar...@johnjbarton.com wrote:
What happens if the construction/initialization of the custom element
calls one of the element's member functions overridden by code in a
prototype
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 Corporation
On Mon, Apr 15, 2013 at 2:23 PM, John J Barton
johnjbar...@johnjbarton.com wrote
While I completely understand the beauty of having any JS object bound to
an element 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
On Thu, Apr 11, 2013 at 7:57 AM, Erik Arvidsson a...@chromium.org 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
On Wed, Apr 10, 2013 at 3:30 PM, Daniel Buchner dan...@mozilla.com wrote:
@John - in my opinion, template bindtotagname=my-yay 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
On Thu, May 17, 2012 at 9:29 AM, Rick Waldron waldron.r...@gmail.com 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
On Thu, May 17, 2012 at 10:10 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Thu, May 17, 2012 at 9:56 AM, John J Barton
johnjbar...@johnjbarton.com wrote:
On Thu, May 17, 2012 at 9:29 AM, Rick Waldron waldron.r...@gmail.com wrote:
Consider the cowpath metaphor - web developers have made
On Wed, May 16, 2012 at 9:53 AM, Dimitri Glazkov dglaz...@chromium.org 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,
On Tue, Feb 14, 2012 at 10:39 PM, Jonas Sicking jo...@sicking.cc 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 bruan...@gmail.com 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
On Mon, Feb 13, 2012 at 11:44 AM, Ian Hickson i...@hixie.ch 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.
..
On Mon, Feb 13, 2012 at 12:57 PM, Ian Hickson i...@hixie.ch 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 incomplete and written in terms few Web app
On Thu, Feb 9, 2012 at 11:53 PM, Ian Hickson i...@hixie.ch wrote:
On Thu, 9 Feb 2012, John J Barton wrote:
On Thu, Feb 9, 2012 at 4:42 PM, Ian Hickson i...@hixie.ch wrote:
On Thu, 9 Feb 2012, John J Barton wrote:
However the solution has two significant problems:
1. There is no way
On Fri, Feb 10, 2012 at 10:58 AM, Ian Hickson i...@hixie.ch 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 layers on the current
On Fri, Feb 10, 2012 at 10:58 AM, Ian Hickson i...@hixie.ch 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
assuming happens after the 'load' event
On Fri, Feb 10, 2012 at 1:37 PM, Ian Hickson i...@hixie.ch wrote:
On Fri, 10 Feb 2012, John J Barton wrote:
On Fri, Feb 10, 2012 at 10:58 AM, Ian Hickson i...@hixie.ch wrote:
On Fri, 10 Feb 2012, John J Barton wrote:
Just to clarify, I want to see the layer you just outlined be
standard
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
On Thu, Feb 9, 2012 at 9:22 AM, Boris Zbarsky bzbar...@mit.edu 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 window. Calling this thing
On Thu, Feb 9, 2012 at 10:01 AM, Boris Zbarsky bzbar...@mit.edu 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? Developer feedback
definitely needed
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 11:49 AM, Boris Zbarsky bzbar...@mit.edu 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.addEventListener(). It works fine for same
On Thu, Feb 9, 2012 at 11:49 AM, Boris Zbarsky bzbar...@mit.edu 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
On Thu, Feb 9, 2012 at 4:42 PM, Ian Hickson i...@hixie.ch 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 the target message you when
On Thu, Sep 22, 2011 at 2:36 PM, Ian Hickson i...@hixie.ch 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
On Thu, Sep 22, 2011 at 5:22 PM, Charles Pritchard ch...@jumis.com 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
On Thu, Aug 25, 2011 at 1:41 AM, Olli Pettay olli.pet...@helsinki.fiwrote:
One thing missing is some kind of declarative way to define
shadow trees, similar to XBL1's content.
I think this omission is a big plus. XBL1 content is mysterious. If a
dev tool wants to add support for building
On Wed, Aug 24, 2011 at 2:30 PM, Dominic Cooney domin...@google.com wrote:
On Thu, Aug 25, 2011 at 2:03 AM, Dimitri Glazkov dglaz...@chromium.org
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
On Wed, Aug 24, 2011 at 7:50 PM, Dimitri Glazkov dglaz...@chromium.orgwrote:
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
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 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
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
Rafael Weinstein wrote:
On Thu, Jul 7, 2011 at 1:58 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Thu, Jul 7, 2011 at 12:18 PM, Jonas Sicking jo...@sicking.cc wrote:
I don't think John J Barton's proposal to fire before mutation
notifications is doable.
I concur. Being
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 rn...@webkit.org wrote:
On Thu, Jul 7, 2011 at 12:18 PM, Jonas Sicking jo...@sicking.cc
wrote:
I don't think John J Barton's proposal to fire before mutation
On 7/7/2011 6:38 PM, Jonas Sicking wrote:
On Thu, Jul 7, 2011 at 5:23 PM, Rafael Weinsteinrafa...@google.com 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
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/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/3/2011 10:26 AM, Ryosuke Niwa wrote:
On Sun, Jul 3, 2011 at 8:41 AM, John J. Barton
johnjbar...@johnjbarton.com 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
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 be notified
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 mutation
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 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/2/2011 12:36 PM, Ryosuke Niwa wrote:
On Sat, Jul 2, 2011 at 10:46 AM, John J. Barton
johnjbar...@johnjbarton.com 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
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 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, null), (2
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 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
Anne van Kesteren wrote:
On Wed, 29 Apr 2009 20:51:33 +0200, John J Barton
johnjbar...@johnjbarton.com 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
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,..., 9
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
72 matches
Mail list logo
