Myself and a few other chromium folks have been working on a design
for a formalized separation between View and Model in the browser,
with needs of web applications being the primary motivator.
Our ideas are implemented as an experimental Javascript library:
https://code.google.com/p/mdv/ and
2011 01:35, Rafael Weinstein rafa...@google.com wrote:
Myself and a few other chromium folks have been working on a design
for a formalized separation between View and Model in the browser,
with needs of web applications being the primary motivator.
Our ideas are implemented as an experimental
...@helsinki.fi wrote:
HI Rafael,
few random comments, or mainly just random questions :)
On 04/23/2011 03:35 AM, Rafael Weinstein wrote:
Myself and a few other chromium folks have been working on a design
for a formalized separation between View and Model in the browser,
with needs of web
...@apple.com wrote:
On Apr 27, 2011, at 6:46 PM, Rafael Weinstein wrote:
What do you think?
- Is this something you'd like to be implemented in the browsers,
Yes.
and if yes, why? What would be the reasons to not just use script
libraries (like your prototype).
FAQ item also coming
on this problem detailing our best
understanding, and make an attempt to loop in library authors to get their
view.
On Thu, Apr 28, 2011 at 2:02 AM, Maciej Stachowiak m...@apple.com wrote:
On Apr 27, 2011, at 6:46 PM, Rafael Weinstein wrote:
What do you think?
- Is this something you'd
On Wed, Jun 29, 2011 at 7:13 AM, Aryeh Gregor simetrical+...@gmail.com wrote:
On Tue, Jun 28, 2011 at 5:24 PM, Jonas Sicking jo...@sicking.cc wrote:
This new proposal solves both these by making all the modifications
first, then firing all the events. Hence the implementation can
separate
On Thu, Jun 30, 2011 at 4:05 AM, Olli Pettay olli.pet...@helsinki.fi wrote:
On 06/30/2011 12:54 AM, Rafael Weinstein wrote:
On Wed, Jun 29, 2011 at 7:13 AM, Aryeh Gregorsimetrical+...@gmail.com
wrote:
On Tue, Jun 28, 2011 at 5:24 PM, Jonas Sickingjo...@sicking.cc wrote:
This new proposal
On Fri, Jul 1, 2011 at 12:43 PM, David Flanagan dflana...@mozilla.com wrote:
On 7/1/11 12:13 PM, Boris Zbarsky wrote:
On 7/1/11 3:05 PM, David Flanagan wrote:
I don't think I really explained my use case on this list. See
https://bugzilla.mozilla.org/show_bug.cgi?id=641821#c23 and
On Fri, Jul 1, 2011 at 3:25 PM, David Flanagan dflana...@mozilla.com wrote:
On 7/1/11 3:06 PM, Olli Pettay wrote:
On 07/02/2011 12:59 AM, David Flanagan wrote:
But, and I think this is an interesting but, what happens if a node is
removed from the document, has its attributes or data or
Respond
On Tue, Jul 5, 2011 at 10:44 AM, Olli Pettay olli.pet...@helsinki.fi wrote:
On 07/01/2011 02:17 AM, Rafael Weinstein wrote:
On Thu, Jun 30, 2011 at 4:05 AM, Olli Pettayolli.pet...@helsinki.fi
wrote:
On 06/30/2011 12:54 AM, Rafael Weinstein wrote:
On Wed, Jun 29, 2011 at 7:13 AM
On Mon, Jul 4, 2011 at 6:43 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 7/4/11 12:28 PM, Ojan Vafai wrote:
I'm not sure there really is a performance tradeoff. I believe that the
proposal Rafael put forward should almost always be faster. Storing the
list of changes and doing a JS callback
On Mon, Jul 4, 2011 at 9:57 AM, Olli Pettay olli.pet...@helsinki.fi wrote:
On 07/04/2011 07:28 PM, Ojan Vafai wrote:
Apologies in advance if my comment makes no sense. This is a long
thread, I tried to digest it all. :)
On Sat, Jul 2, 2011 at 7:07 AM, Boris Zbarsky bzbar...@mit.edu
On Tue, Jul 5, 2011 at 2:27 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 7/5/11 5:21 PM, Rafael Weinstein wrote:
For ChildlistChanged, the potential data to be included:
-Target node*
-Removed nodes*
-Added nodes
-one of nextSibling or previousSibling*
My belief is that including
On Tue, Jul 5, 2011 at 2:29 PM, Rafael Weinstein rafa...@google.com wrote:
On Tue, Jul 5, 2011 at 2:27 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 7/5/11 5:21 PM, Rafael Weinstein wrote:
For ChildlistChanged, the potential data to be included:
-Target node*
-Removed nodes*
-Added nodes
On Tue, Jul 5, 2011 at 2:38 PM, Olli Pettay olli.pet...@helsinki.fi wrote:
On 07/06/2011 12:18 AM, Olli Pettay wrote:
On 07/06/2011 12:06 AM, Rafael Weinstein wrote:
Respond
On Tue, Jul 5, 2011 at 10:44 AM, Olli Pettayolli.pet...@helsinki.fi
wrote:
On 07/01/2011 02:17 AM, Rafael
On Tue, Jul 5, 2011 at 3:55 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Tue, Jul 5, 2011 at 3:24 PM, Olli Pettay olli.pet...@helsinki.fi wrote:
On 07/06/2011 12:48 AM, Rafael Weinstein wrote:
On Tue, Jul 5, 2011 at 2:38 PM, Olli Pettayolli.pet...@helsinki.fi
wrote:
What is the reason
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 synchronous was one of the reasons why the
On Thu, Jul 7, 2011 at 3:19 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Jul 7, 2011 at 2:32 PM, Rafael Weinstein rafa...@google.com 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
On Tue, Jul 19, 2011 at 4:56 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Jul 19, 2011 at 4:18 PM, Ryosuke Niwa rn...@webkit.org wrote:
Thanks for the new proposal, Jonas. I'm very excited about the progress
we're making towards a saner world!
On Tue, Jul 19, 2011 at 4:01 PM, Jonas
What follows is an attempt to summarize the (relatively recent)
discussions regarding replacing DOM Mutation Events.
My goals here are to:
-Provide a quick primer for those who haven't read all hundred or so emails.
-Reiterate the aspects of a solution which seem to have broad support.
-Identify
Although everyone seems to agree that mutations should be delivered
after the DOM operations which generated them complete, the question
remains:
When, exactly, should mutations be delivered?
The four options I'm aware of are:
1) Immediately - i.e. while the operation is underway. [Note: This
Ok. Being a proponent, here's my further (opinionated) support for
Option 3 and criticism for Option 2.
On Wed, Aug 10, 2011 at 5:44 PM, Rafael Weinstein rafa...@google.com wrote:
Although everyone seems to agree that mutations should be delivered
after the DOM operations which generated them
...@helsinki.fi wrote:
On 08/11/2011 03:44 AM, Rafael Weinstein wrote:
Although everyone seems to agree that mutations should be delivered
after the DOM operations which generated them complete, the question
remains:
When, exactly, should mutations be delivered?
The four options I'm aware of are:
1
On Thu, Aug 11, 2011 at 9:12 AM, Olli Pettay olli.pet...@helsinki.fi wrote:
On 08/11/2011 06:13 PM, Rafael Weinstein wrote:
Con:
Since the approach is bound to tasks, it is not clear what should happen
if event loop spins while handling the task. What if some other task
modifies the DOM[1
TL;DR;
1) ObserveSubtree semantics doesn't provide a robust mechanism for
observing a tree/fragment, and if we don't provide something more
complete, libraries will likely register observers at every node in
the document.
2) Not providing position information (e.g childlistIndex) in
On Wed, Aug 17, 2011 at 3:17 AM, Olli Pettay olli.pet...@helsinki.fi wrote:
On 08/17/2011 04:54 AM, Rafael Weinstein wrote:
TL;DR;
1) ObserveSubtree semantics doesn't provide a robust mechanism for
observing a tree/fragment, and if we don't provide something more
complete, libraries
Hi Sean,
I find it hard to reason about cases in the abstract. None of the
examples you list seem concerning to me (i.e. I believe they can be
properly handled), but perhaps it's a failure of my imagination.
Maybe you can provide concrete examples (i.e. with code snippets,
actual instances of
[This time from the right email]
On Wed, Feb 8, 2012 at 2:10 PM, Adam Barth w...@adambarth.com wrote:
Re-using the generic raw text element parsing algorithm would be the
simplest change to the parser. Do you have a concrete example of
where nested template declarations are required? For
Here's a real-world example, that's probably relatively simple
compared to high traffic web pages (i.e. amazon or facebook)
http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/docs/template/api_template.html?revision=120962content-type=text%2Fplain
that produces each page of
On Wed, Feb 8, 2012 at 3:16 PM, Adam Barth w...@adambarth.com wrote:
On Wed, Feb 8, 2012 at 2:47 PM, Rafael Weinstein rafa...@chromium.org wrote:
Here's a real-world example, that's probably relatively simple
compared to high traffic web pages (i.e. amazon or facebook)
http://src.chromium.org
On Mon, Apr 2, 2012 at 3:21 PM, Dimitri Glazkov dglaz...@chromium.org wrote:
On Wed, Feb 8, 2012 at 11:25 PM, Henri Sivonen hsivo...@iki.fi wrote:
On Thu, Feb 9, 2012 at 12:00 AM, Dimitri Glazkov dglaz...@chromium.org
wrote:
== IDEA 1: Keep template contents parsing in the tokenizer ==
Not
On Wed, Apr 18, 2012 at 9:32 AM, Dimitri Glazkov dglaz...@chromium.org wrote:
On Wed, Apr 18, 2012 at 7:49 AM, Henri Sivonen hsivo...@iki.fi wrote:
On Tue, Apr 3, 2012 at 1:21 AM, Dimitri Glazkov dglaz...@chromium.org
wrote:
Perhaps lost among other updates was the fact that I've gotten the
/html/script-ish markup with access to
textContent.
On Thu, Apr 19, 2012 at 1:56 AM, Rafael Weinstein rafa...@google.com
wrote:
On Wed, Apr 18, 2012 at 2:54 PM, Dimitri Glazkov dglaz...@chromium.org
wrote:
On Wed, Apr 18, 2012 at 2:31 PM, James Graham jgra...@opera.com
wrote:
On Wed
/Public/public-webapps/2011OctDec/0663.html ?
On Mon, Apr 23, 2012 at 8:39 PM, Rafael Weinstein rafa...@google.com
wrote:
The main points of contention in the discussion about the template element
are
1) By what mechanism are its content elements 'inert'
2) Do template contents reside
frag.innerHTML = div/divtr/tr
div
frag.innerHTML = tr/trdiv/div
tbody
tr
div
frag.innerHTML = gpath//g
g
path
[Note that innerHTML doesn't work presently on SVGElements in WebKit
or Gecko, but this last example would result if it did]
On Tue, Apr 24, 2012 at 5:26 AM, Rafael Weinstein rafa
On Wed, Apr 25, 2012 at 12:39 PM, Rafael Weinstein rafa...@google.com wrote:
Ok, so from the thread that Yehuda started last year,
There seem to be three issues:
1) Interop (e.g. WRT IE)
2) Defining the behavior for all elements
3) HTML vs SVG vs MathML
I think what Yehuda outlined
Henri,
Does this address the concerns you raised earlier?
On Thu, Apr 26, 2012 at 10:23 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Thu, Apr 26, 2012 at 1:26 AM, Simon Pieters sim...@opera.com wrote:
On Wed, 25 Apr 2012 21:39:53 +0200, Rafael Weinstein rafa...@google.com
wrote:
Any
On Thu, Apr 26, 2012 at 1:33 AM, Anne van Kesteren ann...@opera.com wrote:
On Thu, 26 Apr 2012 10:05:28 +0200, Ryosuke Niwa rn...@webkit.org wrote:
Also, I think Anne convinced me that it's better to deduce the insertion
mode from the first element than inventing a new insertion mode (I've
On Mon, Apr 30, 2012 at 6:51 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Mon, Apr 30, 2012 at 5:43 PM, Anne van Kesteren ann...@opera.com wrote:
I personally think it would be better if HTML kept defining all entry points
to the HTML parser. And at least conceptually this is a new
Is it worth separating the issues of fallback behavior and extracting
element semantics?
It strikes me as unlikely that in practice components *can* be used if
you need to target legacy browsers, and that fallback won't mean much
unless legacy browsers are specifically targeted because proper
, Rafael Weinstein rafa...@google.com wrote:
What doesn't appear to be controversial is the parser changes which
would allow the template element to have arbitrary top-level content
elements.
It's not controversial as long as an HTML context is assumed. I think
it is still controversial for SVG
On Wed, May 9, 2012 at 12:51 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 9 May 2012, Jonas Sicking wrote:
I think having to provide a context every wherewhere you want to
parse HTML is creating very bad developer ergonomics.
You wouldn't have to provide it everywhere. The vast majority of
On Wed, May 9, 2012 at 1:32 PM, Rafael Weinstein rafa...@google.com wrote:
On Wed, May 9, 2012 at 12:51 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 9 May 2012, Jonas Sicking wrote:
I think having to provide a context every wherewhere you want to
parse HTML is creating very bad developer
On Thu, May 10, 2012 at 4:01 PM, Ian Hickson i...@hixie.ch wrote:
On Fri, 11 May 2012, Tab Atkins Jr. wrote:
The innerHTML API is convenient. It lets you set the entire descendant
tree of an element, creating elements and giving them attributes, in a
single call, using the same syntax you'd
On Thu, May 10, 2012 at 4:27 PM, Scott González
scott.gonza...@gmail.com wrote:
On Thu, May 10, 2012 at 7:15 PM, Rafael Weinstein rafa...@google.com
wrote:
On Thu, May 10, 2012 at 4:01 PM, Ian Hickson i...@hixie.ch wrote:
If we're going to do that, then we don't need any lookahead at all. We
On Thu, May 10, 2012 at 4:58 PM, Ian Hickson i...@hixie.ch wrote:
On Thu, 10 May 2012, Rafael Weinstein wrote:
Also, I'm curious why it's ok to peak at the first few characters of the
string, and not ok to peak at the token stream until we see the first
start tag?
Because it's predictable
On Thu, May 10, 2012 at 5:03 PM, Ian Hickson i...@hixie.ch wrote:
On Fri, 11 May 2012, Tab Atkins Jr. wrote:
For something like this:
$(pExample +exnum+:/ppimg src=+exsrc+).appendTo(container);
Can we really not come up with anything better? It makes me really sad to
think that the best we
On Thu, May 10, 2012 at 4:19 PM, Ian Hickson i...@hixie.ch wrote:
On Thu, 10 May 2012, Rafael Weinstein wrote:
On Thu, May 10, 2012 at 4:01 PM, Ian Hickson i...@hixie.ch wrote:
On Fri, 11 May 2012, Tab Atkins Jr. wrote:
But ok, let's assume that the use case is create an element and its
On Fri, May 11, 2012 at 12:13 AM, Ojan Vafai o...@chromium.org wrote:
On Thu, May 10, 2012 at 9:28 PM, Rafael Weinstein rafa...@google.com
wrote:
On Thu, May 10, 2012 at 4:19 PM, Ian Hickson i...@hixie.ch wrote:
On Thu, 10 May 2012, Rafael Weinstein wrote:
On Thu, May 10, 2012 at 4:01 PM
, 2012 at 3:07 AM, Charles McCathieNevile
cha...@opera.com wrote:
On Fri, 11 May 2012 10:55:27 +0200, Henri Sivonen hsivo...@iki.fi wrote:
On Wed, May 9, 2012 at 7:45 PM, Rafael Weinstein rafa...@google.com
wrote:
I'm very much of a like mike with Henri here, in that I'm frustrated
It feels like we're making progress here. It seems as though there are
basically two camps:
1) We shouldn't attempt to solve this problem. E.g. an explicit
context element should be required for fragment parsing.
2) The basic idea of inferring a context element is workable and there
are details
Ok,
So from the previous threads, there are appear to be three issues to
resolve, and I'll list the options that I've noted.
I'll follow up with my perspective of pros/cons and ask others to do
the same. Please point out options or issues that I've missed.
Issue 1: How to handle tokens
Ok, so I have some preferences, but they are *mild* preferences and
any permutation of the options below is acceptable to me.
On Fri, May 11, 2012 at 12:04 PM, Rafael Weinstein rafa...@google.com wrote:
Ok,
So from the previous threads, there are appear to be three issues to
resolve, and I'll
Katz wyc...@gmail.com wrote:
Yehuda Katz
(ph) 718.877.1325
On Tue, May 15, 2012 at 6:46 AM, Henri Sivonen hsivo...@iki.fi wrote:
On Fri, May 11, 2012 at 10:04 PM, Rafael Weinstein rafa...@google.com
wrote:
Issue 1: How to handle tokens which precede the first start tag
Options
On Wed, May 16, 2012 at 4:49 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, May 16, 2012 at 4:29 PM, Rafael Weinstein rafa...@google.com wrote:
Ok. I think I'm convinced on all points.
I've uploaded a webkit patch which implements what we've agreed on here:
https://bugs.webkit.org
On Wed, May 16, 2012 at 4:52 PM, Rafael Weinstein rafa...@google.com wrote:
On Wed, May 16, 2012 at 4:49 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, May 16, 2012 at 4:29 PM, Rafael Weinstein rafa...@google.com wrote:
Ok. I think I'm convinced on all points.
I've uploaded a webkit patch
This seems sensible. I've updated the WebKit patch to do exactly this:
https://bugs.webkit.org/show_bug.cgi?id=84646
It appears that the details of the proposal are now sorted out. I'll
start a new thread describing the full API semantics.
On Fri, May 18, 2012 at 8:29 PM, Ryosuke Niwa
Ok, so from consensus on earlier threads, here's the full API semantics.
Now's the time to raise objections to UA's adding support for this feature.
-
1) The Document interface is extended to include a new method:
DocumentFragment parse (DOMString markup);
which:
-Invokes the fragment
On Fri, May 25, 2012 at 12:32 AM, Simon Pieters sim...@opera.com wrote:
On Fri, 25 May 2012 09:01:43 +0200, Rafael Weinstein rafa...@google.com
wrote:
Ok, so from consensus on earlier threads, here's the full API semantics.
Now's the time to raise objections to UA's adding support
supportive of the goal of allowing HTML literals in
script. I fully agree that better load (compile) time feedback would
be beneficial to authors here.
On Mon, Jun 4, 2012 at 3:47 PM, Ian Hickson i...@hixie.ch wrote:
On Fri, 25 May 2012, Rafael Weinstein wrote:
Now's the time to raise objections
On Mon, Jun 4, 2012 at 3:50 PM, Ian Hickson i...@hixie.ch wrote:
On Mon, 4 Jun 2012, Tab Atkins Jr. wrote:
[...] We could do this by having the parser insert a fake node into
the stack of open elements just for this purpose, I think. That is,
when switching insertion mode in response to
Yehuda,
Can you help clarify here whether jQuery's behavior is intentional
(i.e. use cases drive the need for executability), or if it's a
side-effect of the implementation?
On Fri, Jun 1, 2012 at 1:27 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Thu, May 31, 2012 at 7:55 AM, Henri Sivonen
On Mon, Jun 11, 2012 at 3:13 PM, Henri Sivonen hsivo...@iki.fi wrote:
On Thu, Jun 7, 2012 at 8:35 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Just saying that querySelector/All doesn't match elements in a
template (unless the scope is inside the template already) would work,
but it means
E4H doesn't address all the use cases of Document.parse().
It doesn't solve the problem of existing templating libraries
constructing DOM fragments from processed templates.
E4H (or something similar) would be great, but I think it's a mistake
to make it mutually exclusive with Document.parse().
I think I'm not understanding the implications of your argument.
You're making a principled argument about future pitfalls. Can you
help me get my head around it by way of example?
Perhaps:
-pitfalls developers fall into
-further dangerous points along the slippery slope you think this
opens up
On Fri, Jun 29, 2012 at 6:14 PM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Jun 29, 2012 at 8:25 PM, Adam Klein ad...@chromium.org wrote:
On Fri, Jun 29, 2012 at 2:44 AM, Jonas Sicking jo...@sicking.cc wrote:
All in all I think that as soon as we introduce exceptions to when
CSS Regions regionLayoutUpdate brings up an issue I think we need to
get ahead of:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16391
For context:
Mutation Observers are currently spec'd in DOM4
http://dom.spec.whatwg.org/#mutation-observers
and delivery timing is defined in
On Thu, Oct 18, 2012 at 2:51 PM, Olli Pettay olli.pet...@helsinki.fi wrote:
On 10/19/2012 12:08 AM, Rafael Weinstein wrote:
CSS Regions regionLayoutUpdate brings up an issue I think we need to
get ahead of:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16391
For context
Thanks for reviewing this (and sorry for the delay -- I was on vacation,
and blissfully unable to read email).
I'm happy (and a little surprised) that there's no comment here about the
HTML parser changes. Is that because it all looks good, or because you
didn't dig that deep into it yet?
The
On Fri, Dec 14, 2012 at 2:58 PM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Dec 14, 2012 at 1:32 AM, Simon Pieters sim...@opera.com wrote:
On Fri, 14 Dec 2012 00:04:20 +0100, Jonas Sicking jo...@sicking.cc
wrote:
On Tue, Dec 11, 2012 at 5:00 AM, Henri Sivonen hsivo...@iki.fi wrote:
Thanks so much! Filed as
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20563
On Wed, Jan 2, 2013 at 11:33 AM, Jens O. Meiert j...@meiert.com wrote:
Hi,
I noticed the following typos in the HTML Templates draft [1]:
* Under “Definitions,” “If DOCUMENT does not have a browsing context,
Note that the spec has moved to FPWD, all of the comments Henri raised have
been addressed and WebKit TOT now contains a full implementation including
tests.
On Fri, Dec 21, 2012 at 1:31 PM, Rafael Weinstein rafa...@google.comwrote:
On Fri, Dec 14, 2012 at 2:58 PM, Jonas Sicking jo
On Tue, Feb 5, 2013 at 3:25 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 2/5/13 11:01 PM, Erik Arvidsson wrote:
On Tue, Feb 5, 2013 at 5:28 PM, Boris Zbarsky bzbar...@mit.edu wrote:
So in particular this allows creation of uninitialized instances in
some
sense, yes?
Depends how much
On Mon, Feb 18, 2013 at 12:06 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Feb 18, 2013 at 1:48 AM, Anne van Kesteren ann...@annevk.nl
wrote:
On Sat, Feb 16, 2013 at 5:23 PM, Dimitri Glazkov dglaz...@google.com
wrote:
We were thinking of adding innerHTML to DocumentFragments anyway...
On Tue, Feb 19, 2013 at 11:42 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Feb 19, 2013 at 12:24 PM, Rafael Weinstein rafa...@google.com
wrote:
On Mon, Feb 18, 2013 at 12:06 PM, Jonas Sicking jo...@sicking.cc
wrote:
On Mon, Feb 18, 2013 at 1:48 AM, Anne van Kesteren ann...@annevk.nl
So the two camps in the this argument seem to be arguing largely
philosophical views.
It's clear that Mozilla has experienced pain via plugins having access
to browser internals.
I'm curious if jQuery or others have experienced feeling restricted
because apps are depending on internals by way of
FWIW (and I'm not sure if this is good or bad) it would be consistent
with the template element if
-shadowroot serialized by default with innerHTML
-shadowroot, when parsed is lifted and pushed onto the parent
element's shadowroot stack
-appendChild(shadowroot) doesn't throw, but doesn't do what
, Rafael Weinstein rafa...@google.com
wrote:
On Wed, Apr 10, 2013 at 11:47 AM, Dimitri Glazkov dglaz...@google.com
wrote:
Dear Webappsonites,
There's been a ton of thinking on what the custom elements declarative
syntax must look like. Here, I present something has near-ideal
developer
On Wed, Apr 10, 2013 at 2:45 PM, Rafael Weinstein rafa...@google.com wrote:
FWIW, I think it's a design mistake to make element registration a
concern of template.
Sorry. I over-stated my conviction here. Let me walk that back: I'm
not yet hearing sufficient justification for making element
Yup. Not sure where this is in W3C DOM, but 12.2.5.1 Creating and inserting
nodes (http://www.whatwg.org/specs/web-apps/current-work/)
...
DOM mutation events must not fire for changes caused by the UA parsing the
document. This includes the parsing of any content inserted using
document.write()
On Mon, Oct 7, 2013 at 3:24 AM, James Graham ja...@hoppipolla.co.uk wrote:
On 06/10/13 17:25, Dimitri Glazkov wrote:
And, if the script is executed against the global/window object of
the main document, can and should you be able to access the imported
document?
You can and
On Wed, Dec 4, 2013 at 10:37 AM, Dimitri Glazkov dglaz...@chromium.orgwrote:
On Wed, Dec 4, 2013 at 9:56 AM, Dimitri Glazkov dglaz...@chromium.orgwrote:
On Wed, Dec 4, 2013 at 4:32 AM, Anne van Kesteren ann...@annevk.nlwrote:
On Wed, Dec 4, 2013 at 9:21 AM, Brian Di Palma off...@gmail.com
On Sat, Dec 7, 2013 at 3:01 PM, Brian Di Palma off...@gmail.com wrote:
From your email it seems you can still achieve everything you can with
custom elements when not using
them, it would just involve more code/boilerplate.
So custom elements without shadow dom or templates are syntactic
On Sat, Dec 7, 2013 at 6:56 PM, Ryosuke Niwa rn...@apple.com wrote:
On Dec 7, 2013, at 3:53 PM, Rafael Weinstein rafa...@google.com wrote:
The issue is that being an element and having shadow DOM -- or any
display DOM, for that matter -- are orthogonal concerns.
There are lots of c
I pushed the Web Components folks about exactly this issue (why aren't
these callbacks just MutationObservers?) early last year. They convinced me
(and I remain convinced) that these signals should be Custom Element
callbacks and not Mutation Observer records
Here's the logic that convinced me:
No objections. It may be useful to mention in the note that the Template
spec was merged to HTML (as opposed to simply becoming a concern of HTML,
which might raise the question did HTML do something different than what
this spec used to say?).
On Wed, Feb 26, 2014 at 12:25 PM, Ryosuke Niwa
What do you recommend?
It seems a little heavy-handed to kill it or gut it. What about putting a
big-red warning at the top that it has been merged to HTML and no longer
has normative weight.
On Thu, Feb 27, 2014 at 7:27 AM, Arthur Barstow art.bars...@nokia.comwrote:
On 2/26/14 9:43 AM, ext
SGTM
On Tue, Mar 11, 2014 at 9:38 AM, Yves Lafon yla...@w3.org wrote:
On Fri, 7 Mar 2014, Arthur Barstow wrote:
On 2/27/14 12:10 PM, ext Arthur Barstow wrote:
On 2/27/14 11:41 AM, ext Rafael Weinstein wrote:
What do you recommend?
It seems a little heavy-handed to kill it or gut
On Wed, Mar 12, 2014 at 8:48 AM, Arthur Barstow art.bars...@nokia.comwrote:
On 3/12/14 10:27 AM, ext Rafael Weinstein wrote:
SGTM
On Tue, Mar 11, 2014 at 9:38 AM, Yves Lafon yla...@w3.org mailto:
yla...@w3.org wrote:
On Fri, 7 Mar 2014, Arthur Barstow wrote:
On 2/27/14 12
89 matches
Mail list logo
