During my tests with PC 1.1 I found a strange issue when selecting text in a box using the keyboard.
To reproduce…
create a new template
type some blind text e.g. “bar”
add a new “Positioned Box”
click into the box
enter : "foo
hold down SHIFT and press CRSR-LEFT 6 times
after 3 keystrokes, the word “foo” is selected completely - that is as desired and expected.
after the next SHIFT + CRSR-LEFT stroke, the “r” from “bar” gets hilited - hmm: the selection was extended from content of the box to something outside the box… - not what one would expect…
type “zoo” - goodbye box; the box has been deleted completely - really not wanted this.
Alright so, what it seems to be doing when you do CTRL+SHIFT+LEFT, is that it starts selecting stuff as if you were in the Source view - it will indeed select outside of the current element (whether it’s a positioned box or a paragraph or a table or anything).
While this seems to be desired behaviour within text (selecting multiple paragraphs, multiple cells, etc), it is perhaps a little weirder within positioned boxes.
I will make a feature request to attempt to disable selecting stuff “outside” of a positioned box when having a selection inside of it, but this might be a little more complex to implement than we think - it most probably won’t be changed until at least version 1.3 since the 1.2 feature set is already set in stone.
For paragraphs and tables, I can understand the behaviour. They are in the same flow of text, but a box is to me something more like a closed container with a different z-order etc.
E.g. no text just runs out of the box into the layout.
Well basically it’s the default behaviour for all elements. I’ve made a request to specifically disable this for positioned boxes.
It’s just that positioned boxes are, really, just a element with the “position: absolute;” CSS property, it’s not “outside” of the rest of the page. If you put that same div within another element that had “position: relative;”, then your div’s position would be relative to the parent element, not to the page itself.
HTML/CSS is… a little more complex than just paragraphs and floating boxes.
HTML/CSS is… a little more complex than just paragraphs and floating boxes.
Yes, this is true.
But when you are in the Design view, you shouldn’t have to care about how it is implemented.
I am sure that most of the users want to use “Positioned Boxes” the same way they do as how they are using “Textfields” in MS Word: a “Positioned Box” is a container that may contain other elements such like paragraphs, images, tables etc. The content can be formatted as usual. But there is no flow from content from “outside” into the container or vice versa; all actions made “inside” the container will have an effect “inside” only.
Furthermore, these “boxes” can have a background color, a frame etc.
Said this, the fact that a selection “leaves” the content and can be extended to include something “outside” the box is very strange.
I now understand my confusion, when clicking somewhere “outside” a box, but getting the box selected: the clicked element is identified somehow in the source; not using the current position of the mouse and the current frame of the box.
I hope your product management will think about that strategy - in the first very short training that I gave to customers (4 hours), I have seen their confusion, too: they tried to select something, but got something other hilited.
You’re correct in that there needs to be less confusion, but as I indicate I did open a ticket that will lead to this being resolved in a future version.