Re: [whatwg] Request for new DOM property textarea.selectionText
All editing commands work inside input/textarea on WebKit although some of
them have no effect (e.g. bold, italic, etc...)
I think reusing execCommand is better than adding new method for
input/textarea elements for each new feature request like this one.
- Ryosuke
On Fri, Apr 27, 2012 at 9:36 PM, Ian Hickson wrote:
> On Fri, 27 Apr 2012, Ryosuke Niwa wrote:
> >
> > Why are we adding this new API? WebKit already supports
> >
> > document.execCommand('InsertText', false, "new selected text");
>
> That's for contenteditable regions, right?
>
> The new API is for and . Also, it's not limited to
> replacing the selected text, it can be any region.
>
> --
> Ian Hickson U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
> Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
>
Re: [whatwg] Request for new DOM property textarea.selectionText
On Fri, 27 Apr 2012, Ryosuke Niwa wrote:
>
> Why are we adding this new API? WebKit already supports
>
> document.execCommand('InsertText', false, "new selected text");
That's for contenteditable regions, right?
The new API is for and . Also, it's not limited to
replacing the selected text, it can be any region.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Request for new DOM property textarea.selectionText
Why are we adding this new API? WebKit already supports
document.execCommand('InsertText', false, "new selected text");
- Ryosuke
On Fri, Apr 27, 2012 at 9:01 PM, Ian Hickson wrote:
> On Mon, 10 May 2010, Biju wrote:
> >
> > Can we have a new DOM property textarea.selectionText which can be used
> > to set/get selection text of a TEXTAREA/INPUT type=text.
>
> Gettng the value is relatively easy:
>
> On Mon, 10 May 2010, Biju wrote:
> >
> > Current way in firefox is to
> >
> > 1. OrigStart = textarea.selectionStart
>
> But admittedly setting it is a pain:
>
> > 2. textarea.value = textarea.value.substr(0, OrigStart)
> > + new_text_to_replace
> > + textarea.value.substr(textarea.selectionEnd);
> > 3. Now u loose original selection, so
> >
> > 4. textarea.setSelectionRange(OrigStart,
> OrigStart+new_text_to_replace.length)
> > 5. remember .scrollTop and reapply if needed
>
> I agree that making this easier would be good.
>
>
> > On IE even though wierd you can do it simply by
> >document.selection.createRange().text = new_text_to_replace;
> > BTW, you need to make sure the selection is currently on the
> > textarea/input form control.
> > IE is also very fast when doing that, when firefox hangs few second
> > using the other way
>
> IE's version is non-standard and not adopted by other UAs.
>
>
> On Mon, 10 May 2010, Ojan Vafai wrote:
> >
> > In addition to selection and scroll issues, needing to replace the
> > entire textarea value doesn't scale and thus limits what sorts of things
> > you can do with textareas. A general way to set a sub-part of a
> > textarea's value seems useful to me. I don't think we should tie that to
> > setting the selected text though.
> >
> > textarea.setRangeText(start, end, text);
> >
> > It replaces the text between start and end, maintains current scroll
> > position and preserves the selection.
>
> On Tue, 11 May 2010, Biju wrote:
> >
> > Both have advantages
> >
> > Option 1 (textobj.selectionText) advantages
> > * No need for web developer to provide selection start/end
> > * Automatically select the newly inserted text,
> >(as most time that is what you want)
> > * No need for web developer to calculate selection start/end for
> > setting it after text insert
> > * preserve scroll
> > * Has both Getter and Setter
> >
> > Option 2 (textobj.setRangeText(start, end, text)); advantages
> > * Independent of selection, web developer can change text at any range
> >with out affecting selection
> > * Web developer has more options with it.
> > * preserve scroll
> >
> > So I want to merge both suggestion, with a new signature,
> > also trying to reduce coding for web developer "less code less bug"
> >
> > textobj.setRangeText(newtext, start, end, cursorpos)
> >
> > parameters:
> > newtext
> > - optional parameter
> > - new text that will replace existing
> > - if missing/null/undefined/NaN then default to ""
> >
> > start
> > - optional parameter
> > - starting position of the original textobj text that need to be
> replaced
> > - if missing/null/undefined/NaN then default to textobj.selectionStart
> > - negative value make start position from last character in the text
> content
> >
> > end
> > - optional parameter
> > - ending position of the original textobj text that need to be replaced
> > - if missing/null/undefined/NaN then default to textobj.selectionEnd
> > - negative value make end position from last character
> >
> > cursorpos
> > - optional parameter
> > - if missing/null/undefined/NaN then default to 0
> > - what should happen to cursor/selection after text insert, its values
> are
> > - - 0 - select the newly inserted text
> > - - 1 - place cursor at beginning of inserted text
> > - - 2 - place cursor at the end of inserted text
> > - - 3 - keep selection unaffected
> > * issue, when value is 3 what should we do when setRangeText is
> replacing text
> > which has some parts selected and some other parts unselected
> >
> >
> > so if somebody want replace selection text it is just
> > textobj.setRangeText(newtext);
> > which is almost same as my original proposal, and
> > textobj.setRangeText();
> > will blank a selection
>
> That seems a bit overly complicated, but something in that vein seems
> reasonable.
>
> I've added
>
> setRangeText(newText); // replace selection with newText
> setRangeText(newText, start, end); // replace given range with newText
> setRangeText(newText, start, end, action); // see below
>
> ...where action is one of:
>
> 'select': selects the new text
> 'start': selects empty range at start of new text
> 'end': selects empty range at end of new text
> 'preserve': (default) set selection as follows:
>
>- if selection start was before range, leave as is
>- if selection start was after the old range, put it as far from the
> end of the new range as it was from the end of the old range
>- if selection start was in the o
Re: [whatwg] Request for new DOM property textarea.selectionText
On Mon, 10 May 2010, Biju wrote: > > Can we have a new DOM property textarea.selectionText which can be used > to set/get selection text of a TEXTAREA/INPUT type=text. Gettng the value is relatively easy: On Mon, 10 May 2010, Biju wrote: > > Current way in firefox is to > > 1. OrigStart = textarea.selectionStart But admittedly setting it is a pain: > 2. textarea.value = textarea.value.substr(0, OrigStart) > + new_text_to_replace > + textarea.value.substr(textarea.selectionEnd); > 3. Now u loose original selection, so > > 4. textarea.setSelectionRange(OrigStart, > OrigStart+new_text_to_replace.length) > 5. remember .scrollTop and reapply if needed I agree that making this easier would be good. > On IE even though wierd you can do it simply by >document.selection.createRange().text = new_text_to_replace; > BTW, you need to make sure the selection is currently on the > textarea/input form control. > IE is also very fast when doing that, when firefox hangs few second > using the other way IE's version is non-standard and not adopted by other UAs. On Mon, 10 May 2010, Ojan Vafai wrote: > > In addition to selection and scroll issues, needing to replace the > entire textarea value doesn't scale and thus limits what sorts of things > you can do with textareas. A general way to set a sub-part of a > textarea's value seems useful to me. I don't think we should tie that to > setting the selected text though. > > textarea.setRangeText(start, end, text); > > It replaces the text between start and end, maintains current scroll > position and preserves the selection. On Tue, 11 May 2010, Biju wrote: > > Both have advantages > > Option 1 (textobj.selectionText) advantages > * No need for web developer to provide selection start/end > * Automatically select the newly inserted text, >(as most time that is what you want) > * No need for web developer to calculate selection start/end for > setting it after text insert > * preserve scroll > * Has both Getter and Setter > > Option 2 (textobj.setRangeText(start, end, text)); advantages > * Independent of selection, web developer can change text at any range >with out affecting selection > * Web developer has more options with it. > * preserve scroll > > So I want to merge both suggestion, with a new signature, > also trying to reduce coding for web developer "less code less bug" > > textobj.setRangeText(newtext, start, end, cursorpos) > > parameters: > newtext > - optional parameter > - new text that will replace existing > - if missing/null/undefined/NaN then default to "" > > start > - optional parameter > - starting position of the original textobj text that need to be replaced > - if missing/null/undefined/NaN then default to textobj.selectionStart > - negative value make start position from last character in the text content > > end > - optional parameter > - ending position of the original textobj text that need to be replaced > - if missing/null/undefined/NaN then default to textobj.selectionEnd > - negative value make end position from last character > > cursorpos > - optional parameter > - if missing/null/undefined/NaN then default to 0 > - what should happen to cursor/selection after text insert, its values are > - - 0 - select the newly inserted text > - - 1 - place cursor at beginning of inserted text > - - 2 - place cursor at the end of inserted text > - - 3 - keep selection unaffected > * issue, when value is 3 what should we do when setRangeText is replacing text > which has some parts selected and some other parts unselected > > > so if somebody want replace selection text it is just > textobj.setRangeText(newtext); > which is almost same as my original proposal, and > textobj.setRangeText(); > will blank a selection That seems a bit overly complicated, but something in that vein seems reasonable. I've added setRangeText(newText); // replace selection with newText setRangeText(newText, start, end); // replace given range with newText setRangeText(newText, start, end, action); // see below ...where action is one of: 'select': selects the new text 'start': selects empty range at start of new text 'end': selects empty range at end of new text 'preserve': (default) set selection as follows: - if selection start was before range, leave as is - if selection start was after the old range, put it as far from the end of the new range as it was from the end of the old range - if selection start was in the old range, move it to the start of the new range - if selection end was before range, leave as is - if selection end was after the old range, put it as far from the end of the new range as it was from the end of the old range - if selection emd was in the old range, move it to the end of the new range > We could also add a getter method, also with optional paramet
Re: [whatwg] [Server-Sent Events] Infinite reconnection clarification
On Fri, Apr 27, 2012 at 4:12 AM, Odin Hørthe Omdal wrote: > I think I should do a TLDR since I didn't really get any answers: > > 1. Should EventSource *ever* time out once it has once been connected? > 2. What do browsers do today? What do you think is a good thing to do? > > I tried Opera, Firefox and Chromium for question 2. > > Opera: Gives up after 2-3 minutes. > Firefox: Gives up after ~15 minutes. > Chromium: Doesn't ever give up. Longer and longer retry intervals, upper > limit (I think) of 1 minute between each retry. I think the best thing for users is infinite reconnect with exponential backoff (the Chrome behavior). This gives the page the best chance of "just working" when the user gets back into an area with connection. Waking up the radio once a minute isn't bad, if we can coalesce all our EventSource requests to use the same window. ~TJ
Re: [whatwg] [media] played member expected behavior.
On Thu, 26 Apr 2012 23:11:37 +0200, Ian Hickson wrote:
On Thu, 26 Apr 2012, Paul Adenot wrote:
The played member [1] description of the media element states :
> The played attribute must return a new static normalized TimeRanges
> object that represents the ranges of the media resource, if any, that
> the user agent has so far rendered, at the time the attribute is
> evaluated.
Currently implementing this member in Gecko, we are wondering the exact
meaning of the 'rendered' term. If one seek in a video to a location
while being in a paused state, the user agent 'renders' the frame at
that location, since it is displayed on the screen. No audio (if any) is
rendered, though.
In that case, should we create an empty range starting and ending at the
time that was seeked to ? That means creating multiple empty ranges if
multiple seeks occur while being paused. Does the 'rendering' term
implies that playback should occur ? This description need clarification
to specify the exact behavior to adopt.
Semantically, the name of the member itself ('played') seem to imply
playback.
I think playback probably is the most useful. The use case here was
updating a playback scrub bar with colour for where the user has already
watched the video, and zero-length entries aren't useful for that.
I've made a note of this e-mail to fix the spec, but in the absence of
further information or opinions from anyone else, I'd go with playback as
you suggest.
We haven't implemented this yet, but I agree that must be played, since an
empty range would violate the definition
.
--
Philip Jägenstedt
Core Developer
Opera Software
Re: [whatwg] Endianness of typed arrays
- Original Message - > Sorry for joining the conversation late. > > On Mar 28, 2012, at 1:39 PM, Kenneth Russell wrote: > > > On Wed, Mar 28, 2012 at 12:34 PM, Benoit Jacob > > wrote: > >> > >> 1. In webgl.bufferData implementation, don't call glBufferData, > >> instead just cache the buffer data. > >> > >> 2. In webgl.vertexAttribPointer, record the attributes structure > >> (their types, how they use buffer data). Do not convert/upload > >> buffers yet. > >> > >> 3. In the first WebGL draw call (like webgl.drawArrays) since the > >> last bufferData/vertexAttribPointer call, do the conversion of > >> buffers and the glBufferData calls. Use some heuristics to drop > >> the buffer data cache, as most WebGL apps will not have a use for > >> it anymore. > > > > It would never be possible to drop the CPU side buffer data cache. > > A > > subsequent draw call may set up the vertex attribute pointers > > differently for the same buffer object, which would necessitate > > going > > back through the buffer's data and generating new, appropriately > > byte-swapped data for the GPU. I wanted to reply to the above that while indeed in theory it's never possible to drop these caches, in practice some heuristics might work well enough that it doesn't matter for real content; and in the worst case where we effectively can't ever drop caches, we have a +10% or +20% memory usage increase for typical WebGL applications (as buffers typically aren't the majority of a WebGL application's memory usage), which is bad but still better than not running WebGL at all. > > That's true. But there are other plausible approaches. There's > GL_PACK_SWAP_BYTES: > > http://www.opengl.org/sdk/docs/man/xhtml/glPixelStore.xml This seems specific to desktop OpenGL and doesn't seem to exist in the core OpenGL ES 2.0 specification. Maybe as an extension? > > Or code generation: translate the shaders to do the byte-swapping > explicitly in GLSL. For floats you should be able to cast back and > forth to ints via intBitsToFloat/floatBitsToInt. Interesting; one would have to measure the performance impact of this. What makes me hopeful is that this should only slow down vertex shaders, not fragment shaders (which are the performance critical shaders in most applications). So this could well be the most practical solution so far. WebGL implementations must have a shader compiler anyways, for multiple reasons (validation, shading language differences, working around driver bugs). This only applies to ARRAY_BUFFER, not ELEMENT_ARRAY_BUFFER buffers, but for the latter, we already have to keep a permanent CPU-side copy anyway for validation purposes, so the approach of swapping bytes in the implementation of drawElements should work well and not have any major downside (since having to keep a CPU-side copy was the main downside). Cheers, Benoit > > But these days more and more big-endian systems have support for > little-endian mode, which is probably the simplest approach. And > honestly, there just don't seem to be WebGL-enabled user agents on > big-endian systems. We've left a specification hole in a place > that's easy to trip over, only out of concern for hypothetical > systems -- in an era when little-endian has clearly won. > > If the web isn't already de facto little-endian -- and I believe my > colleagues have seen evidence that sites are beginning to depend on > it -- then typed arrays force developers to test on big-endian > systems to make sure their code is portable, when it's quite likely > they don't have any big-endian systems to test on. That's a tax on > developers they may not be willing or able to pay. I should know, I > am one! :) > > https://github.com/dherman/float.js/blob/master/float.js > > In a hilariously ironic twist of fate, I recently noticed that the > endianness-testing logic originally had a stupid bug that made > LITTLE_ENDIAN always true. It's now fixed, but I didn't detect the > bug because I didn't have a big-endian JS engine to test on. > > > Our emails certainly crossed, but please refer to my other email. > > WebGL applications that assemble vertex data for the GPU using > > typed > > arrays will already work correctly on big-endian architectures. > > This > > was a key consideration when these APIs were being designed. The > > problems occur when binary data is loaded via XHR and uploaded to > > WebGL directly. DataView is supposed to be used in such cases to > > load > > the binary data, because the endianness of the file format must > > necessarily be known. > > I'm afraid this is wishful thinking. API's have more than a fixed set > of use cases. The beautiful thing about platforms is that people > invent new uses the designers didn't think of. Typed arrays are > simple, powerful, and general-purpose, and people will use them for > all kinds of purposes. Take my "float explorer": > > http://dherman.github.com/float.js/ > > There's no XHR and no Web
Re: [whatwg] [Server-Sent Events] Infinite reconnection clarification
I think I should do a TLDR since I didn't really get any answers: 1. Should EventSource *ever* time out once it has once been connected? 2. What do browsers do today? What do you think is a good thing to do? I tried Opera, Firefox and Chromium for question 2. Opera: Gives up after 2-3 minutes. Firefox: Gives up after ~15 minutes. Chromium: Doesn't ever give up. Longer and longer retry intervals, upper limit (I think) of 1 minute between each retry. And the TL version follows: On Tue, 17 Apr 2012 16:44:56 +0200, Odin Hørthe Omdal wrote: If I understand correcly, the spec expects the implementation to keep reconnecting indefinitely, when the network cable is yanked. It is a strong feeling, but it'd be nice to get it clarified in plain text in the spec. Clients will reconnect if the connection is closed; a client can be told to stop reconnecting using the HTTP 204 No Content response code. CLOSED (numeric value 2) The connection is not open, and the user agent is not trying to reconnect. Either there was a fatal error or the close() method was invoked. The task that the networking task source places on the task queue once the fetching algorithm for such a resource (with the correct MIME type) has completed must cause the user agent to asynchronously reestablish the connection. This applies whether the connection is closed gracefully or unexpectedly. It doesn't apply for the error conditions listed below. And this is the place a small clarification could come in handy: Any other HTTP response code not listed here, and any network error that prevents the HTTP connection from being established in the first place (e.g. DNS errors), must cause the user agent to fail the connection. Maybe "Network errors after a successfully established connection must cause the user agent to try reestablishing the connection indefinitely." Or something better. At least, make it clear what is going to happen. :-) On that note, it'd also be nice to hear what the other vendors do with the connection. It seems like both Firefox and Chromium has an exponential fallback with a max-value between the reconnection tries. The first tries will probably respect the given *reconnection time*, but after a while that'll be too often. I tried yanking the network for 10+ minutes, and when I put the cable in again, both Firefox and Chromium used 25 seconds to reconnect. When only yanking it for one minute, the reconnection was much faster (2-5 seconds). This with *reconnection time* set to 500ms. -- Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com
