- From: Aryeh Gregor <Simetrical+w3c@gmail.com>
- Date: Sun, 16 Jan 2011 17:44:39 -0500
On Sun, Jan 16, 2011 at 3:51 PM, Ryosuke Niwa <rniwa at webkit.org> wrote: > Does it make sense to add selectionBase and selectionExtent instead of > exposing direction? ?That seems to match better with DOM selection for which > we have baseNode, baseOffset, extentNode, and extentOffset. Yes, but it's more redundant. The exposed properties would no longer be orthogonal -- changing one would have to change the others, and it's not intuitively obvious in some cases how they should change. E.g., suppose selectionAnchor == 5, selectionFocus == 8, so the selection is forward. Now I set selectionStart = 4. Does this give me selectionAnchor == 4 and selectionFocus == 8 (so it's the same as changing selectionAnchor), or does it give selectionAnchor == 8 and selectionFocus == 4 (changing direction to backwards because I extended backwards), or maybe selectionAnchor == 5 and selectionFocus == 4 (behaving like extend())? If we just have a boolean, it's unambiguous: the properties are all logically separate. We don't want to emulate the DOM selection API, IMO -- it's ridiculously complex for minimal functionality gain, even accounting for the fact that it has to deal with nodes as well as offsets. Save authors the pain, if they only have to deal with text fields.
Received on Sunday, 16 January 2011 14:44:39 UTC