decide what to do by themselves. For example, I'd
imagine browsers can implement some interactive UI that lets user decide
whether or not he/she wants to paste / copy certain content on demand.
Allowing access only within the event handler might be too restrictive.
Best regards,
Ryosuke Niwa
On Mon, Jan 31, 2011 at 1:31 AM, Hallvord R. M. Steen hallv...@opera.comwrote:
On Mon, 31 Jan 2011 18:02:34 +0900, Ryosuke Niwa rn...@webkit.org wrote:
OK. Any particular reason? Are you looking at it from the implementor's or
the script author's perspective?
From script author's perspective
On Mon, Jan 31, 2011 at 3:25 AM, Paul Libbrecht p...@activemath.org wrote:
Le 31 janv. 2011 à 11:39, Daniel Cheng a écrit :
The way I'm working on implementing it (for drag and drop, though it
applies to copy and paste as well), arbitrary strings would not be
accessible from a non-DOM
On Mon, Jan 31, 2011 at 11:28 AM, Daniel Cheng dch...@chromium.org wrote:
On Mon, Jan 31, 2011 at 09:00, Ryosuke Niwa rn...@webkit.org wrote:
Making it live seems more efficient. If we allowed arbitrary MIME types
and spec'ed to always return the same data, then we must copy contents
On Tue, Mar 1, 2011 at 5:18 PM, Makoto Kato m_k...@ga2.so-net.ne.jp wrote:
On Safari 5, even if textbox has IME composition string, text into textbox
can be replaced by DOM/script. But other browser's behaviors are different,
and this is no specification when textbox has composition string.
On Thu, Mar 3, 2011 at 7:47 PM, Makoto Kato m_k...@ga2.so-net.ne.jp wrote:
Hi, Niwa-san.
On 2011/03/02 15:30, Ryosuke Niwa wrote:
You must have tested Chrome improperly. We currently have a bug in
Chrome. To see the bug, open the attached test and type nihao with
Chinese IME on Windows
On Tue, May 3, 2011 at 10:26 AM, Paul Libbrecht p...@hoplahup.net wrote:
As noted in the thread about security started by Halvord:
In many of the scenarios I have working for, the content to be put on the
clipboard would come from a luxury knowledge structure on the server, one
that has
I think I have raised my concern before but what should happen if script
calls getData() within a copy/cut event handler? Should it return the
clipboard content after taking account the values set by setData? Or should
it always return the same value? Or should script be banned from calling
On Wed, May 4, 2011 at 2:46 PM, Daniel Cheng dch...@chromium.org wrote:
From my understanding, we are trying to protect against [1] hidden data
being copied without a user's knowledge and [2] XSS via pasting hostile
HTML. In my opinion, the algorithm as written is either going to remove too
On Mon, May 16, 2011 at 9:34 PM, Hallvord R. M. Steen hallv...@opera.comwrote:
On Mon, 31 Jan 2011 20:25:20 +0900, Paul Libbrecht p...@activemath.org
wrote:
A website maker for, say, a shop for furnitures that knows they can go
into my home plan maker through the clipboard will want to be
On Tue, May 17, 2011 at 12:11 AM, Paul Libbrecht p...@activemath.orgwrote:
Ryosuke,
why would sensitive information be readable or writable?
Because it has been available through clipboard. e.g. a popular
productivity application puts a local file path in link elements whenever
you copy
On Tue, May 17, 2011 at 12:26 AM, Paul Libbrecht p...@activemath.orgwrote:
I agree it's a risk but since it's only when the user pastes intentionally,
I don't think it is a risk to be excluded.
I don't think it's okay. I didn't even save the file and file path was
invisible to a user. As a
On Tue, May 17, 2011 at 1:16 AM, Olli Pettay olli.pet...@helsinki.fiwrote:
I think Webkit's and Gecko's behavior makes more sense.
You paste to some location in the editable area, not to root of it.
But selection could be a range. Why would you arbitrarily pick one end
point?
- Ryosuke
Ryosuke Niwa
Software Engineer
Google Inc.
On Tue, May 17, 2011 at 10:48 AM, Paul Libbrecht p...@hoplahup.net wrote:
This was certainly at least copied in plain-text as well, or?
The risk is here today then already, correct? (even with traditional forms
and a quick onchange that makes
On Wed, May 18, 2011 at 5:43 PM, João Eiras joao.ei...@gmail.com wrote:
But there is no way to access the clipboard contents. Or does execCommand
dispatch a synchronous event ?
It fires copy/paste events.
- Ryosuke
On Wed, May 18, 2011 at 5:41 PM, João Eiras joao.ei...@gmail.com wrote:
More generic
- text/* (I've see in too many places mime-types like text/x-c-src, and
text is text.)
- application/*+xml
- application/*script (ecmascript, javascript)
How do we know that these types don't contain
On Mon, Jun 20, 2011 at 10:48 AM, Tab Atkins Jr. jackalm...@gmail.comwrote:
2. During a user-initiated click, you can lock the mouse to the target
or an ancestor without a permissions prompt, but with a persistent
message, either as an overlay or in the browser's chrome.
Does this mean that
On Wed, Jun 29, 2011 at 6:11 PM, Jonas Sicking jo...@sicking.cc wrote:
Jokes aside. I think the way to do this is that the spec should
introduce the concept of a compound mutating function. Functions
like insertBefore, removeChild and the innerHTML setter should claim
to be such functions.
On Tue, Jun 28, 2011 at 2:24 PM, Jonas Sicking jo...@sicking.cc wrote:
1. DOMNodeRemoved is fired *before* a mutation takes place. This one's
tricky since you have to figure out all the removals you're going to
do, then fire events for them, and then hope that the mutations
actually still
On Thu, Jun 30, 2011 at 1:15 PM, David Flanagan dflana...@mozilla.comwrote:
avoid the need to maintain a list of pending callbacks.
Yeah, this is one reason I like Rafael's proposal of having a list of
mutations. In many editing apps, you want to get a list of mutation events
for each editing
On Thu, Jun 30, 2011 at 1:35 PM, Boris Zbarsky bzbar...@mit.edu wrote:
The point of my proposal was to guarantee that mutation events are
delivered when the tree is in its freshly-mutated state and avoid the
need to maintain a list of pending callbacks.
That would be nice; the problem is
On Thu, Jun 30, 2011 at 3:55 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 6/30/11 6:33 PM, Ryosuke Niwa wrote:
I think most developers are concerned with paint to avoid flickering and
not so much about layout.
I meant from the implementation's point of view. E.g. if a node is
partially
On Wed, Jun 29, 2011 at 6:11 PM, Jonas Sicking jo...@sicking.cc wrote:
Maybe this is a stupid question, since I'm not familiar at all with
the use-cases involved, but why can't we delay firing the
notifications until the event loop spins? If we're already delaying
them such that there
On Thu, Jun 30, 2011 at 5:16 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 6/30/11 7:01 PM, Ryosuke Niwa wrote:
What do you mean by it being partially inserted? Like document
relationship, etc... aren't consistent?
That would be one example, yes. Firing mutation events as you go involves
On Fri, Jul 1, 2011 at 12:05 PM, David Flanagan dflana...@mozilla.com
wrote:
The sketch that Rafael has provided does look like it would address my
needs. Not because all the mutations are batched into a single list (though
that seems like the most important feature of his proposal) but
On Fri, Jul 1, 2011 at 12:53 PM, David Flanagan dflana...@mozilla.comwrote:
On 7/1/11 12:29 PM, Ryosuke Niwa wrote:
I think this will be really hard to implement. For example, consider the
following code:
var parent = node.parentNode;
parent.removeChild(node);
setTimeout(function
On Fri, Jul 1, 2011 at 3:47 PM, Rafael Weinstein rafa...@google.com wrote:
If you want to discover mutations to nodes while outside the tree,
then having a single subtree observer isn't sufficient. You'll need an
attribute observer registered on all elements reachable from the root.
I believe
On Fri, Jul 1, 2011 at 5:36 PM, Rafael Weinstein rafa...@google.com wrote:
We've been prototyping more useful higher-level semantics on top of
what we've proposed (akin to what you're asking about). In general, if
you want to know something correct about what happened to a tree from
state (a)
On Sat, Jul 2, 2011 at 7:07 AM, Boris Zbarsky bzbar...@mit.edu wrote:
The numbers above are made up, of course; it would be useful to have some
hard data on the actual use cases.
Maybe we need both sorts of APIs: one which generates a fine-grained change
list and incurs a noticeable DOM
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 breakpoints like add/remove attribute.
If my goal
On Sun, Jul 3, 2011 at 10:04 AM, John J. Barton 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 removals, we have to
pre-compute all nodes that are to be removed and
On Sun, Jul 3, 2011 at 8:41 AM, John J. Barton
johnjbar...@johnjbarton.comwrote:
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
On Mon, Jul 4, 2011 at 11:01 AM, Dave Raggett d...@w3.org wrote:
How exactly would the listener know the previous state?
For a concurrent editing app, it is important to be able to describe
changes reversibly so that you can revert the DOM when a given local edit
isn't accepted, or you need
On Mon, Jul 4, 2011 at 8:40 PM, John J. Barton
johnjbar...@johnjbarton.comwrote:
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
On Mon, Jul 4, 2011 at 2:22 PM, Olli Pettay olli.pet...@helsinki.fi wrote:
On 07/05/2011 12:02 AM, Adam Klein wrote:
In Rafael's API, each mutation is represented by an object, so I'd
simply put it there with its own key, something like:
interface MutationRecord {
// e.g.,
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 to require a new mechanism for async handling? Could
listeners be
On Tue, Jul 5, 2011 at 5:27 PM, Rafael Weinstein rafa...@google.com wrote:
It seems like these are rarified enough cases that visual artifacts
are acceptable collateral damage if you do this. [Put another way, if
you care enough about the visual polish of your app that you will put
energy
On Wed, Jul 6, 2011 at 1:27 AM, Dave Raggett d...@w3.org wrote:
On 04/07/11 21:43, Olli Pettay wrote:
In the easiest case when the script cares about only one specific
attribute:
element.**addAttributeChangeListener(
{
prevVal: element.getAttribute(foo),
handleMutation:
On Wed, Jul 6, 2011 at 7:43 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 7/6/11 10:23 AM, John J. Barton wrote:
This is another advantage of onModelChanging or 'before' events. All of
the previous values are available for listeners and the task of
selecting which ones to process is left to
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 existing DOM
mutation events don't work. We shouldn't adding yet-another
On Thu, Jul 7, 2011 at 1:58 PM, Ryosuke Niwa rn...@webkit.org wrote:
Right. But on the other hand, if this code were to run inside a mutation
observer, it won't work in your proposal either. So the questions is
whether writing a function that depends on state updated by the mutation
On Thu, Jul 7, 2011 at 3:43 PM, John J Barton
johnjbar...@johnjbarton.comwrote:
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 Fri, Jul 8, 2011 at 5:21 AM, Sean Hogan shogu...@westnet.com.au wrote:
- MathJax (http://mathjax.org) is a JS lib that facilitates putting math
onto the web by converting LaTeX or MathML markup in a page to HTML. By
default MathJax triggers off the onload event to run this conversion on the
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 Sicking jo...@sicking.cc wrote:
[ { target: node1, type: childlist, added: [a, b, c, d], removed: [x, y]
},
{ target: node1, type: attributes,
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:
For editing purposes, it's also crucial to know from/to where nodes are
removed/inserted. It seems like adding an offset trivially solves
On Wed, Jul 20, 2011 at 8:43 AM, Dave Raggett d...@w3.org wrote:
Perhaps we need to distinguish auto generated attributes from those that
are set by markup or scripts. Could you please clarify for me the difference
between the html style attribute and the one you are referring to? My
On Wed, Jul 20, 2011 at 9:32 AM, Dave Raggett d...@w3.org wrote:
Isn't there a cheap way to distinguish changes to the DOM (setAttribute)
from indirect changes to how CSSMutableStyleDeclaration is formatted to
text? It sounds as if you already have a setter function that knows how to
update
On Wed, Jul 20, 2011 at 12:53 PM, David Flanagan dflana...@mozilla.comwrote:
On 7/20/11 12:11 PM, Ryosuke Niwa wrote:
But internally, a node movement is a removal then an insertion. There's
always possibility that a node gets removed then inserted again after
mutation observers
On Tue, Jul 19, 2011 at 8:23 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 7/19/11 7:18 PM,
Ryosuke Niwa
Software Engineer
Google Inc.
wrote:
For editing purposes, it's also crucial to know from/to where nodes are
removed/inserted. It seems like adding an offset trivially solves
On Fri, Jul 22, 2011 at 3:58 PM, Jonas Sicking jo...@sicking.cc wrote:
We should have much richer events to aid with rich text editing. Using
mutation notifications for this is will not create a good experience
for the page author.
But this is a big use case of mutation events today. If we
On Mon, Aug 1, 2011 at 6:33 PM, Maciej Stachowiak m...@apple.com wrote:
In an IRC discussion with Ian Hickson and Tab Atkins, we can up with the
following idea for convenient element creation:
Element.create(tagName, attributeMap, children…)
Can we alternatively extend
On Wed, Aug 10, 2011 at 12:49 PM, Olli Pettay olli.pet...@helsinki.fiwrote:
FYI, I'm planning to implement the proposal (using vendor prefixed API)
so that I can create tryserver builds.
I'll post the links to builds here later, hopefully in a few days, when
I find the time to do the actual
On Wed, Aug 10, 2011 at 8:32 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 8/10/11 9:06 PM,
Ryosuke Niwa
Software Engineer
Google Inc.
wrote:
On Wed, Aug 10, 2011 at 12:49 PM, Olli Pettay olli.pet...@helsinki.fi
mailto:Olli.Pettay@helsinki.**fi olli.pet...@helsinki.fi wrote:
FYI
On Mon, Aug 15, 2011 at 5:23 AM, Anne van Kesteren ann...@opera.com wrote:
Since there seems to be consensus to not do either Immediately or New
task should I remove those from http://wiki.whatwg.org/wiki/**
Modifications http://wiki.whatwg.org/wiki/Modifications now? It is fine
with me if
On Wed, Aug 17, 2011 at 3:17 AM, Olli Pettay olli.pet...@helsinki.fiwrote:
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 will
tags instead of b tags for bold text
generated by the bold command. With aftereditaction, the web application
can just fix up the DOM after the browser has modified it to
use strong tags.
Can we add these events?
Best regards,
Ryosuke Niwa
Software Engineer
Google Inc.
On Tue, Aug 30, 2011 at 4:08 PM, Darin Adler da...@apple.com wrote:
How would this work with undo?
That's a debatable point. Presumably, we'll be adding undo/redo events as
well so we could not fire before/after edit action events for
execCommand('undo') and execCommand('redo'). I know it's
On Tue, Aug 30, 2011 at 4:34 PM, Darin Adler da...@apple.com wrote:
My question was not about the undo command. I meant that if I implemented a
handler for the aftereditaction event that changed b tags to strong tags,
how would the undo machinery undo what I had done?
Ah, I see. So UA won't
Maybe execCommand('copy') isn't enabled outside editable region in some UAs?
- Ryosuke
On Tue, Sep 6, 2011 at 2:18 PM, Daniel Cheng dch...@chromium.org wrote:
Why do you need to create an element? Just call execCommand('copy') and
setData('text/html', 'blah') in your copy handler.
Daniel
I think it's a great idea to get your spec more attention in W3C community
specially because some UA vendors don't participate in discussions on
whatwg.
- Ryosuke
On Tue, Sep 13, 2011 at 1:27 PM, Aryeh Gregor a...@aryeh.name wrote:
For the last several months, I was working on a new
On Wed, Oct 12, 2011 at 8:14 PM, Sean Hogan shogu...@westnet.com.au wrote:
Maybe you can provide concrete examples (i.e. with code snippets,
actual instances of use cases, etc...)
Actually, it is the proponents of changing the status-quo and of the more
complex solution who bear more
On Wed, Oct 12, 2011 at 7:51 PM, Sean Hogan shogu...@westnet.com.au wrote:
It is different to event listeners. The following
document.body.**addEventListener(**DOMAttrModified, handler, false);
document.getElementById(**target).addEventListener(**DOMAttrModified,
preferred_handler,
supports -webkit-user-select: none to do this but some authors apparently
want to allow collapsed selection.
I personally don't quite understand why authors ever want to do this but I'm
not totally against the idea of providing new mechanism for this if there
are good use cases.
Best,
Ryosuke Niwa
On Thu, Oct 13, 2011 at 7:20 PM, Ojan Vafai o...@chromium.org wrote:
Overall I really like the proposal (both having the events and Jonas's
addition to include them in the undo transaction). We'd fire the
afterEditAction exactly everywhere we currently fire the input event though.
Instead of
On Thu, Oct 20, 2011 at 6:35 PM, Ojan Vafai o...@chromium.org wrote:
On Thu, Oct 20, 2011 at 1:06 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Thu, Oct 13, 2011 at 7:20 PM, Ojan Vafai o...@chromium.org wrote:
Overall I really like the proposal (both having the events and Jonas's
addition
On Thu, Oct 20, 2011 at 6:57 PM, Ryosuke Niwa rn...@webkit.org wrote:
I don't think we can make such an assumption. People mutate DOM on input
event all the time:
http://codesearch.google.com/#search/q=%20oninput=type=cs
Including any DOM mutations in the on-going transaction would mean
was on vacation for about ten days)
On Sat, Oct 15, 2011 at 1:51 PM, Ryosuke Niwa rn...@webkit.org wrote:
Is there an interest in providing a way to prevent non-collapsed
selection
under some node in a document? And if there is, what are use cases?
Authors periodically file a WebKit bug against our
On Nov 3, 2011 2:34 AM, Hallvord R. M. Steen hallv...@opera.com wrote:
On Thu, 03 Nov 2011 00:13:04 +0100, Daniel Cheng dch...@google.com
wrote:
What's the expected behavior if a script calls event.preventDefault()
when processing a copy/cut event but does not modify the data store?
Should
This sounds like an excellent idea. Chromium / WebKit had an issue with
this in regards to copy paste because some applications where inserting
table-element-less tables into clipboard, and HTML5 parsing algorithm was
stripping them out.
- Ryosuke
On Thu, Nov 3, 2011 at 4:03 PM, Yehuda Katz
an arbitrary command defined on a page, or ask what the value of
command is by queryCommandValue.
What are your thoughts on this topic?
Best,
Ryosuke Niwa
Software Engineer
Google Inc.
the current proposal to be ready for implementation feedback, and as such,
I plan to prototype it in WebKit and give my own feedback as well.
I sincerely request for your feedback on the proposal, and I will answer
any question(s) you may have about the proposal.
Best regards,
Ryosuke Niwa
This is great! Thanks for doing this. Can we also get stats. on new Node
methods like append, remove, etc...?
- Ryosuke
On Tue, Dec 13, 2011 at 11:36 PM, Boris Zbarsky bzbar...@mit.edu wrote:
John Jensen here at Mozilla has been doing some web crawling trying to
find what barewords are used
http://lists.w3.org/Archives/Public/www-dom/2011OctDec/0183.html is the
latest version as far as I know.
- Ryosuke
On Wed, Dec 14, 2011 at 12:57 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 12/14/11 3:54 AM, Ryosuke Niwa wrote:
This is great! Thanks for doing this. Can we also get stats
On Sun, Jan 8, 2012 at 11:57 PM, Simon Pieters sim...@opera.com wrote:
On Sat, 07 Jan 2012 03:57:33 +0100, Ojan Vafai o...@chromium.org wrote:
Different apps
have different needs and it's crappy for them to have to handle enter
themselves just to get a different block type on enter.
On Tue, Jan 10, 2012 at 12:46 PM, Aryeh Gregor a...@aryeh.name wrote:
On Tue, Jan 10, 2012 at 3:40 PM, Ryosuke Niwa rn...@webkit.org wrote:
Single br tag is shorter than pairs of div tags when serialized.
True, but only slightly, and the difference is even smaller if you use
p instead
On Wed, Jan 11, 2012 at 1:00 AM, Simon Pieters sim...@opera.com wrote:
On Tue, 10 Jan 2012 21:50:34 +0100, Ryosuke Niwa rn...@webkit.org wrote:
On Tue, Jan 10, 2012 at 12:46 PM, Aryeh Gregor a...@aryeh.name wrote:
On Tue, Jan 10, 2012 at 3:40 PM, Ryosuke Niwa rn...@webkit.org wrote
On Wed, Jan 11, 2012 at 1:43 AM, Markus Ernst derer...@gmx.ch wrote:
Am 11.01.2012 10:00 schrieb Simon Pieters:
On Tue, 10 Jan 2012 21:50:34 +0100, Ryosuke Niwa rn...@webkit.org
wrote:
On Tue, Jan 10, 2012 at 12:46 PM, Aryeh Gregor a...@aryeh.name wrote:
On Tue, Jan 10, 2012 at 3:40 PM
On Wed, Jan 11, 2012 at 8:41 AM, Aryeh Gregor a...@aryeh.name wrote:
Anne asked me to investigate how exactly Ranges are added to
Selections (bug:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15470). It turns out
browsers mostly don't interoperate. One interesting thing I found out
is
On Wed, Jan 11, 2012 at 12:09 PM, Aryeh Gregor a...@aryeh.name wrote:
On Wed, Jan 11, 2012 at 12:38 PM, Ryosuke Niwa rn...@webkit.org wrote:
That sounds like a great idea.
. . .
I'm not sure if we should add just editoptions though given we might
need
to add more elaborative options
On Wed, Jan 11, 2012 at 7:39 AM, Aryeh Gregor a...@aryeh.name wrote:
Okay, so what API should we use? I'd really prefer this be
per-editing host. In which case, how about we make it a content
attribute on the editing host?
That sounds like a great idea.
It can be a DOMSettableTokenList.
On Thu, Jan 12, 2012 at 1:58 AM, Hallvord R. M. Steen hallv...@opera.comwrote:
On Wed, 11 Jan 2012 18:31:26 +0100, Ryosuke Niwa rn...@webkit.org wrote:
Actually, applying p {margin:0} looks quite trivial.
The problem is that many existing contents don't have that css rule and
we obviously
Sorry for the extremely slow reply. It slipped through hundreds of emails :(
On Mon, May 16, 2011 at 8:41 PM, Hallvord R. M. Steen hallv...@opera.comwrote:
To me, it doesn't make sense to remove the other elements:
- OBJECT: Could be used for SVG as I understand.
OBJECT is considered a
On Thu, Feb 2, 2012 at 10:20 PM, Charles Pritchard ch...@jumis.com wrote:
Seems like a very minor risk for high security sites, e.g. banking, in
identifying form elements.
In the spirit of giving it some thought:
But even for those websites, what could input / textarea elements can
reveal
On Thu, Feb 2, 2012 at 10:43 PM, Charles Pritchard ch...@jumis.com wrote:
**
On 2/2/12 10:27 PM, Ryosuke Niwa wrote:
On Thu, Feb 2, 2012 at 10:20 PM, Charles Pritchard ch...@jumis.comwrote:
Seems like a very minor risk for high security sites, e.g. banking, in
identifying form elements
On Wed, Feb 8, 2012 at 5:20 PM, Brian Kardell bkard...@gmail.com wrote:
Are you essentially suggesting partials? Basically, one template can
contain another only by reference? Then you have something like a
corresponding tag or macro-ish thing whereby you can reference
(functionally
On Wed, Feb 8, 2012 at 7:31 PM, Brian Kardell bkard...@gmail.com wrote:
Then why not something like
template id=aworld/template
template id=bhello partial with=a/template
Right. If we were to disallow nested templates, that's the way to go. The
question is whether we should disallow nested
I like the idea of letting authors dynamically detectthe supported mime
types. But providing methods on the interface object seems rather unusual.
Also, I'm thinking there are cases where the supported mime types change
dynamically without reloading the page.
- Ryosuke
On Feb 17, 2012 5:25 AM,
I meant to say *if* there are cases.
On Feb 17, 2012 9:53 AM, Ryosuke Niwa rn...@webkit.org wrote:
should be allowed, I think.
Realistically, I don't think we'll ever let the wild Web get/set arbitrary
data like that. But maybe we can do that for privileged websites (ones that
the user trusts).
Le 17 févr. 2012 à 18:53,
Ryosuke Niwa
Software Engineer
Google Inc.
a écrit :
Also, I'm
with a hack that a kind html containing a script that reads the cookie when
executed?
In general, it's websites' responsibility to sanitize data they get from
getData.
On Fri, Feb 17, 2012 at 11:18 AM, Paul Libbrecht p...@hoplahup.net wrote:
Le 17 févr. 2012 à 19:25, Ryosuke Niwa a écrit :
Yes
Can we disallow mutation events inside shadow DOM?
There is no legacy content that depends on mutation events API inside
shadow DOM, and we have a nice spec implementation of new mutation
observer API already.
FYI, https://bugs.webkit.org/show_bug.cgi?id=79278
Best,
Ryosuke Niwa
Software
On Thu, Feb 23, 2012 at 4:10 PM, Brian Kardell bkard...@gmail.com wrote:
Just to be clear on this: what is the status of mutation observers? If
there any chance shadow dom beats mutation observers to standardization? I
don't think so, but just checking... If that turned out to be the case
uses the event target.
Best,
Ryosuke Niwa
Software Engineer
Google Inc.
Hi,
I've moved my draft to W3C repository at
http://dvcs.w3.org/hg/undomanager/raw-file/tip/undomanager.html
At this point, I'd like the editing community group to be in charge of this
proposal.
- Ryosuke
On Mon, Dec 5, 2011 at 11:44 PM, Ryosuke Niwa rn...@webkit.org wrote:
Greetings all
Why don't we just use script elements for that then?
On Mon, Apr 23, 2012 at 3:52 PM, Yuval Sadan sadan.yu...@gmail.com wrote:
You musn't forget what we're not planning for. Templates can be great for
so many applications - generating code (JSON, Javascript), generating
plain-text or
Have you looked at
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0663.html ?
On Mon, Apr 23, 2012 at 8:39 PM, Rafael Weinstein rafa...@google.comwrote:
The main points of contention in the discussion about the template element
are
1) By what mechanism are its content elements
.
On Apr 24, 2012 8:28 AM, Rafael Weinstein rafa...@google.com wrote:
No, I hadn't. Let me digest this thread. Much of what I'm implicitly
asking has already been discussed. I'll repost if I have anything to
add here. Apologies for the noise.
On Mon, Apr 23, 2012 at 10:32 PM, Ryosuke Niwa rn
I agree. Changing the context element based on the first element is strange
and counter-intutitive and doesn't buy us anything.
For example, enforcing the in table insertion mode when we encounter td
as the first element doesn't guarantee into where this fragment is
inserted. In fact, it can be
On Wed, Apr 25, 2012 at 3:05 PM, Yehuda Katz wyc...@gmail.com wrote:
jQuery seems to think it buys us something because we have implemented
exactly that.
Do you know why jQuery does it that way?
- Ryosuke
On Wed, Apr 25, 2012 at 3:31 PM, Ojan Vafai o...@chromium.org wrote:
script type=text/html works for string-based templating. Special
handling of /script is not a big enough pain to justify adding a template
element.
...
String-based templating already works. We don't need new API for it.
1 - 100 of 522 matches
Mail list logo
