On Mon, Apr 13, 2015 at 3:18 PM, Hallvord Reiar Michaelsen Steen
hst...@mozilla.com wrote:
So.. are you suggesting something like
window.Clipboard.setData('text/plain', 'foo') ?
Maybe. I don't know what a good name would be.
On Fri, Apr 10, 2015 at 2:44 PM, Hallvord Reiar Michaelsen Steen
hst...@mozilla.com wrote:
However, document.execCommand() is spec'ed as having a value argument.
What about actually using it here? Simplifying the above code to:
element.onclick = function(){
document.execCommand('copy',
On Thu, Feb 12, 2015 at 4:45 AM, Marc Fawzi marc.fa...@gmail.com wrote:
how long can this be sustained? forever? what is the point in time where the
business of retaining backward compatibility becomes a huge nightmare?
It already is, but there's no way out. This is true everywhere in
On Tue, Jan 27, 2015 at 4:49 PM, Koji Ishii kojii...@gmail.com wrote:
3 proposals so far:
Proposal A: Leave it undefined. If it's not causing interop issues, we
can leave it.
Proposal B: Clone.
Proposal C: Live.
I can live with any, but prefer B.
On Tue, Jan 27, 2015 at 4:31 PM, Koji Ishii kojii...@gmail.com wrote:
It's true that you could use multi-range selections to select in
visual order. But there are bunch of operations defined against
selections. What does it copy? What will happen when you type a to
replace the selected text?
On Sat, Jan 24, 2015 at 9:18 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Though I believe browsers will soon have much more pressure to support
multiple ranges as a matter of course, as increased design with
Flexbox and Grid will mean that highlighting from one point to
another, in the
On Sun, Jan 25, 2015 at 1:31 AM, Mats Palmgren m...@mozilla.com wrote:
Gecko knows if a Range is part of a Selection or not.
Authors don't, I don't think. Of course, we could expose this info to
authors if we wanted, so that's not a big problem.
True, I'm just saying that I don't see any
On Sat, Jan 24, 2015 at 3:28 PM, Koji Ishii kojii...@gmail.com wrote:
Looks like we're in consensus that a) it doesn't really cause issues
today, and b) there are scenarios where live-ness is nice.
I don't agree that it doesn't cause issues now. Unless we want Range
methods to behave
On Sat, Jan 17, 2015 at 10:12 PM, Olivier Forget teleclim...@gmail.com wrote:
I'd be interested in hearing more about what didn't work with that API by
both devs who tried to make use of it and the implementors too.
For the record: web developers don't usually take advantage of additional
On Wed, Jan 21, 2015 at 5:20 PM, Mats Palmgren m...@mozilla.com wrote:
It seems fine to me. WebKit/Blink already rejects(*) a range with
detached nodes in the addRange call. Imposing the same restriction on
a (live) Selection range is consistent with that.
I don't think it's consistent at
On Mon, Jan 12, 2015 at 9:59 PM, Ben Peters ben.pet...@microsoft.com wrote:
Multiple selection is an important feature in the future. Table columns are
important, but we also need to think about BIDI. Depending on who you talk
to, BIDI should support selection in document order or layout order.
/show_bug.cgi?id=13975
On Wed, Jan 14, 2015 at 6:14 PM, Mats Palmgren m...@mozilla.com wrote:
On 01/09/2015 12:40 PM, Aryeh Gregor wrote:
The advantage of the IE/Gecko behavior is you can alter the selection
using Range methods. The advantage of the WebKit/Blink behavior is
you can restrict
On Mon, Jan 12, 2015 at 3:40 AM, Karl Dubost k...@la-grange.net wrote:
I'm using multiple range selection very often. From every day to a couple of
times a week. My main usage is when I use bookmarking services and I want to
keep part of an article which are distant. Basically a text1 […]
On Fri, Jan 9, 2015 at 8:29 PM, Olivier Forget teleclim...@gmail.com wrote:
On Fri Jan 09 2015 at 4:43:49 AM Aryeh Gregor a...@aryeh.name wrote:
- It may never happen, but when multiple ranges are supported, are
they bound to index?
Everyone wants to kill this feature, so it's moot
On Wed, Jan 7, 2015 at 12:32 AM, Ryosuke Niwa rn...@apple.com wrote:
Trident (since IE10) and Gecko both return a live Range, which can be
modified to update selection. WebKit and Blink both return a clone Range so
that any changes to the Range doesn't update the selection.
It appears that
On Wed, May 21, 2014 at 2:01 AM, Glenn Maynard gl...@zewt.org wrote:
I think I'd suggest avoiding the mess of execCommand altogether, and add new
methods, eg. window.copy() and window.cut() (or maybe just one method, with
a cut option). execCommand is such a nonsensical way to expose an API
On Mon, Apr 21, 2014 at 9:19 PM, Ben Peters ben.pet...@microsoft.com wrote:
The Selection API Bugzilla component [1] is now available for bugs in the
Selection API spec [2]. I propose that we move selection-related bugs from
the HTML Editing APIs spec [3] to this new component. Are there any
On Thu, Mar 20, 2014 at 6:38 PM, Marta Pawlowska
m.pawlow...@samsung.com wrote:
Specification details that lead me to my conclusions:
https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#the-inserthorizontalrule-command
- step 2. If p is not an allowed child of the editing host of node,
On Mon, Mar 17, 2014 at 1:59 PM, Robin Berjon ro...@w3.org wrote:
My understanding from talking to various people is that at least part of the
problem comes from the type of code that is currently deployed in the wild.
An awful lot of it works around browser inconsistencies not through feature
On Fri, Mar 14, 2014 at 1:43 AM, Ryosuke Niwa rn...@apple.com wrote:
It appears that there is a lot of new features such as CSS regions and shadow
DOM that have significant implications on selection API, and we really need a
spec. for selection API these specifications can refer to.
On Sun, Dec 22, 2013 at 2:22 AM, Johannes Wilm johannesw...@gmail.com wrote:
Hey,
is there any news on this or on content editable in general? Would it
be a better idea to just forget about contenteditable and instead
implement everything using javascript, the way Codemirror has done it
(
On Mon, Aug 5, 2013 at 10:25 AM, Mihnea-Vlad Ovidenie mih...@adobe.com wrote:
I would like to know more about the corner cases mentioned above and the
problems encountered when trying to implement this feature. Are they
documented somewhere I can take a look?
The basic issue is that in ~100%
On Sat, Jun 1, 2013 at 1:27 AM, Ojan Vafai o...@chromium.org wrote:
The main use case I can think of for mixed editability is an image with a
caption. If anyone has other use-cases, that would be helpful in reasoning
about this. http://jsfiddle.net/UAJKe/
A video with JavaScript controls
On Fri, Feb 22, 2013 at 2:42 AM, Alex Mogilevsky alex...@microsoft.com wrote:
Thanks for background, it helps a lot. I don't see a need to comment it by
point so let me just reference it [1] and try to summarize.
1. There is no consensus on what the default should be. There are
Sorry for the delayed response -- I've been busy with other things and
didn't have time to check my e-mail. Thanks a lot for the feedback
and questions!
On Mon, Feb 4, 2013 at 9:59 PM, Alex Mogilevsky alex...@microsoft.com wrote:
There was a discussion here a while ago on desired default
On Tue, Feb 19, 2013 at 11:26 AM, Ms2ger ms2...@gmail.com wrote:
FWIW, Aryeh is currently studying full time and doesn't follow web standards
discussions regularly.
I do check them from time to time, though, and will check any personal
e-mail I receive for the time being. In particular, I'm
(I noticed people talking about this on IRC and commented, and zcorpan
pointed me to this thread.)
On Tue, Oct 16, 2012 at 7:08 PM, Boris Zbarsky bzbar...@mit.edu wrote:
The point is that a browser can act as if every single server response
included Vary: User-Agent. And perhaps should.
On Thu, Aug 9, 2012 at 3:53 PM, Robin Berjon ro...@berjon.com wrote:
Trying to evangelise that something is experimental is unlikely to succeed.
But when trying out a new API people do look at the console a lot (you tend
to have to :). It might be useful to emit a warning upon the first usage
On Sun, Jun 17, 2012 at 4:43 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 6/17/12 9:33 AM, Anne van Kesteren wrote:
Always throwing SyntaxError is probably better.
Also probably incompatible with a depth-first recursive descent parser
implementation. Are we sure we want to overconstrain
On Wed, May 2, 2012 at 4:57 PM, Boris Zbarsky bzbar...@mit.edu wrote:
I would think that disabling cut/copy/paste would apply to main menus too,
not just context menus. Most people I know who use menus for this (which is
precious few, btw, for the most part people I know seem to use keyboard
On Thu, May 3, 2012 at 12:44 AM, Ojan Vafai o...@chromium.org wrote:
As I've said before, I don't think command/value should be restricted to
contentEditable beforeInput/input events. I don't see any downside to making
command, value and text all available for all three cases. It simplifies
On Wed, May 2, 2012 at 3:56 AM, Ryosuke Niwa rn...@webkit.org wrote:
That might make sense given how confusing these before* are.
On the other hand, there are use cases to communicate enabledness of cut,
copy, paste with UA. Maybe we can address this use case by letting
websites override
On Wed, May 2, 2012 at 9:04 AM, Ryosuke Niwa rn...@webkit.org wrote:
That's a good point. What would be a viable alternative then?
The use-case is disable cut/copy/paste and also hide those options
from context menus, right?
I think these are two separate features. First, you want to prevent
On Wed, May 2, 2012 at 9:27 AM, Ryosuke Niwa rn...@webkit.org wrote:
Sounds like beforecut, beforecopy, and beforepaste suffice then... Maybe
these events are useful after all.
I think they're useful, but very badly named -- authors will think
they fire before every cut, copy, and paste. So
On Wed, Apr 4, 2012 at 10:07 PM, Ojan Vafai o...@chromium.org wrote:
The original proposal to drop textInput included that beforeInput/input
would have a data property of the plain text being inserted. Aryeh, how does
that sound to you? Maybe the property should be called 'text'? 'data' is
On Fri, Jan 13, 2012 at 5:12 PM, Ojan Vafai o...@chromium.org wrote:
We could define it in terms of defaultView (or browsing context) and put our
effort into getting interoperability on defaultView?
This is what I've done for now:
http://dvcs.w3.org/hg/editing/rev/4dc4d65cc87e
At least
On Fri, Jan 13, 2012 at 12:34 PM, Boris Zbarsky bzbar...@mit.edu wrote:
I would prefer a definition that doesn't involve defaultView, actually. I
don't expect browsers to converge defaultView behavior any time in the near
or medium future, so the testability would be illusory: tests would just
What does document.implementation.createHTMLDocument().getSelection() return?
* IE9 returns a Selection object unique to that document.
* Firefox 12.0a1 and Opera Next 12.00 alpha return the same thing as
document.getSelection().
* Chrome 17 dev returns null.
I prefer IE's behavior just for the
On Wed, Jan 11, 2012 at 3:09 PM, Charles Pritchard ch...@jumis.com wrote:
The reason is listed in WCAG2 section 2.1.2 and CR5.
http://www.w3.org/TR/WCAG/
The items suggest that a standard means of moving focus be maintained. Users
should be given simple instructions on how to move focus if
On Thu, Jan 12, 2012 at 4:58 AM, Hallvord R. M. Steen
hallv...@opera.com wrote:
Probably a stupid question, but one I've always wanted to ask: couldn't we
default to a different, smaller, possibly 0 margin for P when in editable
content?
As Markus says: it breaks WYSIWYG. The idea of
On Tue, Jan 10, 2012 at 3:50 PM, Ryosuke Niwa rn...@webkit.org wrote:
p has default margins. That alone is enough for us not to adopt p as
the default paragraph separator.
On Wed, Jan 11, 2012 at 5:15 AM, Simon Pieters sim...@opera.com wrote:
Sure, but some apps like to send their stuff in
On Tue, Jan 10, 2012 at 4:48 PM, Charles Pritchard ch...@jumis.com wrote:
Would users press Esc to get out of the tab lock?
Do they need to be able to get out of it? They can't in a regular
word processor, so why should they be able to in Google Docs? If some
users need to be able to override
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 that in Gecko, if no one calls
addRange/removeRange/removeAllRanges,
On Wed, Jan 11, 2012 at 12:27 PM, Ryosuke Niwa rn...@webkit.org wrote:
Does gecko returns a Range at (document, 0) for getRange(0) in such cases?
Okay, it looks like my testing before was off. Actually, all browsers
have no range in the selection initially. But I was testing in Live
DOM
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 in the future. It might make more sense to
add a new attribute per option as
On Wed, Jan 11, 2012 at 3:15 PM, Ryosuke Niwa rn...@webkit.org wrote:
That sounds workable. Presumably it's only available on the editing host (as
supposed to any element or any element with contenteditable content
attribute).
Right.
On Fri, Jan 6, 2012 at 10:12 PM, Ojan Vafai o...@chromium.org wrote:
There are strong use-cases for both. In an app like Google Docs you
certainly want tab to act like indent. In a mail app, it's more of a
toss-up. In something like the Google+ sharing widget, you certainly want it
to maintain
On Fri, Jan 6, 2012 at 9:57 PM, Ojan Vafai o...@chromium.org wrote:
I'm OK with this conclusion, but I still strongly prefer div to be the
default single-line container name.
Why? I don't like using div as a line separator at all, because
it's also used as a block-level wrapper, while p is
On Sun, Jan 8, 2012 at 2:28 PM, Doug Schepers schep...@w3.org wrote:
In the status section of the HTML Editing APIs spec [1], you have detailed
instructions for how people should provide feedback, but the links you
provide are to the pubic-webapps archive and to your personal email, rather
This is just a heads-up that as of the new year, I'm contracting for
Mozilla instead of Google. I'll continue to work on specifications
and tests as before, in particular including the HTML Editing
specification.
On Tue, Nov 22, 2011 at 12:19 AM, Yehuda Katz wyc...@gmail.com wrote:
I like .is, the name jQuery uses for this purpose. Any reason not to go with
it?
We might want it for something else. .matches clearly sounds like
it's selector-related, and I have more trouble thinking of another
meaning
On Tue, Nov 22, 2011 at 1:04 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Again, some decent data on what pages actually do in on* handlers would be
really good. I have no idea how to get it. :(
Can't browsers add instrumentation for this? You have users who have
opted in to sending anonymized
On Tue, Nov 22, 2011 at 7:08 PM, Jonas Sicking jo...@sicking.cc wrote:
This expression finds all div elements which has at least 6 span
descendants and where an odd number of those span elements have a
data-foo attribute equal to its parents data-bar attribute. It is
obviously trivial to add
On Mon, Nov 21, 2011 at 11:34 AM, Boris Zbarsky bzbar...@mit.edu wrote:
The sticking point here is obviously item #2. Data needed on use of
matches and is as barewords in on* attributes, specifically.
I don't follow. matchesSelector is on Element, not Node, right? Why
is it relevant to on*
On Mon, Nov 21, 2011 at 11:29 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
That only interferes if .find() for selectors is defined on window.
qSA is only defined on Document and Element, though, and I see no
reason that .find wouldn't be the same.
So then we get another built-in method that
On Mon, Nov 21, 2011 at 8:54 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
You're not misunderstanding, but you're wrong. ^_^ The element
itself is put in the lookup chain before document. See this testcase:
!DOCTYPE html
button onclick=alert(namespaceURI)foo/button
(namespaceURI was
On Tue, Nov 8, 2011 at 9:17 AM, Arthur Barstow art.bars...@nokia.com wrote:
My summary is: although HTML Editing APIs is in scope for WebApps, and we
agreed to use public-webapps for related discussions [1], given no one has
agreed to actively drive the spec in WebApps, we will not include it
(sorry for the delay in responding, I 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
On Mon, Oct 24, 2011 at 11:08 AM, Aryeh Gregor a...@aryeh.name wrote:
As far as I know, the use-case is to prevent users from copying text
easily.
. . . although on second thought, why would authors want to allow
collapsed selections, then? Maybe I'm just confused.
On Fri, Oct 21, 2011 at 4:42 PM, Ms2ger ms2...@gmail.com wrote:
However, *I do object to the publication* of this specification because the
inappropriate resolution of the following issues (in no particular order):
First (issue 123), it contradicts an uncontested requirement [1] in DOM4
On Fri, Sep 23, 2011 at 4:09 PM, Arthur Barstow art.bars...@nokia.com wrote:
With this understanding, and having not noticed any objections to Aryeh's
proposal, I think we should consider Aryeh's proposal as accepted.
Thank you. I've updated the spec and will use this list accordingly
in the
On Thu, Sep 22, 2011 at 7:33 AM, Arthur Barstow art.bars...@nokia.com wrote:
It seems to me, that by virtue of using public-webapps, it does give WebApps
WG a role e.g. to at least comment on the CG's editing spec. [Whether such a
role is official or not is probably just splitting hairs.]
I
On Thu, Sep 22, 2011 at 1:04 PM, Charles Pritchard ch...@jumis.com wrote:
Does it have to be an either-or situation? Given that there are pressures to
publish in REC, to have a version which follows various procedures, it seems
plausible that the two can coexist.
That's true, but there's no
On Thu, Sep 22, 2011 at 2:44 PM, Arthur Barstow art.bars...@nokia.com wrote:
It appears you are intentionally using comments here to differentiate
contributions. Is that right?
Right.
I ask because, as I understand the CG process: before a person can make a
contribution to a CG spec, they
On Mon, Sep 19, 2011 at 12:48 PM, Arthur Barstow art.bars...@nokia.com wrote:
Aryeh - coming back to your question below ...
Since you are the Chair of the HTML Editing APIs CG [CG], would you please
explain what you see as the relationship between the CG and WebApps
vis-à-vis the Editing
On Mon, Sep 19, 2011 at 12:48 PM, Arthur Barstow art.bars...@nokia.com wrote:
Since you are the Chair of the HTML Editing APIs CG [CG], would you please
explain what you see as the relationship between the CG and WebApps
vis-à-vis the Editing spec? In particular, what role(s) do the CG and WG
On Fri, Sep 16, 2011 at 1:44 PM, Charles Pritchard ch...@jumis.com wrote:
I don't think it's malicious. But, Google has unprecedented control over
these W3C specs.
They are absolutely using that control to benefit their priorities.
Google has exercised no control over my spec. I've written it
On Wed, Sep 14, 2011 at 7:30 PM, Arthur Barstow art.bars...@nokia.com wrote:
Since some related functionality was included (at one point) in the HTML5
spec, it seems like we should ask the HTML WG for feedback on Aryeh's email.
Aryeh told me there are some related bugs:
For the last several months, I was working on a new specification,
which I hosted on aryeh.name. Now we've created a new Community Group
at the W3C to host it:
http://aryeh.name/spec/editing/editing.html
http://www.w3.org/community/editing/
Things are still being worked out, but one issue is
On Sun, Sep 4, 2011 at 9:12 AM, Arthur Barstow art.bars...@nokia.com wrote:
Some members of the group consider the D3E spec as the highest priority of
our DOM-related specs and they have put considerable resources into that
spec. Doug and Jacob will continue to lead that spec effort, and as I
On Wed, Sep 7, 2011 at 5:47 AM, Olli Pettay olli.pet...@helsinki.fi wrote:
What happens if beforeeditaction tears down the document, or
changes the document significantly or closes the window etc.
(Those a generic problems with before* events)
It shouldn't make any difference. The behavior of
I filed a bug against DOM Core:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13971
On Tue, Aug 30, 2011 at 4:33 AM, Jonas Sicking jo...@sicking.cc wrote:
My point was that it was a mistake for querySelectorAll to return a
NodeList. It should have returned an Array. Sounds like people agree
with that then?
I don't have a problem with that, if it can be changed safely.
On Tue, Aug 30, 2011 at 4:44 PM, Karl Dubost ka...@opera.com wrote:
Le 29 août 2011 à 14:57, Aryeh Gregor a écrit :
In editing, it's common to want to change an element's name. For
instance, document.execCommand(formatblock, false, h1) will change
the current line's wrapper to an h1
On Thu, Aug 25, 2011 at 7:17 PM, Jonas Sicking jo...@sicking.cc wrote:
.push and .pop are generic and work on anything that looks like an
Array. However they don't work on NodeList because NodeList isn't
mutable.
. . .
None of these are *mutable* functions.
Oh, right. I misunderstood you.
On Fri, Aug 26, 2011 at 12:48 AM, Jonas Sicking jo...@sicking.cc wrote:
The point is that if it's just a chapter in a larger spec, how do I
know that there isn't other important information in the larger spec
that I have to read in order to get a understanding of the full
feature.
The same
In editing, it's common to want to change an element's name. For
instance, document.execCommand(formatblock, false, h1) will change
the current line's wrapper to an h1. Unbolding b id=foo should
produce span id=foo. My editing spec defines an algorithm for this
On Mon, Aug 29, 2011 at 3:40 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Shades of
http://www.w3.org/TR/DOM-Level-3-Core/core.html#Document3-renameNode
That has some good catches I hadn't thought of -- it preserves event
handlers and custom JS attributes too.
On Thu, Aug 25, 2011 at 2:33 AM, Jonas Sicking jo...@sicking.cc wrote:
That works, but what is the advantage?
The same advantage as having those methods work for Array. :)
They're useful for lots of stuff.
And .push/.pop or other mutating functions wouldn't work.
Right. I'm only talking
On Sun, Aug 21, 2011 at 1:52 PM, Julien Richard-Foy
jul...@richard-foy.fr wrote:
Since Javascript 1.6, a lot of useful collection functions are defined for
Array [1]. Unfortunately, they can’t be used directly with results returned by
.querySelectorAll, or even .getElementsByTagName since these
On Mon, Aug 15, 2011 at 11:23 PM, Shawn Wilsher m...@shawnwilsher.com wrote:
On 8/3/2011 10:33 AM, Jonas Sicking wrote:
IndexedDB does however not allow readers to start once a writing
transaction has started. I thought that that was common behavior even
for MVCC databases. Is that not the
On Fri, Aug 12, 2011 at 6:16 PM, Jonas Sicking jo...@sicking.cc wrote:
Yup. Though I think WebIDL will take care of the handling for when the
author specifies a negative value. I.e. WebIDL will specify what
exception to throw, so we don't need to. Similar to how WebIDL
specifies what exception
On Fri, Aug 12, 2011 at 7:42 AM, Arthur Barstow art.bars...@nokia.com wrote:
Anne, Ms2ger, All - can you live with adding a note to D2V rather than going
down the rescind path?
I'm fine with having prominent notices in obsolescent standards
pointing readers to the up-to-date work. If
On Thu, Aug 11, 2011 at 6:28 AM, Arthur Barstow art.bars...@nokia.com wrote:
Before we publish a new WD of Anne's DOM spec, I would like comments on how
the DOM specs should be organized. In particular: a) whether you prefer the
status quo (currently that is DOM Core plus D3E) or if you want
On Wed, Aug 3, 2011 at 10:12 AM, Arthur Barstow art.bars...@nokia.com wrote:
Anne would like to publish a new WD of DOM Core and this is a Call for
Consensus (CfC) to do so:
http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html
Agreeing with this proposal: a) indicates support for
On Mon, Aug 1, 2011 at 9: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…)
Creates an element with the specified tag,
On Tue, Aug 2, 2011 at 2:05 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Read again - the idea is to auto-expand arrays.
(I don't have much of a preference between just use an array and
use varargs, but expand arrays. I agree that using only varargs
without expansion would be bad.)
I'm
On Mon, Jul 25, 2011 at 11:12 PM, Sean Hogan shogu...@westnet.com.au wrote:
I assume you are referring to the NodeWatch proposal from Microsoft.
1st draft:
http://www.w3.org/2008/webapps/wiki/Selector-based_Mutation_Events
2nd draft:
On Sat, Jul 23, 2011 at 10:04 AM, Glenn Adams gl...@skynav.com wrote:
I would suggest not using the word theft, even if placed in quotes. Call
it bandwidth leeching or something like that. It certainly is by no means
theft by any reasonable definition.
Theft is a broad term that can informally
On Thu, Jul 21, 2011 at 1:02 PM, Adrian Bateman adria...@microsoft.com wrote:
For platform features that directly affect web developers' pages that might
sometimes be true. However, compression is also optional in HTTP and it
doesn't appear to have caused problems or made some sites work and
On Mon, Jul 25, 2011 at 4:58 PM, Adrian Bateman adria...@microsoft.com wrote:
First, I don't think that's the same thing at all.
Why not?
Second, the IETF HyBi working
group has asked members of this working group for Last Call feedback. If you
think the protocol has the wrong mix of
On Fri, Jul 22, 2011 at 11:54 AM, Boris Zbarsky bzbar...@mit.edu wrote:
Actually, you can pretty easily do it in the other order (move the text into
the b, and then put the b in the DOM), and may want to so as to minimize
the number of changes the the live DOM; that's something that's often
When discussing mutation events use-cases, mostly so far people have
been talking about editors. However, I think mutation event
replacements would have a much more general appeal if they were easily
usable in certain cases with little performance impact. Specifically,
one use-case I've run into
On Thu, Jul 21, 2011 at 4:21 PM, Boris Zbarsky bzbar...@mit.edu wrote:
I'd really like numbers. Having looked at the Gecko editor code in the
past, I don't share your assurance that this is how it works
That said, if you point to a workload, I (or anyone else; it's open source!)
can
On Wed, Jul 20, 2011 at 3:11 PM, Ryosuke Niwa rn...@webkit.org 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 are invoked. Also, what happens if a function removed a
bunch
On Wed, Jul 20, 2011 at 1:43 AM, David Flanagan dflana...@mozilla.com wrote:
Finally, I still think it is worth thinking about trying to model the
distinction between removing nodes from the document tree and moving them
(atomically) within the tree.
I'll chip in that I think this is useful.
On Sun, Jul 10, 2011 at 5:04 PM, Charles McCathieNevile
cha...@opera.com wrote:
Not quite. I'm saying that there are cases where violoating the requirement
is reasonable, so test results shouldn't determine simple conformance.
On the other hand, where these are things that in *most* cases we
On Sun, Jul 10, 2011 at 3:59 PM, Charles McCathieNevile
cha...@opera.com wrote:
Privacy and security restrictions leap to mind. There are things that really
are should requirements because there are valid use cases for not applying
them, and no reason to break those cases by making the
On Thu, Jul 7, 2011 at 3:47 PM, Ian Hickson i...@hixie.ch wrote:
Anything that allows us to _not_ coordinate is an epic disaster, IMHO.
We absolutely should be coordinating. How else can we ensure the platform
is a consistent platform?
This is a feature, not a bug.
Maybe, but I still think
On Fri, Jul 8, 2011 at 3:56 PM, Ian Hickson i...@hixie.ch wrote:
If the proposal is to make all exceptions have a name property (or
whatever we call it) whether in ES, in DOM, or anywhere else, and to have
everyone pick consistent exception names, then I'm fine with that. If we
do do that then
1 - 100 of 147 matches
Mail list logo
