Re: [whatwg] Specification of window.find()
On 29 June 2012 21:46, Ian Hickson i...@hixie.ch wrote: Given the lack of interest in the feature, I have removed it from the spec and recommend to implementors that they drop support for the API. What's the procedure for proposing a new API to address the same use cases I've described earlier in the thread? I would favour an addition to Range. Tim
Re: [whatwg] Specification of window.find()
On 21 July 2011 20:59, Aryeh Gregor simetrical+...@gmail.com wrote:
On Wed, Jul 20, 2011 at 6:23 PM, Tim Down timd...@gmail.com wrote:
Yes, but it's significantly better than the alternative, which is to
write your own code to search for text that spans nodes.
It shouldn't be *too* hard to write that code. First do the search in
textContent and get a list of the offsets of all the results. Then
get a list of Text nodes, and iterate through them. Record the sum of
their lengths as you go, and when you get to the right place, store
the result. I'd guess it would be 20 lines or so. Something like
this (untested):
function findStrings(root, search) {
var offsets = [];
for (var i = root.textContent.indexOf(search); i != -1; i =
root.textContent.indexOf(search, i + 1)) {
offsets.push(i);
}
var results = [];
var treeWalker = document.createTreeWalker(root, NodeFilter.SHOW_TEXT);
var currentOffset = 0;
while (treeWalker.nextNode()) {
while (offsets.length
currentOffset = offsets[offsets.length - 1]
offsets[offsets.length - 1] currentOffset +
treeWalker.currentNode.length) {
results.push([treeWalker.currentNode,
offsets[offsets.length - 1] - currentOffset]);
offsets.pop();
}
currentOffset += treeWalker.currentNode.length;
}
return results;
}
Probably buggy, but something like that should work. (And hey, it's
19 lines, good guesswork.) Granted, if you wanted to do any kind of
normalization it would be more complicated to author, but also more
complicated to spec. So I don't see really a use-case here that's
strong enough to justify this, if we can get rid of it.
There's also the perennial problem of dealing with non-visible text
(c.f. Selection.toString(), innerText), which some browsers handle (a
quick tests suggests WebKit searches non-visible text and Firefox
doesn't). Also, don't forget that you're in the habit of writing this
sort of code. Knocking that kind of code out quickly is beyond what a
large percentage of web developers are capable of.
Agreed. My number two feature (well, it would make the top 5, at
least) would be removing the restriction on execCommand() only working
on editable content. This very use case shows that its usefulness
extends beyond editable content. The temporarily-switch-designMode-on
workaround is ugly, and destroys the selection in some browsers.
As I said elsewhere, I disagree. Wanting to only modify editable
content is an important use-case. It's easy to emulate the behavior
you want if that restriction is in place (temporarily turn on
designMode), but nearly impossible to emulate the opposite behavior if
it's not built in to start with. If execCommand() worked on any
content at all, then text editors would be permanently forced to use
iframes with designMode instead of being able to use contenteditable,
just to avoid the user randomly bolding or deleting interface text.
Also, it would mean that (for instance) execCommand(delete) works
differently from the backspace key.
If turning designMode on destroys the selection in some browsers,
that's a bug that can easily be fixed, and doesn't justify a change to
the spec. Changing specs to work around easily-fixed browser bugs
makes much less sense than just fixing the bugs. The only
disadvantage I see to requiring this is that it's error-prone: the
obvious way to do it is to turn designMode on and then turn it off,
which will have an unexpected side effect if it had already been on.
But that's a minor issue, and I don't see a good way to avoid it.
Why exactly do you not want to turn designMode on and off, other than
easily-fixed browser bugs? What do you think is ugly about it?
I absolutely agree that restricting mutation to editable content is
important. My issues with using designMode are a combination of side
effects and implementation quirks in current and older browsers, which
I agree doesn't justify a change to the spec, and a gut feeling that
it's the wrong approach. There is no reason why your algorithms can't
work on non-editable nodes, so why require the user to change such a
fundamental property of the DOM (even temporarily)? I'd prefer an
alternative mechanism for specifying whether a command should apply to
only editable content that is part of the editing API. In my
execCommand implementation, it's specified as a property of an options
object passed to execCommand(). If that's not an option, another
command could be used, similar to the styleWithCSS command, to switch
between modes. applyToNonEditable, or something.
Tim
Re: [whatwg] Specification of window.find()
On 6 January 2011 21:53, Ian Hickson i...@hixie.ch wrote: On Wed, 27 Oct 2010, benjamin.poul...@nokia.com wrote: I would like to suggest a change for the main HTML 5 specification: http://www.whatwg.org/specs/web-apps/current-work/ The problem I have is with the Window object specification (http://www.whatwg.org/specs/web-apps/current-work/#the-window-object ). It does not mention the method find() which can be found on most engines (e.g.: https://developer.mozilla.org/en/DOM/window.find ). It looks like IE doesn't implement this, so it's probably not strictly required for compat with the Web. What are the use cases for this feature? It's useful for custom search features. I've recommended it a few times on Stack Overflow for people wanting to highlight or somehow style all occurrences of a piece of text that may span nodes (it's this part that is the compelling feature). You can achieve the same using TextRange in IE. For example: http://stackoverflow.com/questions/5886858/full-text-search-in-html-ignoring-tags I think this is a valid use case. On a related note, I would like to see equivalents of some of the text-based methods in IE's TextRange make their way into Range, but that's a separate issue. Tim
Re: [whatwg] Specification of window.find()
On 20 July 2011 17:58, Aryeh Gregor simetrical+...@gmail.com wrote: On Wed, Jul 20, 2011 at 6:14 AM, Tim Down timd...@gmail.com wrote: It's useful for custom search features. I've recommended it a few times on Stack Overflow for people wanting to highlight or somehow style all occurrences of a piece of text that may span nodes (it's this part that is the compelling feature). You can achieve the same using TextRange in IE. For example: http://stackoverflow.com/questions/5886858/full-text-search-in-html-ignoring-tags I think this is a valid use case. However, the implementation here doesn't do what you'd want: it selects the text, destroying any existing selection. You can work around it by preserving and then restoring the selection somehow, but it's not ideal at all. Yes, but it's significantly better than the alternative, which is to write your own code to search for text that spans nodes. It would make much more sense to have a function that returned a Range or list of Ranges. Absolutely. Of course, for the use-case you posted, execCommand() would also have to work on Ranges instead of just the selection, but that should probably be feature #1 to add to it anyway . . . Agreed. My number two feature (well, it would make the top 5, at least) would be removing the restriction on execCommand() only working on editable content. This very use case shows that its usefulness extends beyond editable content. The temporarily-switch-designMode-on workaround is ugly, and destroys the selection in some browsers. Tim
Re: [whatwg] Generalized execCommand() alternatives, or standardized selection and range handling
On 31 May 2011 18:39, Aryeh Gregor simetrical+...@gmail.com wrote: On Tue, May 31, 2011 at 4:15 AM, Markus Ernst derer...@gmx.ch wrote: Anyway, everything we need is actually available in the DOM, except a standardized and simple handling of selections and ranges. (Well, I might be wrong - but looking at the Gecko DOM reference and the MSDN DHTML reference, they show very different approaches to the range and selection objects, and the code of TinyMCE shows lots of browser sniffing.) That's because browsers' implementations don't follow the specs, or in some cases because there weren't specs until the last few months, not because there's anything wrong with the spec. I've implemented all my algorithms in pure JavaScript, and there are almost no places where I have to work around browser bugs -- given that I only target the latest versions of IE/Firefox/Chrome/Opera. implementation.js is over 4000 lines, and I estimate I've needed maybe ten browser-specific workarounds, certainly under twenty. (If you want to support IE9, of course, have fun . . .) I'm working on this. There was a perverse pleasure in getting to a workable version of the Range and Selection APIs in IE 9, and the commands stuff I've recently built on top based on (a slightly outdated version of) Aryeh's code has required relatively little browser-specific code to get bold and italic working. Very rough demo here (works in IE 6 - 8 as well as sensible browsers): http://rangy.googlecode.com/svn/branches/1point2/demos/commands.html. The only major thing that can't be done in JS is change how ranges behave when you mutate the DOM. Effectively, I work around it by using a single Range object to represent the user's selection, and I only care how that changes. This might actually be the way I'll end up speccing it too, although it'd be nice if we could preserve ranges outside the selection too. My version passes an array of ranges to be preserved to the command's various internal methods. Works with multiple selected ranges in Firefox. Tim
Re: [whatwg] Generalized execCommand() alternatives, or standardized selection and range handling
On 31 May 2011 09:15, Markus Ernst derer...@gmx.ch wrote: While following the discussions about Aryeh Gregor's great work on execCommand(), I get the impression that this method is very limited to some basic formatting actions. It provides shortcuts for a limited set of DOM actions, but is not really extendable or generalizable. Some of the discussions were about adding support for new elements, such as header and section, or for distinctive i and em resp. b and strong elements. I doubt that extending execCommand() with specific new commands for more elements would be the direction to go. With the focus on HTML editing rather than WYSIWYG editing, some kind of generalized wrapping/unwrapping mechanism would be helpful. This could be handled with a new method that offers shortcuts for wrapping/unwrapping selections; some kind of addWrapper(elementName) and removeWrapper(elementName). Anyway, everything we need is actually available in the DOM, except a standardized and simple handling of selections and ranges. (Well, I might be wrong - but looking at the Gecko DOM reference and the MSDN DHTML reference, they show very different approaches to the range and selection objects, and the code of TinyMCE shows lots of browser sniffing.) I'd find it very helpful as an addition to Aryeh's work, to get standardized methods for actions like: - creating a range out of a selection - block-extending the range - accessing all child elements of the range - accessing all parent elements of the range - memorizing start and end points in order to reset the selection after modifications (This list may not be complete.) I'd be happy about some thoughts on this. -- Markus Aryeh's own example implementation script accompanying the execCommand spec has several of these (block-extending a range, decomposing a range and performing DOM manipulation while preserving ranges, for example). See http://aryeh.name/spec/editcommands/implementation.js Tim
Re: [whatwg] More HTML Editing Commands questions
On 19 May 2011 21:10, Aryeh Gregor simetrical+...@gmail.com wrote:
(You know that
!DOCTYPE HTML
style
span { border: solid black 1px; }
/style
pspanOne/span/pspan
/spanpspanTwo/span/p
will behave the same as what you wrote and is just as conformant, right?)
Actually I didn't. Thanks for the tip. I have some HTML5 reading to do.
What I have in mind doesn't involve DOM mutation. Imagine the
selection is collapsed in the middle of a text node and the bold
command is called. The browser now has an internal flag set but there
is no change in the DOM. However, if the selection is moved away from
its current position, that flag is unset and that position is no
longer notionally bold, even if the selection is then returned to its
original position before anything else happens. This happens in all
browsers. To achieve this with JavaScript running in the page, you
need a reliable selection change event. For the purposes of simply
tracking the user moving the selection, an asynchronous event would be
fine.
Assuming that your goal here is to replicate execCommand() from
JavaScript, what happens if the user puts the selection somewhere,
bolds, types something, then moves the selection elsewhere? I guess
that works fine if there are reliable input events (are there?), and
they're ordered properly with respect to the selection change events.
There's no issue in that scenario if there is a selection change event
that fires when the the user does the final selection move. What are
you getting at? Sorry if I'm missing something.
Tim
[whatwg] More HTML Editing Commands questions
I have a couple of general questions about the HTML Editing Commands spec: 1) Will there be any provision for special handling of whitespace text nodes? I notice that WebKit leaves them alone. For example, running document.execCommand(bold, false, null) for the following HTML with selection boundaries denoted by pipes: p|One/p pTwo|/p ... in Chrome 10 you get p|bOne/b/p pbTwo|b/p The whitespace between the p elements has been ignored. This also leads to a bug, since it seems the check for whether the selection content is already completely bold does take into account the whitespace node and rerunning the command now has no effect. Opera surrounds the whitespace node within a styling element, while Firefox seems to have some voodoo magic to decide whether or not to surround a whitespace node. In the simple case above, it leaves it alone so long as I haven't previously manipulated the DOM manually with my own script. 2) Will the spec specify what happens when executing commands on an insertion point/caret? Tim
Re: [whatwg] HTML Editing Commands spec minor clarifications
On 12 May 2011 19:06, Aryeh Gregor simetrical+...@gmail.com wrote: Really the whole idea of multiple Ranges per Selection is underdefined right now, since AFAIK only Gecko supports it at all, and the way it does it is weird and we don't really want to spec it, and other engines don't seem to want to implement it anyway. So I might get to that at some point, but for now I'm not really paying attention to it. My current focus is on getting the execCommand() algorithms right -- I'm leaving API details for later. IIRC, my testing did actually show that Gecko affects the first range, meaning the first range ordered by start. (Also IIRC, Gecko doesn't permit overlapping ranges, so the start is always unique.) But I've added a todo here also, pointing out the possible error: http://aryeh.name/gitweb.cgi?p=editcommands;a=commitdiff;h=93e928f08347078c8518e428338e9e8606a5eb66 Actually, it would make most sense to just affect all ranges in the selection, and I wouldn't be surprised if the current Gecko behavior is an accident. I did some simple tests yesterday that confirm that Gecko generally acts only the first range, and was slightly surprised. I would expect it to affect all ranges in the selection. However, when you select multiple table cells in Gecko (which always creates a range for each selected cell, regardless of whether or not you use the Ctrl key), calling document.execCommand() acts on each range. Only the state of the first range is taken into consideration when deciding what state the selection has, meaning that for a binary command such as Bold, all selected cells are switched to the opposite state to that of the first selected cell. Tim
Re: [whatwg] Selection events in editable content
On 10 May 2011 16:42, Ryosuke Niwa rn...@webkit.org wrote: On Tue, May 10, 2011 at 8:33 AM, Ojan Vafai o...@chromium.org wrote: What's the difference between selectstart and selectionchange in WebKit? In IE is this case the only difference between the two? selectstart fires before selection changes, it bubbles, and it's cancelable. So it's very useful if you want to prevent selection. But the event isn't useful as much as it could be because it doesn't tell you what new selection is so we might want to consider adding new property like newSelectionRanges that tells you what new selection will be. - Ryosuke newSelectionRanges on its own wouldn't be as useful as possible, since it tells you nothing about the selection direction. You could cover this by adding newSelectionFocusNode, newSelectionFocusOffset, newSelectionAnchorNode and newSelectionAnchorOffset as well. Tim
[whatwg] Selection events in editable content
Are there any plans for selection-related events for editable HTML content (contenteditable or designMode)? An event that fires whenever the selection changes would be very useful and seems a curious oversight in most current browsers. The current situation is: - There are two events that exist: select and selectstart - In IE, the selectstart event fires whenever the user starts changing the selection within any contenteditable element, including when the user chooses Select all from the edit or context menus. It also fires on the body element when the user starts making a selection anywhere in the page. - Additionally, in IE, the select event fires on the body element whenever the selection changes, whether the body is contenteditable or not, including when the user chooses Select all from the edit or context menus - In WebKit, the selectstart event fires on the body whenever the user starts making a selection either with the mouse or the keyboard (regardless of whether the content is editable), and then fires again whenever the mouse moves in the case of a mouse selection until the button is released. However, no event is fired in WebKit when the user chooses Select all from the edit or context menus, or presses Ctrl/Cmd-A. - Firefox does not fire either event in editable content. IE is the only major browser that has seriously useful behaviour here. Are there any plans to spec this or similar behaviour? I can think of several use cases within the context of a rich text editor if justification is required. Forgive me if this has been covered before, but I've been unable to find anything in any specs about it. Tim
Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification
On 7 April 2011 18:36, Aryeh Gregor simetrical+...@gmail.com wrote: On Wed, Apr 6, 2011 at 7:40 PM, Tim Down timd...@gmail.com wrote: Is there an overwhelming reason why execCommand() should be restricted to contentEditable/designMode elements, as the spec seems to suggest? IIRC from testing, that's how all browsers but IE9 behave. I guess the reason is that if you have a typical WYSIWYG editor, which has non-editable stuff surrounding it, and the user has selected some non-editable stuff on the page and clicks the bold button, you don't want the non-editable stuff to be bolded -- the button should only affect the editable area. Also, in a typical case, you're letting the user edit so that the markup will be saved or submitted to a server, and the markup that you'll save or submit is probably only the editable stuff. So if you do something like push down styles from outside the editable area, that change will not only unexpectedly affect the appearance of the non-editable part of the page, the change might not get saved. Of course, this makes it less convenient to use the commands for non-editing purposes, but they're mostly not very useful for that anyway. Do you have particular use-cases for using execCommand() outside of contentEditable/designMode? I'll probably put off tackling details like this until a much later date, once I've specified the algorithms themselves to a satisfactory extent. I don't recall ever wanting to use execCommand() in non-editable content myself (although I wouldn't rule it out), but I've answered a few questions on Stack Overflow where the asker has wanted to highlight (i.e. change the background colour of) the current selection. I've suggested temporarily putting the document into designMode, calling execCommand() with HiliteColor / BackColor and turning designMode off again. Here's an example of someone wanting to do this for a bookmarklet: http://stackoverflow.com/questions/3223682/change-css-of-selected-text-using-javascript I found about five others that were not so specific about why they wanted it, but all wanted to highlight the selected text using a background colour. One more example: http://stackoverflow.com/questions/1622629/javascript-highlight-selected-range-button Tim
Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification
Is there an overwhelming reason why execCommand() should be restricted to contentEditable/designMode elements, as the spec seems to suggest? Tim On 1 March 2011 18:36, Aryeh Gregor simetrical+...@gmail.com wrote: Two or three weeks ago I began writing a specification for execCommand() and related functions. I don't have anything implementable yet -- it's very incomplete and there are known issues with the existing stuff. But I thought I'd post it for any early review comments on the direction I'm taking, particularly from implementers but also from anyone else familiar with the APIs (e.g., someone who's used them in practice): http://aryeh.name/gitweb.cgi?p=editcommands;a=blob_plain;f=editcommands.html;hb=HEAD The plan is that this should be merged into the main HTML spec, with a full test suite, by the end of August. Feedback appreciated.
Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification
On 18 March 2011 00:43, Aryeh Gregor simetrical+...@gmail.com wrote: On Thu, Mar 17, 2011 at 6:45 PM, Tim Down timd...@gmail.com wrote: I'm interested in this stuff and am very grateful for your work. I've been writing a document.execCommand() replacement for my Rangy library (http://code.google.com/p/rangy/), so this is all extremely relevant for me. In the course of writing the spec, I'm also writing an implementation in JavaScript to make sure it's sane and produces expected results. I'm not making any effort to have it work in browsers other than the most recent -- getting it to work in IE 9 might be a significant hassle -- but in a few months it should be a quite complete execCommand() implementation, maybe suitable for use in a JavaScript library if someone wants to make it work in old browsers. I'm doing something similar for the DOM Range tests I'm writing. For instance, I've written JavaScript implementations of deleteContents(), cloneContents(), and extractContents() to match my spec text, which in turn closely matches browsers. You can take a look here: https://bitbucket.org/ms2ger/dom-range/src/tip/test/ If you're writing your library based on the W3C's DOM Level 2 Range spec, you might not want to. The DOM Range spec at html5.org might be a better reference, if it defines the functionality you're looking for: http://html5.org/specs/dom-range.html It should be much easier to implement, since it's written algorithmically in the style of HTML5 (my implementations just follow the spec line-by-line). It also has more features and more closely matches how browsers actually work, and it defines Selection too. All of my spec-related code (tests, implementations, etc.) is in the public domain. The core stuff for my library (DOM Range and Selection for all browsers, including IE 9) is already done. The Range part follows the DOM Level 2 Range spec (apart from the parts about the effect of DOM mutation on existing Ranges, which I didn't implement), since your new algorithm-based spec didn't exist at the time (August-October 2010). The Selection part imitates what I considered the most useful common ground between Mozilla and WebKit Selection objects with only a little influence from the Selection section in the HTML5 spec (which is where it was at the time) since it had a number of issues that I discovered and raised bugs for while writing the selection code (backwards selections, extend(), toString()). I have been following your progress fairly carefully and am aware of the extra features in your spec, some of which may have originated from my requests. There is a lot of useful stuff in your code, spec and tests that I intend to look at to verify and likely improve my code. Thanks for all your work. Tim Tim
Re: [whatwg] HTML-to-plaintext conversion (innerText and Selection.toString())
On 4 February 2011 01:25, Aryeh Gregor simetrical+...@gmail.com wrote: On Thu, Feb 3, 2011 at 4:41 PM, Boris Zbarsky bzbar...@mit.edu wrote: And all I'm saying is that there are at least three pieces of data here: 1) innerText return value 2) Selection.toString() return value 3) What the browser actually copies My point is that browsers must be free to modify #3 as desired. Dictating it in a web spec, is not acceptable, imo. Sure. Agreed, I think; but should that be Selection.toString() or some other API? That is are we hijacking Selection.toString() because it's convenient, or because it's the right way to expose such an algorithm? innerText seems like a reasonable place to put such an API, if only because WebKit already does it. It's not ideal a priori, but by the consistency standards of the web platform it's not noticeably bad. I should particularly point out that your typical author is not going to have the foggiest notion of separation of DOM and CSS and so on -- it will make intuitive sense to authors to have it at innerText as much as anywhere. I did actually find a couple of sites that defined functions that accepted an HTML string, created a div, assigned the HTML to the div's innerHTML, and returned the innerText (or textContent if innerText is unavailable): http://api.opencast.naver.com/CS888/23 http://bbs.ptbus.com/thread-22143-1-1.html I didn't find what they were actually used for, though. Note that this breaks if innerText doesn't work correctly for non-displayed elements, so basically it will only do any prettification in IE. Depending on your definition of okay, yes. I mean... we have an okay way that's interoperable now (I hope): Range.toString. Except you don't think it does an okay job, clearly. I agree on that; I don't necessarily agree that current browser Selection.toString does an okay job. Actually, if browsers are willing to converge on making innerText work like textContent and Selection.toString() work like Range.toString(), I'd be okay with that. There are use-cases for a standardized plaintext conversion API, but at this point I think they're too marginal to be worth the effort of actually specifying and implementing. Such an API is inherently going to be either not very good or unreasonably complicated. There's no reason at all that you couldn't implement such an API in a JavaScript library -- I don't see why it has to be part of the web platform. I've been told Opera doesn't care about this and will implement whatever is specced as long as it's web-compatible and not too complicated to be worth the effort. Gecko (at least that portion that I'm talking to :) ) seems to be skeptical of implementing anything very complicated here either. But Maciej has told me that WebKit doesn't want to scrap its elaborate plaintext-conversion APIs (which have by far the best fidelity of any browser's from what I see). So as I see it, the easiest solution would be for WebKit to agree to move its APIs to prefixed versions if it wants to keep them, and change behavior of the unprefixed ones to something like textContent. (Possibly with minimal differences for web-compat -- Opera's behave slightly differently, and IIRC I was told it's for web-compat reasons.) On the other hand, if WebKit is unwilling to accept anything other than a complicated plaintext conversion algorithm here, I don't think we're going to have interop in the foreseeable future no matter what. Even if it gets specced, no one will want to implement it. I'm not clear on whether WebKit would be willing to implement a standardized algorithm either, given the nonexistent web-compat issues. So in that case I'd try to ask Microsoft, and unless they side with WebKit, we can at least have everyone but WebKit converge on innerText/Selection.toString() behaving as similarly to textContent/Range.toString() as possible. How does that sound to everyone? It sounds less than ideal to me. From the perspective of web developer, that removes useful functionality. I'm not too bothered about innerText, but it's not hard to come up with use cases for an implementation of Selection.toString that returns the text that is visually selected on the screen rather than the trivial concatenation of calling toString on its Ranges. For example, a bookmarklet to search the web for the text the user has selected in the current page, or a tooltip that show content relating to the current selected text. I don't think it's necessary to have perfect interoperability for this to be useful: the current situation is not that bad, although IE9 worsens it since it implements the Range-toString-concatenation approach that is in the current spec and is now being suggested again. I also suspect that use of Selection.toString is fairly widespread and browsers changing their implementation to this could break a lot of pages. Tim
Re: [whatwg] Control over selection direction
On 4 February 2011 11:07, Marijn Haverbeke mari...@gmail.com wrote: See below for a revised proposal, based on the discussion here. To move this forward, I understand I must get some people to implement it. I'll probably eventually get to submitting a Firefox patch. If anyone reading this list knows the people who'd be able to make this happen on other browsers, please point them at it. - element.selectionDirection [= value] Returns either forward or backward, indicating which side of the selection is anchored. For forward it is the top, for backward the bottom. Can be set to one of these strings to change the side of the selection that counts as the anchor. [...] The selectionDirection attribute must, on getting, return one of the strings forward or backward. backward is returned when the anchor, the fixed end, of the selection lies after the base, the movable end. forward is returned in all other cases. When set to forward when its current value is backward, or set to backward when its current value is forward, it must flip the roles of the ends of the selection, so that what used to be the anchor now becomes the base. When set to any other value, this is ignored. I still prefer a Boolean (and therefore a change of name to selectionBackwards or similar). I see no gain from using a string. Otherwise, this seems like the best solution. Tim
Re: [whatwg] Request for implementer feedback: granularity definitions for Selection.modify()
It seems to me like there's an additional complication: presumably Selection.modify() acts on only the text that is visible to the user, which lands you with the problem of first specifying what that text is. This is similar to the problem presented by specifying the toString() method of Selection (which needs revisiting: see http://www.w3.org/Bugs/Public/show_bug.cgi?id=10583), or the innerText property of elements. Tim On 30 January 2011 21:33, Aryeh Gregor simetrical+...@gmail.com wrote: I'm working on a definition of Selection.modify(), and have run into the problem of how to define the various granularities used there. (See https://developer.mozilla.org/en/DOM/selection/modify for basic docs.) The intent of the API is clearly that, e.g., selection.modify(move, right, character) should do something like hitting the right arrow key, selection.modify(extend, right, line) should be like Shift+Down, etc. But this is platform-specific in practice -- e.g., Ctrl+Left and Ctrl+Right use different definitions of word boundaries in different programs I use. To what degree should I try to define how these granularities work? I could go ahead and say that moving by characters should be done by moving to the next grapheme cluster boundary as defined by UAX#29, for example. Or I could say that it should follow platform conventions for when the user advances by a character, e.g., using the right and left arrow keys. Or maybe something else? What would implementers prefer? In practice, in other places where this stuff is needed (like line-breaking or :first-letter), we just leave it entirely undefined, which doesn't seem ideal but perhaps isn't fully avoidable.
Re: [whatwg] Request for implementer feedback: multiple Ranges per Selection
On 28 January 2011 16:53, Ryosuke Niwa rn...@webkit.org wrote: On Fri, Jan 28, 2011 at 7:59 AM, Aryeh Gregor simetrical+...@gmail.comsimetrical%2b...@gmail.com wrote: 2) Have WebKit or Opera run into any websites that depend on being able to use multiple Ranges per Selection? As far as I know, there is no bug filed against this, which seems to imply that we haven't had significant issues. 3) Are WebKit or Opera planning to add support for multiple Ranges per Selection? (I'd be interested in IE too, clearly, but they don't read this list.) Not anytime soon as far as I'm concerned. We do have a comment in the code indicating there had been a plan, but I don't think anyone is actively working on it. Because we haven't had much complaints from users and developers and supporting it requires so much work, I personally think it's not worth the effort. At the risk of misusing this platform, I would venture that WebKit has more pressing issues with Selections (for example, not being able to place the caret at the start of a text node). Tim
Re: [whatwg] Control over selection direction
On 14 January 2011 10:16, Marijn Haverbeke mari...@gmail.com wrote:
Another relevant precedent is window.getSelection().modify (Webkit and
Gecko-2 specific), which uses the strings forward and backward to
specify the direction in which to alter the selection. English is not
my native language, and I'm not sure what the semantic difference
between forward and forwards is, but I do expect people to
misremember which one we end up using, and use the other one. Would it
make sense to accept both the with-s and the without-s versions, or is
that kind of do-what-mean stuff not HTML5-style?
(This .modify method can, by the way, already be used, on the browsers
that support it, to create reversed selections by setting a collapsed
selection at the end of the desired selection, and then calling
getSelection().modify(extend, backward, character) X times to
adjust the start to the desired point. This is, unfortunately,
horribly slow, and quite clunky.)
If you don't need the TextRange-like character-based modification, you
can instead use the selection's extend() method (supported in Mozilla,
WebKit and Opera for years) to create a backwards selection:
function selectRangeBackwards(range) {
var sel = window.getSelection();
var endRange = range.cloneRange();
endRange.collapse(false);
sel.addRange(endRange);
sel.extend(range.startContainer, range.startOffset);
}
Tim
Re: [whatwg] Control over selection direction
On 14 January 2011 11:33, Marijn Haverbeke mari...@gmail.com wrote: If you don't need the TextRange-like character-based modification, you can instead use the selection's extend() method (supported in Mozilla, WebKit and Opera for years) to create a backwards selection: Maybe that is what you meant by this not working for TextRange-like things, but, unfortunately, the regular selection primitives do not appear to treat the content of text input and textarea elements as separate elements. I can use this trick to create a reversed selection that starts at the start of the textarea, but not one starting at an arbitrary character. I'm sorry, I thought you were referring to regular selections as opposed to inputs or textareas, since you mentioned window.getSelection(). It hadn't occurred to me to use modify() to try and affect the selection in a textarea. Tim
Re: [whatwg] Control over selection direction
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 string property. That seems to introduce the problem of having this integer match up with one of the ends. It's not a big problem, you could just ignore values that don't correspond to an end, but it seems to add unnecessary conceptual noise, since this is simply a two-valued piece of state. I don't think strings are all that awkward, but I guess that's a taste thing. Fair enough, I think you may be right. Given that this is a binary property of the selection state, how about a a Boolean `selectionBackwards` property? Tim
Re: [whatwg] Control over selection direction
I completely agree, and have been lobbying for similar functionality for the main document selection object, resulting in the current ongoing discussion in this bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10624. 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. Tim On 12 January 2011 19:35, Marijn Haverbeke mari...@gmail.com wrote: Hi, I'd like to propose a minor addition to 4.10.20 APIs for the text field selections. When programmatically setting the selection of a text input, it is currently impossible to create a range with the 'anchor' at the bottom and the 'base' at the top. Concretely, this means that, after a selection has been set by a program, if the user presses shift and moves the cursor, it is always the bottom of the selection that is moved. When doing heavy scripting on such input element, it is often necessary to restore a previous selection exactly as the user made it. This is currently not possible, and I'd say the HTML5 standard is our only hope of finally getting something like this widely implemented. The most obvious way to handle this would be to allow selectionStart to be greater than selectionEnd. This is, however, unacceptable for various reasons -- it's not easily feature-detectable, it breaks older code that reads these properties and expects start to never be greater than end, and it makes the names more confusing than they have to be. 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 shift-movement modifies the bottom, whereas botton means the inverse, with movement modifying the top. (I think the top/bottom terminology shouldn't break with any languages that order characters differently. Does anyone write bottom to top? If someone sees a problem, we could choose other terms, but these are the most obvious I could come up with.) So, in standard-ese: - element.selectionAnchor [= value] Returns either top or bottom, indicating the side of the selection that is anchored. Can be set to change the side of the selection that counts as the anchor. [...] The selectionAnchor attribute must, on getting, return one of the strings top or bottom. bottom is returned when the anchor, the fixed end, of the selection lies before the base, the movable end. top is returned in all other cases. When set to top when its current value is bottom, or set to bottom when its current value is top, is must flip the roles of the ends of the selection, so that what used to be the anchor now becomes the base. When set to any other value, this is ignored. -- Let me know what you think. Best, Marijn Haverbeke
[whatwg] HTML5 7.6.1 Selection problems
I am concerned about some aspects of section 7.6.1 in the HTML5 specification, relating to Selection objects. My main concern is that some parts do not match current browser behaviour, in particular relating to backwards selections (i.e. where the focus point comes before the anchor point within the document). Current browsers, unlike the HTML5 spec, allow both detection and creation of backwards selections. Detection is via the anchorNode, anchorOffset, focusNode and focusOffset properties. The selection focus may be at a point in the document prior to the selection anchor, meaning that the selection is backwards. In the HTML5 spec, the selection focus must always be the same or after the anchor in the document (http://www.w3.org/Bugs/Public/show_bug.cgi?id=10624). Creation is via the expand method: it's possible to create a Range and add it to the selection (making the selection anchor equal to the start of the Range) and use the expand() method to move the selection focus to any point in the document, including a point before the selection anchor. HTML5 does not specify the expand() method (http://www.w3.org/Bugs/Public/show_bug.cgi?id=10691). It seems to me that it's important to be able create and manipulate backwards selections: browsers already do it and it's useful within the context of an editable element or document. An unrelated issue is in the toString() method of Selection objects. In HTML5, this takes a simplistic approach of concatenating the results of calling toString() on each Range within the selection. This is unfortunately not how any browser implements it or ever has: toString() in Mozilla, WebKit and Opera returns only the text within the selection that is visible to the user, omitting, for example, text nodes within elements hidden by CSS properties such as display and text nodes within script elements (http://www.w3.org/Bugs/Public/show_bug.cgi?id=10583). The behaviour is somewhat similar to that of an element's innerText property as implemented in IE or WebKit. In summary, the changes I'd like to see in section 7.6.1 of the HTML5 spec: 1. Change the specification of anchorNode, anchorOffset, focusNode and focusOffset to be dependent on the direction of the selection but still match either the start or end of the last range in the selection; 2. Add the expand() method of Selection objects, matching current browser behaviour; 3. Change the specification of the toString() method of Selection objects to match current browser behaviour. Tim Down
