- From: Bjartur Thorlacius <svartman95@gmail.com>
- Date: Thu, 18 Aug 2011 22:09:05 +0000
?ann fim 18.?g? 2011 21:05, skrifa?i Alfonso Mart?nez de Lizarrondo: > Now if someone had some bright idea to enable finding in the hidden text > that would be perfect, but the view source workaround is good enough for the > moment. > That seems to be of general utility. I recommend sending feature request to implementors. > That's just CSS and I'm not sure if it should be present in this spec, but > on the other side it's clear that besides the .execCommand a good Editing > spec should state or hint about other features that the browsers must > implement to behave properly (like showing the caret so the user knows where > he's typing, enable the user to select parts of the content,...). These > might look trivial, but iOS5 seems to be the first mobile browser that will > behave good enough so that both CKEditor and TinyMCE will enable the support > for it (check the comments in > http://code.google.com/p/android/issues/detail?id=8253 about the Android > browser) As long as overspecification is avoided (care must be taken to allow e.g. caret(s) to be hidden when another top-level window is focused, etc). > A browser that provides a perfect implementation of all the execCommands but > doesn't allow the user to type or select is worthless for editing. Then requiring implementations to allow users to select and replace any substring consisting of a sequence of whole characters (i.e. characters represented by a single glyph) and insert text of their own at any character boundaries seems reasonable. I don't see why mandating carets is needed. Should users not be allowed to edit editable content using structural and/or aural editors?
Received on Thursday, 18 August 2011 15:09:05 UTC