Hi Craig, thank you for the response.
One kluge might be to set a borderless semi-transparent graphic over the field
Well, yes, I was thinking this way. But it adds a "kluge". A nice word by the way ). In German language "klug" means "witty" or "smart".
The problem is that placing a semi-transparent field or other object will not allow to use the selected text. Also, the textcolor - for example if black - will become light bluish.

- SelectedText2.JPG (8.86 KiB) Viewed 10753 times
The example field control I am showing is just doing that.
It consists of a basic field in Livecode plus a overlay rectangle.
I have put a semi-transparent rectangle with a bluish background color on top. The border lines are white creating the distinction between selection and field boundaries.
PROBLEM 1: The user can no longer select the text.
PROBLEM 2: If the text is selected then it might disappear because it will be white when the hilitecolor of the control is blue for example. So, actually, also in this case, the text must not be selected at all. But then, the user wants to do something with the chunk of text selected...
Maybe there is another solution. I have not found it yet.
Since, I believe, details of UX and component design become more and more important, there are more such property details for a field (or control in general) should be addressed.
I would also appreciate very much to see additional properties for fields, buttons and other objects where this makes sense:
- "Hilitecolor" of a chunk of text (set, get) for fields or wherever text could be hilited in response to hiliting the object
- Rounded corners (degrees) for fields, buttons, graphic objects
- Possibility to define separate left, top, right and bottom borders and theis styles/colors/line sizes
- Allowing to place images / SVG / icons into fields which then can have a margin to push the text to the side or let text flow around
Further thoughts:
- Allowing bulleted/numbered lists as styles in text fields (selecting bullet styles or defining some)
- Allowing visually to set tabs and margins (before, after, left, right) as well as the leading using a ruler or a separate control where such values could be set?
- In-built style system allowing to define styles for paragraphs of chunks of text, ... (and other objects). So, at least we could have text styles and paragraph styles? (We can develop this on our own of course.) But does it make sense when everyone has to develop his/her own style system?
- Allowing table definitions in fields (?) - well, we have table fields, but can they be styled on such level of detail as with CSS? -- and can they be part of a flow? Maybe, that may also be possible to a degree even now.
Is it possible to do? Would it soon be possible using LCB? This would just mean to be on-pair with HTML/CSS styling and probably even be a requirement for serious detailed work for UX designers?
Just it comes to my mind: Then I could really possibly see a very large number of people working with LC defining web applications which would translate to HTML/CSS. And LC code would translate to Javascript. Well, just an additional thought here. Partially it seems to be done already.
Hans-Helmut