<div class="gmail_quote">On Thu, Jan 5, 2012 at 4:03 PM, Ojan Vafai <span dir="ltr"><<a href="mailto:ojan@chromium.org">ojan@chromium.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="gmail_quote"><div class="im">On Thu, Jan 5, 2012 at 3:47 PM, Ryosuke Niwa <span dir="ltr"><<a href="mailto:rniwa@webkit.org" target="_blank">rniwa@webkit.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div class="gmail_quote"><div>On Thu, Jan 5, 2012 at 3:31 PM, Ojan Vafai <span dir="ltr"><<a href="mailto:ojan@chromium.org" target="_blank">ojan@chromium.org</a>></span> wrote:<br></div><div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


Selections on the web are document ordered (i.e. all the DOM between two points). So, any CSS that puts elements out of document order gives a crappy selection to the user.<div><br></div><div><div style="position:relative">foo<div style="position:absolute;left:-100px">bar</div>baz</div>.<div>







<br></div><div>If you select "foobaz", clearly no user would expect "bar" to get selected. The same problem arises with floats, negative margins, flexbox and grid ordering. I expect it's likely that CSS will continue to get more ways to put elements out of document order.</div>





</div></blockquote><div><br></div></div><div>The same behavior arises from bidirectional text as well.</div></div></blockquote><div><br></div></div><div>bidi is a different case. It has to do with user-insertion. The user inserts it in document order, so it makes sense to select it in document order. It does lead to crazy looking selections, but they are selections that make sense to bidi-users.</div>

</div></blockquote><div><br></div><div>It's essentially the same case. Author puts bidirectional text on the page and user can't select in visual order. We frequently get complaints about that. And it's one of use cases for Gecko's multi-range selection (there's an option to enable this).</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="gmail_quote"><div>That's exactly what a multi-range selection is.</div>

<div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>Does this seem technically feasible? I think we can get the APIs exposed to JS to work with this if we are willing to make the change.</div>





</div></blockquote><div><br></div></div><div>Gecko already have such an API.</div></div></blockquote><div><br></div></div><div>Sure, but Gecko only uses it for selecting table columns, right? Otherwise, selections in Gecko are document ordered and between to points in the DOM.</div>

</div></blockquote><div><br></div><div>No, user can create multi-range selection on regular text, etc...</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div>Also, once user can select such content, they'd expect to be able to copy & paste that content. In fact, the most probable reason an user selects text is to copy it.</div>



<div>

<br></div><div>However, when relatively positioned, flexbox, etc... are involved, there's virtually no way for us to ensure the pasted content will maintain the visual order. So users would get crappy experience anyways.</div>



</div></blockquote><div><br></div></div><div>It's true, but I think this is a less crappy experience. In these cases we could either try to copy in visual order or just paste out of order. It's not perfect, but it's better a better experience than selecting text that the user clearly didn't want selected.</div>

</div></blockquote><div><br></div><div>I don't think that's a good idea. For example in the case of relatively positioned blocks, those CSS properties that caused blocks to be relatively positioned will stay with the pasted content. So we may end up pasting contents that'll end up overlapping with the content at the destination.</div>

<div><br></div><div>Users can already copy all the contents, paste as text, and remove unnecessary parts. That's much superior solution in that we'll more likely to end up with the same visual ordering (because all contents will be copied), and the website or the application into which the contents was pasted will be able to deal with it appropriately.</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="gmail_quote"><div>Also, what should happen, for example, if those contents appear inside a contenteditable region and the user hits delete, paste, insert a character, etc...</div>

</div></blockquote><div><br></div></div><div>Yup. We have to handle all these cases appropriately. Copy is the only hard case IMO. Delete is implemented as deleting each sub-range individually and then collapsing the selection at the beginning of the first range. For all the other cases, you do a delete and then insert into the now collapsed selection.</div>

</div></blockquote><div><br></div><div>That's an over simplification. "Deleting" a relatively positioned block or contents inside a flexbox isn't as simple as just deleting the element. We have to make adjustments to adjacent elements, which may also be in other disjoint ranges of the same selection we're operating on. In general, I'd expect those disjoint ranges in the selection to have a very complex dependencies with each other. Dealing with the interactions of those dependencies within editing commands is extremely difficult. Ehsan (from Mozilla) can educate us on that topic.</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div><div>Is this too crazy? Are there other solutions?</div></div></blockquote><div><br></div></div><div>I'm strongly opposed to the idea of supporting multi-range selection. It's not worth the complexity and we'll never get it right.</div>



</div></blockquote><div><br></div></div><div>We'll never get it 100% right, but we can get much much closer than we do today and with the increasing number of cases that hit this, it becomes more important that we do get this right.</div>

</div></blockquote><div><br></div><div>I don't think it's worth the complexity. In my opinion, this is one of those features we shouldn't implement despite of the potential benefits.</div><div><br></div><div>
- Ryosuke</div>
<div><br></div></div>