On Dec 8, 2013, at 5:21 PM, Dominic Cooney domin...@google.com wrote:
On Fri, Dec 6, 2013 at 12:49 PM, Ryosuke Niwa rn...@apple.com wrote:
On Dec 5, 2013, at 7:32 PM, Scott Miles sjmi...@google.com wrote:
We don't think decoupling custom elements and shadow DOM completely is
useful given
On Dec 7, 2013, at 3:25 PM, Dominic Cooney domin...@google.com wrote:
On Sat, Dec 7, 2013 at 10:06 AM, Ryosuke Niwa rn...@apple.com wrote:
On Dec 6, 2013, at 5:01 PM, Ryosuke Niwa rn...@apple.com wrote:
On Dec 6, 2013, at 1:20 AM, Brian Di Palma off...@gmail.com wrote:
On Fri, Dec 6, 2013 at 3
features could be used to explain the
functionality of existing Web platform features, such as HTML elements.
as currently stated in the latest WG and ED, then we should not be adding new
magical state to the platform.
- R. Niwa
On Jan 30, 2014, at 3:03 PM, Ryosuke Niwa rn...@apple.com wrote
Hi,
Apparently there has been discussions about hats and cats selector combinators
in www-style:
http://lists.w3.org/Archives/Public/www-style/2014Feb/0032.html
In that Tab (Atkins) from Google made a comment saying that Chrome will be
shipping Shadow DOM in the very near future:
Hi,
Could someone clarify why we want to allow out-of-order registration of custom
elements? Can we also have (a pointer to) concrete use cases for this feature?
The thing is if an author wants to replace or customize a placeholder element
using a script that loads later, that’s pretty easy
On Jan 28, 2014, at 2:11 PM, Jake Archibald jaffathec...@gmail.com wrote:
I'm really fond of the link rel=import elements=x-foo, x-bar pattern,
but I yeah, you could end up with a massive elements list.
How about making link[rel=import] async by default, but make elements with a
dash in
On Jan 27, 2014, at 1:05 PM, Dimitri Glazkov dglaz...@google.com wrote:
On Fri, Jan 24, 2014 at 5:53 PM, Ryosuke Niwa rn...@apple.com wrote:
On Jan 23, 2014, at 2:45 PM, Dimitri Glazkov dglaz...@google.com wrote:
As HTML imports [1] are implemented across browsers, there’s a potential
On Jan 23, 2014, at 2:45 PM, Dimitri Glazkov dglaz...@google.com wrote:
As HTML imports [1] are implemented across browsers, there’s a potential for
diversity of opinion in how rendering of documents with imports occurs. What
blocks rendering?
What doesn’t? To prevent the inevitable pain of
On Jan 10, 2014, at 8:16 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 1/10/14 11:10 AM, Erik Arvidsson wrote:
My hope was that it would be rare to override Symbol.create for Elements
so in most cases we would not need to call user code.
For spec purposes and parser implementation design
Jonas, William, Ted, and I had some discussion about this last month. (Sorry
for the delayed response).
On Dec 5, 2013, at 10:58 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 12/6/13 1:49 AM, Ryosuke Niwa wrote:
Then how do we define a custom element using ES6 classes? Are we going
Also,
http://www.html5rocks.com/en/tutorials/webcomponents/customelements/
and
http://www.polymer-project.org/platform/custom-elements.html
already talk about custom elements as a way of defining (and use) new (types
of DOM) elements.
I mean… even our current working draft says
This
On Dec 11, 2013, at 6:46 PM, Dominic Cooney domin...@google.com wrote:
On Thu, Dec 12, 2013 at 5:17 AM, pira...@gmail.com pira...@gmail.com wrote:
I have seen registerProtocolHandler() and it's being discused
registerServiceWorker(). I believe registerElementDefinition() or
Let's take a look at the original list of use cases proposed in 2008 at
http://www.w3.org/2008/webapps/wiki/Component_Model_Use_Cases:
Layout Manager
Layout Manager Use Case Parameters
Who
Web Framework Engineer
What
Build a layout library, consisting of a UI layout primitives, such as panel,
On Dec 8, 2013, at 12:19 PM, Daniel Freedman dfre...@google.com wrote:
Developers want data-binding, and the auto cloning template does not give
them a favorable timing model.
They want to set those up before the ShadowDOM is stamped, on a per-instance
level.
If they were to use the
On Dec 7, 2013, at 8:33 PM, Rafael Weinstein rafa...@google.com wrote:
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
On Dec 10, 2013, at 9:20 AM, Erik Arvidsson a...@chromium.org wrote:
On Tue, Dec 10, 2013 at 11:15 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Tue, Dec 10, 2013 at 4:10 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
Nevertheless, it would be unfortunate to use the in-progress
On Dec 8, 2013, at 4:42 PM, Dominic Cooney domin...@google.com wrote:
On Sun, Dec 8, 2013 at 7:25 PM, Ryosuke Niwa rn...@apple.com wrote:
On Dec 7, 2013, at 4:38 PM, Dominic Cooney domin...@google.com wrote:
On Fri, Dec 6, 2013 at 3:34 PM, Ryosuke Niwa rn...@apple.com wrote:
On Dec 5, 2013
On Dec 9, 2013, at 5:12 PM, Dominic Cooney domin...@google.com wrote:
On Tue, Dec 10, 2013 at 6:38 AM, Ryosuke Niwa rn...@apple.com wrote:
On Dec 8, 2013, at 4:42 PM, Dominic Cooney domin...@google.com wrote:
On Sun, Dec 8, 2013 at 7:25 PM, Ryosuke Niwa rn...@apple.com wrote:
On Dec 7, 2013
On Dec 9, 2013, at 8:45 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Tue, Dec 10, 2013 at 3:33 PM, Ryosuke Niwa rn...@apple.com wrote:
In fact, why do we even bother to add any new API at all for web components
if our primary target was framework authors. Ember.js, Angular JS, etc...
all
On Dec 9, 2013, at 11:13 AM, Scott Miles sjmi...@google.com wrote:
I'm not wont to try to summarize it here, since he said it already better
there. Perhaps the short version is: nobody knows what the 'standard use
case' is yet.
How is that possible given we've already spent 2+ years on the
On Dec 9, 2013, at 9:34 PM, Ryosuke Niwa rn...@apple.com wrote:
On Dec 9, 2013, at 11:13 AM, Scott Miles sjmi...@google.com wrote:
I'm not wont to try to summarize it here, since he said it already better
there. Perhaps the short version is: nobody knows what the 'standard use
case' is yet
On Dec 9, 2013, at 11:03 PM, Matthew McNulty mmcnu...@google.com wrote:
On Tue, Dec 10, 2013 at 4:04 PM, Ryosuke Niwa rn...@apple.com wrote:
On Dec 9, 2013, at 9:34 PM, Ryosuke Niwa rn...@apple.com wrote:
On Dec 9, 2013, at 11:13 AM, Scott Miles sjmi...@google.com wrote:
I'm not wont to try
On Dec 7, 2013, at 4:38 PM, Dominic Cooney domin...@google.com wrote:
On Fri, Dec 6, 2013 at 3:34 PM, Ryosuke Niwa rn...@apple.com wrote:
On Dec 5, 2013, at 10:09 PM, Hajime Morrita morr...@google.com wrote:
On inheritance around HTMLElement family, there seems to be a confusion
between
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++ HTML elements that have no display DOM. Polymer already
has an even
On Dec 6, 2013, at 7:37 AM, Erik Arvidsson a...@chromium.org wrote:
On Fri, Dec 6, 2013 at 2:33 AM, Ryosuke Niwa rn...@apple.com wrote:
It appears to me that we should definitely have a good answer for this
question before the specification reaches CR
given that the definition of ES6
On Dec 6, 2013, at 1:20 AM, Brian Di Palma off...@gmail.com wrote:
On Fri, Dec 6, 2013 at 3:24 AM, Ryosuke Niwa rn...@apple.com wrote:
On Nov 12, 2013, at 12:45 AM, Ryosuke Niwa rn...@apple.com wrote:
On Nov 12, 2013, at 8:12 AM, Dimitri Glazkov dglaz...@chromium.org wrote:
1
On Dec 6, 2013, at 5:01 PM, Ryosuke Niwa rn...@apple.com wrote:
On Dec 6, 2013, at 1:20 AM, Brian Di Palma off...@gmail.com wrote:
On Fri, Dec 6, 2013 at 3:24 AM, Ryosuke Niwa rn...@apple.com wrote:
On Nov 12, 2013, at 12:45 AM, Ryosuke Niwa rn...@apple.com wrote:
On Nov 12, 2013, at 8:12
On Dec 6, 2013, at 7:41 PM, Elliott Sprehn espr...@chromium.org wrote:
On Thu, Dec 5, 2013 at 5:37 PM, Ryosuke Niwa rn...@apple.com wrote:
Given that many important/natural use cases of custom elements involve shadow
DOM,
can we add a flag to auto-create shadow DOM for custom elements
Hi,
Let me understand the problem of styling/replacing builtin form controls.
As I understand it, people want to do:
select name=cities is=map
optionOakland/option
optionSan Francisco/option
optionSan Jose/option
...
/select
or
input is=switch type=checkbox ...
to have a nice fallback when is
On Dec 5, 2013, at 7:38 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 12/5/13 4:30 AM, Ryosuke Niwa wrote:
As I understand it, people want to do:
select name=cities is=map
That's not the main issue being discussed right now, as far as I can tell.
Sorry, I should have been more explicit
On Dec 4, 2013, at 5:38 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote:
* Ryosuke Niwa wrote:
Now we know that there has been an effort to decouple the various Web
Components
features and specifications, and the Custom Elements specification was going
to
the Last Call on its own
Could someone point me to a discussion/reasoning behind why we're using
createdCallback as opposed to the constructor
as a way of instantiating a custom element?
It's so awkward to have a separate callback in the world where we have ES6
classes.
- R. Niwa
Hi,
Given that many important/natural use cases of custom elements involve shadow
DOM,
can we add a flag to auto-create shadow DOM for custom elements?
In particular, can we add template as the third argument to document.register
so that
when a custom element is instantiated, the specified
On Nov 12, 2013, at 12:45 AM, Ryosuke Niwa rn...@apple.com wrote:
On Nov 12, 2013, at 8:12 AM, Dimitri Glazkov dglaz...@chromium.org wrote:
2) It couples templates, shadow DOM, and custom elements in a way that's
highly opinionated and inflexible. Throughout this year, we've tried many
On Nov 12, 2013, at 12:45 AM, Ryosuke Niwa rn...@apple.com wrote:
On Nov 12, 2013, at 8:12 AM, Dimitri Glazkov dglaz...@chromium.org wrote:
1) It is not friendly to ES6 classes. In fact, you can't use class syntax
and this syntax together.
Okay, let the author define the constructor.
3
On Dec 5, 2013, at 7:32 PM, Scott Miles sjmi...@google.com wrote:
We don't think decoupling custom elements and shadow DOM completely is
useful given that most important and natural use cases of custom elements
involve the use of shadow DOM.
Separating concerns is always useful,
On Nov 11, 2013, at 4:12 PM, Dimitri Glazkov dglaz...@chromium.org wrote:
3) The approach pollutes global name space with constructors. This had been
voiced many times as unacceptable by developers.
4) How does build a custom element that uses name-card as its base element?
What about div
Hickson i...@hixie.ch wrote:
On Thu, 5 Dec 2013, Ryosuke Niwa wrote:
On Dec 5, 2013, at 8:49 AM, Ian Hickson i...@hixie.ch wrote:
On the other hand, this still doesn't tell UA whether it should be
ignoring the binding on a given platform or not (i.e. it doesn't address
the device-specific UI
Thanks.
On Dec 5, 2013, at 8:30 PM, Dimitri Glazkov dglaz...@chromium.org wrote:
On Thu, Dec 5, 2013 at 7:55 PM, Ryosuke Niwa rn...@apple.com wrote:
On Nov 11, 2013, at 4:12 PM, Dimitri Glazkov dglaz...@chromium.org wrote:
3) The approach pollutes global name space with constructors. This had
On Dec 5, 2013, at 8:43 PM, Dimitri Glazkov dglaz...@chromium.org wrote:
There were several threads around this in March/April, but the main gist is
that we can't allow running user code when the parser is building the tree,
and thus we would need to decouple the timing of the constructor
On Dec 5, 2013, at 9:23 PM, Dimitri Glazkov dglaz...@chromium.org wrote:
On Thu, Dec 5, 2013 at 9:03 PM, Ryosuke Niwa rn...@apple.com wrote:
On Dec 5, 2013, at 8:43 PM, Dimitri Glazkov dglaz...@chromium.org wrote:
There were several threads around this in March/April, but the main gist
On Dec 5, 2013, at 10:09 PM, Hajime Morrita morr...@google.com wrote:
On inheritance around HTMLElement family, there seems to be a confusion
between interface side inheritance and implementation side inheritance.
Right. Differentiating the two is very important.
For Custom Elements, the
On Dec 5, 2013, at 10:44 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 12/6/13 12:03 AM, Ryosuke Niwa wrote:
That sounds like an implementation detail of Blink/WebKit.
It seems like a pretty fundamental restriction for all current HTML parsers.
In particular, the HTML parsing algorithm has
On Dec 5, 2013, at 10:58 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 12/6/13 1:49 AM, Ryosuke Niwa wrote:
Then how do we define a custom element using ES6 classes? Are we going to
not call the constructor?
An excellent question, indeed. I don't have a good answer for you.
It appears
We share the same concern Jonas raised here.
In addition, we had been postponing reviewing the Web Components specifications
due to the heavy refactoring of the Shadow DOM specification announced in
July:
http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0161.html
Now we know that
On Nov 26, 2013, at 10:15 PM, Dominic Cooney domin...@google.com wrote:
On Wed, Nov 27, 2013 at 2:19 PM, Ryosuke Niwa rn...@apple.com wrote:
On Nov 27, 2013, at 8:57 AM, Dominic Cooney domin...@google.com wrote:
On Tue, Nov 26, 2013 at 2:03 PM, Ryosuke Niwa rn...@apple.com wrote:
Hi
On Oct 7, 2013, at 12:24 PM, Rafael Weinstein rafa...@google.com wrote:
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
On Dec 3, 2013, at 8:02 PM, Eric Bidelman ericbidel...@google.com wrote:
On Tue, Dec 3, 2013 at 7:03 PM, Ryosuke Niwa rn...@apple.com wrote:
On Oct 9, 2013, at 10:42 AM, Scott Miles sjmi...@google.com wrote:
On Mon, Oct 7, 2013 at 3:24 AM, James Graham ja...@hoppipolla.co.uk wrote:
On 06/10
On Nov 27, 2013, at 8:57 AM, Dominic Cooney domin...@google.com wrote:
On Tue, Nov 26, 2013 at 2:03 PM, Ryosuke Niwa rn...@apple.com wrote:
Hi,
I have been having informal discussions of our earlier proposal for
cross-orign use cases and declarative syntax for web components, and I
Hi,
I have been having informal discussions of our earlier proposal for cross-orign
use cases and declarative syntax for web components, and I realized there was a
lot of confusion about our motivations and decision decisions. So I wanted to
explain why/how we came up that proposal in this
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 also agree (I think) that we need a way to connect
ES6 modules and the
We share the concern Jonas expressed here as I've repeatedly mentioned on
another threads.
On Nov 18, 2013, at 4:14 PM, Jonas Sicking jo...@sicking.cc wrote:
This has several downsides:
* Libraries can easily collide with each other by trying to insert
themselves into the global using the
On Nov 19, 2013, at 2:10 PM, Dimitri Glazkov dglaz...@chromium.org wrote:
On Mon, Nov 18, 2013 at 8:26 PM, Ryosuke Niwa rn...@apple.com wrote:
We share the concern Jonas expressed here as I've repeatedly mentioned on
another threads.
On Nov 18, 2013, at 4:14 PM, Jonas Sicking jo
On Nov 12, 2013, at 8:12 AM, Dimitri Glazkov dglaz...@chromium.org wrote:
On Sun, Nov 10, 2013 at 6:49 PM, Arthur Barstow art.bars...@nokia.com wrote:
On 11/9/13 3:24 AM, ext Ryosuke Niwa wrote:
Hi all,
We have been discussing cross-orign use case and declarative syntax of web
components
, Nov 12, 2013 at 9:01 PM, Elliott Sprehn espr...@gmail.com wrote:
On Tue, Nov 12, 2013 at 12:45 AM, Ryosuke Niwa rn...@apple.com wrote:
[...]
Script in the import is executed in the context of the window that
contains the importingdocument. So window.document refers to the main page
On Nov 11, 2013, at 3:56 PM, Adam Barth w...@adambarth.com wrote:
Can you help me understand what security properties your proposal
achieves and how it achieves them? I spent some time thinking about
this problem a couple of years ago when this issue was discussed in
depth, but I couldn't
On Nov 11, 2013, at 5:33 PM, Ryosuke Niwa rn...@apple.com wrote:
On Nov 11, 2013, at 5:13 PM, Adam Barth w...@adambarth.com wrote:
On Mon, Nov 11, 2013 at 12:57 AM, Ryosuke Niwa rn...@apple.com wrote:
On Nov 11, 2013, at 3:56 PM, Adam Barth w...@adambarth.com wrote:
Can you help me
On Nov 12, 2013, at 6:22 AM, Elliott Sprehn espr...@gmail.com wrote:
On Mon, Nov 11, 2013 at 1:33 AM, Ryosuke Niwa rn...@apple.com wrote:
[...] we’re open to creating a proxy/fake element subclass which is not
visible in the global scope and identical to HTMLKnownElement in its
prototype
components in the host document.
3. Support static (write-once) binding of a HTML template
e.g.
template id=cardTemplateName: {{name}}brEmail:{{email}}/template
script
document.body.appendChild(cardTemplate.instantiate({name: Ryosuke Niwa,
email:rn...@webkit.org}));
/script
4. Add “interface
On Oct 29, 2013, at 6:04 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 10/14/13 12:11 AM, Ryosuke Niwa wrote:
If I'm not mistaken, how alternative text is presented is up to UA vendors.
You're mistaken. The HTML spec actually defines the behavior here, in
standards mode: it's presented
...@sicking.cc wrote:
On Oct 17, 2013 6:48 PM, Hajime Morrita morr...@google.com wrote:
On Fri, Oct 18, 2013 at 3:56 AM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Oct 17, 2013 at 1:55 AM, Hajime Morrita morr...@google.com wrote:
On Thu, Oct 17, 2013 at 5:01 PM, Ryosuke Niwa rn
DOM and is more about
generic selection atomicity concept. It could be covered by a CSS property
for example.
Doesn't -moz-user-select/-ms-user-select: element do that already?
On Oct 16, 2013, at 9:25 PM, Jonas Sicking jo...@sicking.cc wrote:
On Oct 16, 2013 8:04 PM, Ryosuke Niwa rn
On Oct 16, 2013, at 5:14 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Oct 15, 2013 at 12:04 PM, Ryosuke Niwa rn...@apple.com wrote:
On Oct 13, 2013, at 9:19 PM, Jonas Sicking jo...@sicking.cc wrote:
On Sun, Oct 13, 2013 at 9:11 PM, Ryosuke Niwa rn...@apple.com wrote:
On Oct 11, 2013
On Oct 13, 2013, at 9:19 PM, Jonas Sicking jo...@sicking.cc wrote:
On Sun, Oct 13, 2013 at 9:11 PM, Ryosuke Niwa rn...@apple.com wrote:
On Oct 11, 2013, at 10:52 PM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Oct 11, 2013 at 10:23 PM, Ryosuke Niwa rn...@apple.com wrote:
On Oct 7, 2013
On Oct 11, 2013, at 10:52 PM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Oct 11, 2013 at 10:23 PM, Ryosuke Niwa rn...@apple.com wrote:
On Oct 7, 2013, at 1:38 PM, Jonas Sicking jo...@sicking.cc wrote:
On Oct 7, 2013 6:56 AM, Hajime Morrita morr...@google.com wrote:
Hi,
I'm sorry
On Oct 7, 2013, at 1:38 PM, Jonas Sicking jo...@sicking.cc wrote:
On Oct 7, 2013 6:56 AM, Hajime Morrita morr...@google.com wrote:
Hi,
I'm sorry that I didn't notice that you were talking about UA shadow DOM.
It's an implementation detail and the standard won't care about that.
On Sep 17, 2013, at 5:48 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Mon, Sep 16, 2013 at 8:49 PM, Boris Zbarsky bzbar...@mit.edu wrote:
What's a new rendering engine supposed to do? Implement one of the prefixed
versions? Break content? Implement the unprefixed version? I'd say that
On Sep 13, 2013, at 8:26 PM, Brian Kardell bkard...@gmail.com wrote:
On Sep 13, 2013 4:38 PM, Ryosuke Niwa rn...@apple.com wrote:
On Sep 11, 2013, at 11:54 AM, Francois Remy r...@adobe.com wrote:
For the record, I'm equally concerned about renaming `matchesSelector`
into `matches
On Sep 11, 2013, at 11:54 AM, Francois Remy r...@adobe.com wrote:
For the record, I'm equally concerned about renaming `matchesSelector` into
`matches`.
A lot of code now rely on a prefixed or unprefixed version of
`matchesSelector` as this has shipped in an interoperable fashion in all
On Jul 12, 2013, at 12:57 PM, James Greene james.m.gre...@gmail.com wrote:
It appears that the only way to trigger a `copy` event programmatically is to
use `document.execCommand('copy')`, which most browsers prevent:
On Apr 30, 2013, at 12:07 PM, Daniel Freedman dfre...@google.com wrote:
I'm concerned that if the spec shipped as you described, that it would not be
useful enough to developers to bother using it at all.
I'm concerned that we can never ship this feature due to the performance
penalties it
1, 2013, at 12:41 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, May 1, 2013 at 12:15 PM, Dimitri Glazkov dglaz...@chromium.org
wrote:
On Wed, May 1, 2013 at 11:49 AM, Ryosuke Niwa rn...@apple.com wrote:
On Apr 30, 2013, at 12:07 PM, Daniel Freedman dfre...@google.com wrote:
I'm
rather have us do the hard work
here.
For the record, we have two independent implementations of the Shadow
DOM spec so that should debunk some of the myths that this is too hard
to implement and maintain.
On Tue, Apr 30, 2013 at 10:37 AM, Ryosuke Niwa rn...@apple.com wrote:
On Apr 25
On Mar 29, 2013, at 4:21 PM, Paul Libbrecht p...@hoplahup.net wrote:
Nice catch for this example you provide below.
The solution to this issue would be to simply empty the script element
instead of stripping it away. Right?
Unfortunately, that approach won't be backward compatible. Also,
Hi,
The current clipboard API specification mentions security risks of copy paste
but doesn't seem to explicitly mention methods by which user agents deal with
such security risks.
In particular, WebKit has been stripping script element from the pasted content
but this may have some side
On Wed, Sep 19, 2012 at 11:00 AM, Boris Zbarsky bzbar...@mit.edu wrote:
I was looking at http://dvcs.w3.org/hg/**undomanager/raw-file/tip/**
undomanager.htmlhttp://dvcs.w3.org/hg/undomanager/raw-file/tip/undomanager.htmland
ran into some issues:
1) No mention of where feedback should be
On Thu, Aug 23, 2012 at 5:10 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Aug 23, 2012 at 4:32 PM, Glenn Maynard gl...@zewt.org wrote:
On Thu, Aug 23, 2012 at 12:19 PM, Ryosuke Niwa rn...@webkit.org wrote:
It is not worse either way. Equally bad both ways. But, we're
designing
On Fri, Aug 24, 2012 at 1:41 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Thu, Aug 23, 2012 at 5:10 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Aug 23, 2012 at 4:32 PM, Glenn Maynard gl...@zewt.org wrote:
On Thu, Aug 23, 2012 at 12:19 PM, Ryosuke Niwa rn...@webkit.org
wrote
...@chromium.org wrote:
On Wed, Aug 22, 2012 at 6:49 PM, Ryosuke Niwa rn...@webkit.org mailto:
rn...@webkit.org wrote:
On Wed, Aug 22, 2012 at 5:55 PM, Glenn Maynard gl...@zewt.orgmailto:
gl...@zewt.org wrote:
On Wed, Aug 22, 2012 at 7:36 PM, Maciej Stachowiak
m...@apple.com
:
On Wed, Aug 22, 2012 at 6:49 PM, Ryosuke Niwa rn...@webkit.orgmailto:
rn...@webkit.org wrote:
On Wed, Aug 22, 2012 at 5:55 PM, Glenn Maynard gl...@zewt.orgmailto:
gl...@zewt.org wrote:
On Wed, Aug 22, 2012 at 7:36 PM, Maciej Stachowiak
m...@apple.com mailto:m...@apple.com
Ryosuke Niwa
Software Engineer
Google Inc.
On Thu, Aug 23, 2012 at 6:55 AM, Olli Pettay olli.pet...@helsinki.fi
wrote:
On 08/22/2012 11:16 PM, Maciej Stachowiak wrote:
But, again, letting webpages force that behavior in Safari seems wrong to
me. I don't think we should allow violating
to paste as text or paste as rich text.
*Proposal*
Add a boolean flag to beforepaste and paste events indicating whether the
user had intended to paste as text or rich text. (pasteAsText IDL
attribute?)
Best regards,
Ryosuke Niwa
Software Engineer
Google Inc.
On Thu, Aug 23, 2012 at 10:19 AM, Ryosuke Niwa rn...@webkit.org wrote:
On Thu, Aug 23, 2012 at 6:55 AM, Olli Pettay olli.pet...@helsinki.fi
wrote:
On 08/22/2012 11:16 PM, Maciej Stachowiak wrote:
But, again, letting webpages force that behavior in Safari seems wrong
to me. I don't think
On Wed, Aug 22, 2012 at 5:55 PM, Glenn Maynard gl...@zewt.org wrote:
On Wed, Aug 22, 2012 at 7:36 PM, Maciej Stachowiak m...@apple.com wrote:
Ryosuke also raised the possibility of multiple text fields having
separate UndoManagers. On Mac, most apps wipe they undo queue when you
change text
On Aug 22, 2012 7:40 PM, Glenn Maynard gl...@zewt.org wrote:
On Wed, Aug 22, 2012 at 8:49 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Wed, Aug 22, 2012 at 5:55 PM, Glenn Maynard gl...@zewt.org wrote:
On Wed, Aug 22, 2012 at 7:36 PM, Maciej Stachowiak m...@apple.com
wrote:
Ryosuke also
transactions attached to the undo manager?
That seems like an important use case.
/ Jonas
On Mon, Aug 20, 2012 at 9:52 PM, Ryosuke Niwa rn...@webkit.org wrote:
Greetings all,
We've been implementing undo manager in WebKit, and we've found out that
allowing live undo manager on a detached undo
On Tue, Aug 21, 2012 at 1:54 AM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Aug 20, 2012 at 11:56 PM, Ryosuke Niwa rn...@webkit.org wrote:
No. Allowing the host to be moved without removing automatic transaction
is
what causes the problem because automatic transactions need to keep
if other browser vendors are so inclined,
but I'm somewhat skeptical that we can get the required two independent
implementations given how much trouble we've had.
- Ryosuke
On Mon, Aug 20, 2012 at 9:52 PM, Ryosuke Niwa rn...@webkit.org wrote:
Greetings all,
We've been implementing undo manager
transactions in the undo manager
into no-ops but I'd prefer disconnecting the undo manager altogether to
make the behavior simple.
Best,
Ryosuke Niwa
Software Engineer
Google Inc.
On Wed, Jul 11, 2012 at 10:36 AM, Ojan Vafai o...@chromium.org wrote:
Another thing to consider if we add DOMTransaction back in is that you now
need to specifiy what happens in more cases, e.g.:
-call transact on the same DOMTransaction twice
-call transact on a DOMTransaction then modify
On Wed, Jul 11, 2012 at 3:12 PM, Ojan Vafai o...@chromium.org wrote:
On Wed, Jul 11, 2012 at 11:19 AM, Ryosuke Niwa rn...@webkit.org wrote:
On Wed, Jul 11, 2012 at 10:36 AM, Ojan Vafai o...@chromium.org wrote:
Another thing to consider if we add DOMTransaction back in is that you
now need
On Wed, Jul 11, 2012 at 3:35 PM, Ojan Vafai o...@chromium.org wrote:
On Wed, Jul 11, 2012 at 3:23 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Wed, Jul 11, 2012 at 3:12 PM, Ojan Vafai o...@chromium.org wrote:
We don't have this problem with the dictionary interface because we
don't store
On Mon, Jul 9, 2012 at 7:30 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Fri, Jul 6, 2012 at 12:09 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Fri, Jul 6, 2012 at 1:46 AM, James Graham jgra...@opera.com wrote:
On 07/06/2012 02:01 AM, Ryosuke Niwa wrote:
On Thu, Jul 5, 2012 at 4:27 PM
On Mon, Jul 9, 2012 at 9:52 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Mon, Jul 9, 2012 at 9:41 AM, Ryosuke Niwa rn...@webkit.org wrote:
On Mon, Jul 9, 2012 at 7:30 AM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
On Fri, Jul 6, 2012 at 12:09 PM, Ryosuke Niwa rn...@webkit.org wrote
On Fri, Jul 6, 2012 at 1:46 AM, James Graham jgra...@opera.com wrote:
On 07/06/2012 02:01 AM, Ryosuke Niwa wrote:
On Thu, Jul 5, 2012 at 4:27 PM, Ojan Vafai o...@chromium.org wrote:
In your version, you need to remember the order of the arguments, which
requires you looking it up each
On Jul 6, 2012 3:06 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 7/5/12 3:05 PM, Ryosuke Niwa wrote:
Also, I think consistency matters a lot here. I'm not aware of any other
Web-facing API that takes a pure object with callback functions.
http://www.w3.org/TR/DOM-Level-2-Traversal-Range
On Thu, Jul 5, 2012 at 4:40 PM, Yuval Sadan sadan.yu...@gmail.com wrote:
t = undoManager.transact(foobar, function() { ... });
t.onredo = function() { /* custom redo */ };
t.execute();
Whether onundo/onredo are assigned upon execute() is well defined, so
basing behavior on that is
On Thu, Jul 5, 2012 at 8:08 AM, James Graham jgra...@opera.com wrote:
On 07/05/2012 12:38 AM, Ryosuke Niwa wrote:
After this change, authors can write:
scope.undoManager.transact(new AutomaticDOMTransaction{**function () {
scope.appendChild(foo);
}, 'append foo'));
instead
On Thu, Jul 5, 2012 at 12:45 PM, James Graham jgra...@opera.com wrote:
On Thu, 5 Jul 2012, Ryosuke Niwa wrote:
On Thu, Jul 5, 2012 at 8:08 AM, James Graham jgra...@opera.com **wrote:
On 07/05/2012 12:38 AM, Ryosuke Niwa wrote:
After this change, authors can write
Thanks for the feedback. We need more developer feedbacks on this spec.
On Jul 5, 2012 1:50 PM, Yuval Sadan sadan.yu...@gmail.com wrote:
Passing in objects containing one or more non-callback properties is
also an increaingly common pattern, and we are trying to replace legacy
APIs that took
301 - 400 of 522 matches
Mail list logo
