Rather than a single string property, how about integer
selectionAnchor and selectionFocus properties? This is then analogous
to Selection's anchorNode, anchorOffset, focusNode and focusOffset
properties and avoids an awkward string property.
That seems to introduce the problem of having this
This sounds good to me. I used the term forwards and backwards
for the DOM Range spec, which I think make more sense. I also think
selectionDirection is a better property name, as Ojan suggests.
Coincidentally, that was exactly what I was going to propose at first,
but then I found the
On Thu, Jan 13, 2011 at 12:52 AM, Marijn Haverbeke mari...@gmail.comwrote:
This sounds good to me. I used the term forwards and backwards
for the DOM Range spec, which I think make more sense. I also think
selectionDirection is a better property name, as Ojan suggests.
Coincidentally,
I ended up creating a PageWorker object, which is constructed in the page
rather then in a WebWorker. It uses setInterval to repeatedly run a function
in the background to do the image processing directly on the canvas imageD
data. To reduce overhead, each interval runs the function in a small
On Thu, Jan 13, 2011 at 5:08 AM, Berend-Jan Wever skyli...@chromium.org wrote:
I ended up creating a PageWorker object, which is constructed in the page
rather then in a WebWorker. It uses setInterval to repeatedly run a function
in the background to do the image processing directly on the
On 13 January 2011 08:48, Marijn Haverbeke mari...@gmail.com wrote:
Rather than a single string property, how about integer
selectionAnchor and selectionFocus properties? This is then analogous
to Selection's anchorNode, anchorOffset, focusNode and focusOffset
properties and avoids an awkward
On 13/01/2011, at 11:35, Glenn Maynard wrote:
On Thu, Jan 13, 2011 at 5:08 AM, Berend-Jan Wever skyli...@chromium.org
wrote:
I ended up creating a PageWorker object, which is constructed in the page
rather then in a WebWorker. It uses setInterval to repeatedly run a function
in the
To preserve shared-nothingness, the passed object (and the object's children)
could be made unreachable (somehow, don't ask me) in the sending context as
soon as passed to the worker. Perhaps other constraints might need to exist,
e.g. perhaps no methods allowed in these objects.
This is a
On 1/13/11 7:24 AM, Jorge wrote:
Not too long ago, the browsers did allow timeouts of less than 10ms.
Uh, no. Not too long ago browsers did not allow timeouts of less than
10ms, ever. At this point the only browser that does for repeated
timeouts is Chrome, which allows 4ms. Various
On 13/01/2011, at 14:05, Marijn Haverbeke wrote:
To preserve shared-nothingness, the passed object (and the object's
children) could be made unreachable (somehow, don't ask me) in the sending
context as soon as passed to the worker. Perhaps other constraints might
need to exist, e.g.
Hey all,
is there any official recommendation for which element to use for form
submission buttons?
Historically, input has been preferred because of button's
implementation differences in IE6. Now that IE6 support is becoming less
and less of an issue for many websites, that argument is
On Thu, 13 Jan 2011 16:21:17 +0100, Alan Plum ht...@alanplum.com wrote:
is there any official recommendation for which element to use for form
submission buttons?
Historically, input has been preferred because of button's
implementation differences in IE6. Now that IE6 support is becoming
But if you could make it unreachable on the sending end then there would be
no need to duplicate it, just to pass a reference to the worker, it would
take about 1 ns.
Yes, but the sender might have gotten this value from anywhere. All
other code using the value will have to know that it is
On 13/01/2011, at 16:27, Marijn Haverbeke wrote:
But if you could make it unreachable on the sending end then there would be
no need to duplicate it, just to pass a reference to the worker, it would
take about 1 ns.
Yes, but the sender might have gotten this value from anywhere. All
On Thu, Jan 13, 2011 at 1:26 AM, Ryosuke Niwa ryosuke.n...@gmail.comwrote:
On Thu, Jan 13, 2011 at 12:52 AM, Marijn Haverbeke mari...@gmail.comwrote:
This sounds good to me. I used the term forwards and backwards
for the DOM Range spec, which I think make more sense. I also think
On Wed, 12 Jan 2011 19:35:15 -, Marijn Haverbeke mari...@gmail.com
wrote:
So I propose a selectionAnchor property, which holds either top or
bottom, and can be set to one of these strings to modify the
direction. top would mean the anchor lies after the base of the
selection, so further
2011/1/13 Kornel Lesiński kor...@geekhood.net
If not, maybe methods to save/restore selection or modify content without
removing selection would be better? (this would allow browsers to support
multiple selected ranges, block selection in multiline inputs, etc.)
var previousSelection =
Would you use it in cases other than restoring previous selection?
My typical use case is that I mess with the content of the input, and
then restore the selection. For example, after adding three characters
to the front, I then restore selectionStart and selectionEnd by adding
three to their
2011/1/13 Marijn Haverbeke mari...@gmail.com
My typical use case is that I mess with the content of the input, and
then restore the selection. For example, after adding three characters
to the front, I then restore selectionStart and selectionEnd by adding
three to their original values. It
On 13/01/2011, at 15:41, Boris Zbarsky wrote:
On 1/13/11 7:24 AM, Jorge wrote:
Not too long ago, the browsers did allow timeouts of less than 10ms.
Uh, no. Not too long ago browsers did not allow timeouts of less than 10ms,
ever.
Last time I checked that in 2008, most Mac browsers had a
Various IDLs in the spec use [NoNull], but apparently WebIDL no longer
defines that (the Changes section says it was removed in 2008). I'm
not sure exactly what it used to do, but the spec should be updated to
use whatever WebIDL now defines as a replacement.
In defining the interface for Node,
On 1/13/11 3:19 PM, Jorge wrote:
On 13/01/2011, at 15:41, Boris Zbarsky wrote:
On 1/13/11 7:24 AM, Jorge wrote:
Not too long ago, the browsers did allow timeouts of less than 10ms.
Uh, no. Not too long ago browsers did not allow timeouts of less than 10ms,
ever.
Last time I checked that
On Thu, Jan 13, 2011 at 9:41 AM, Boris Zbarsky bzbar...@mit.edu wrote:
In any case, to implement the 4ms thing on Windows Chrome has to have a
dedicated thread polling the multimedia timer, which is a huge PITA in terms
of things like wakeups and battery life... And for what it's worth on my
On 1/13/11 4:37 PM, Glenn Maynard wrote:
- trying to actually get very short, accurate timers, and
- using timers simply to return to the browser, run any pending UI
events, and then immediately start work again with no additional
delay.
The second one is actually really really hard to do with
On Thu, Jan 13, 2011 at 4:26 AM, Ryosuke Niwa ryosuke.n...@gmail.com wrote:
I don't like top/bottom because it seems to imply certain visual
orientation. (e.g. I think RTL text in vertical writing mode flows bottom
up). To make terms agnostic of text direction and writing mode, I'd prefer
AppCache feature request: An https manifest should be able to list
resources from other https origins.
I've got some app developers asking for this feature. Currently, it's
explicitly disallowed by the the spec for valid security reasons, but
there are also valid reasons to have this capability,
On Thu, Jan 13, 2011 at 3:08 PM, Aryeh Gregor
simetrical+...@gmail.comsimetrical%2b...@gmail.com
wrote:
On Thu, Jan 13, 2011 at 4:26 AM, Ryosuke Niwa ryosuke.n...@gmail.com
wrote:
I don't like top/bottom because it seems to imply certain visual
orientation. (e.g. I think RTL text in
On Thu, Jan 13, 2011 at 5:21 PM, Boris Zbarsky bzbar...@mit.edu wrote:
The second one is actually really really hard to do with setTimeout.
Especially if you have UI events that need more than one trip through the
event loop to do their thing.
In simple event systems that's mostly a matter of
On 13/01/2011, at 23:21, Boris Zbarsky wrote:
On 1/13/11 4:37 PM, Glenn Maynard wrote:
I suspect there's something simpler going on here, though--as you
said, copying a 10 MB buffer really should be very quick.
It's really not that quick, actually. First, you have to allocate a new 10MB
On 1/13/11 6:38 PM, Glenn Maynard wrote:
It might be possible to optimize the allocation further, but even
2.5ms is worth optimizing out. If you're trying to maintain 60 FPS
(16.6ms per frame), that's 15% of your total available time (ignoring
concurrency).
Indeed. One more note. My 2.5ms
I've noticed, recently, that FF4b8 on Windows has a minimum
window.innerWidth of 392px.
On OS X, Chrome M10 has a minimum innerWidth of 400px.
IE9p7 has a minimum reported width of 234px.
Height is not restricted so severely.
In FF, at least, using zoom in allows the the innerWidth to be
31 matches
Mail list logo
