In Chrome, I can't select the contenteditable text context by using the keyboard in Chrome when the text contains a long string that wraps to the next line.
This repro's in Chrome (latest; Chrome 47 at the time of my writing this).
Repro steps
Click to place the cursor at the end of the contentedtable div (in the snippet below).
Hold shift and hit the up arrow a bunch of times.
Expected: All text becomes selected.
Observed: The text before the space ("foo") is never selected.
Here's the code. NOTE the character after "foo" is a space, not a newline!
<div contenteditable="true" style="background: #ddd; width: 200px; height: 100px;">foo asdfjkl;asdfjkl;asdfjkl;asdfjkl;asdfjkl;asdfjkl;asdfjkl;</div>
Actually, that's the correct behavior of textboxes in general.
In this case, you see the two words in different lines because the second one is wider than the container, so you see a line break and you try to use the up arrow to select "foo".
But, as you say in the question, after "foo" there is a space character, so you must use the left arrow to select it.
Just imagine the same case but with a full width textbox, you would only try to use the left arrow. Only the style changes here, not the behavior for that specific content.
Related
Weather.com is the only example I know of that is doing this, showing a dashed red line under misspelled text instead of squiggles. This is on Chrome in Windows 7
What I'd like to replicate
Any ideas on how this is done? Unfortunately going to inspector clears text from the field.
What most sites show
This turns out to not be a style, but rather an effect of a precisely sized text box/precisely tuned line height. The squiggle is 2px tall, but the bottom 1px was cut off, giving it the appearance of a dashed line, but in fact it is not.
This method can be used to replicate the effect shown IF you are using a font where the letters that extend below the baseline don't go so far down that they touch the spellcheck squiggle.
It seems possible to move the squiggle independently of the text, which could possibly present a way to do emulate this style with any font.
If I find a way to do this, I will update further.
This is a browser feature that can be achieved (at least in Webkit/Blink) on input fields and contentEditable elements with spellcheck="true". Not every browser will implement it the same way. For that, you would have to build the text markers yourself in conjunction with a dictionary service (like Google Docs does, as one example).
https://jsfiddle.net/bn7pfyf3/
(change the "true"s to "false"s and you won't see any highlights on focus)
In Webkit/Blink, this is a DocumentMarker type (which is used for Ctrl+F, highlights, typos in input fields, and more). They are not exposed in the DOM or CSS.
https://github.com/crosswalk-project/blink-crosswalk/blob/master/Source/core/dom/DocumentMarker.h
I work in a research project, and we have a python script that generates html texts that have a number of words highlighted. I would like to make the position of these highlighted words in the texts visible on the scroll bar. One way we could do this is by adding a special character (e.g. "$") after each of the marked words, and then run a search on this character.
We would like this character to be invisible, in order not to mess up the text visually.
I tried making a span class named "hidden", with font size 0. This does the job of hiding the $ sign, but Chrome search suddenly does not indicate the location on the scroll bar anymore. The search box still shows there are 57 results for "$", but the scroll bar highlights are gone, and clicking the "up" and "down" buttons does not bring me to the location of the next result.
I also tried inserting invisible commas (ampersandic;) in the text, but did not manage to search for these.
Other solutions, anyone?
Thanks a lot!
You can use opacity: 0 which will visually hide the element but it will not remove the space of character.
To minimise the space you can decrease the font size to the minimum like font-size: 1px
I have a select list in IE 8 it works ok.
On Firefox 3 and 4: I cannot click on the select box, unless I move the mouse 0.5cm below the actual select box.
On Webkit the same as firefox, plus by default it looks blank with no options in it until clicked?
The page is http://gocruising.com.au/Cruises/Search the select list is on the right "sort results by"
I know there must be some invalid HTML somewhere but I cannot see it.
Your <div class="icons">...</div> is hanging down, meaning the click events on the control are really click the the div.
You may need to make that div smaller, reposition it, or lift the select above using z-index.
I have a div element containing some text. When the user clicks a word inside that div I'd like to highlight just that word.
In order to do this I need to know what character position in the text the click occurred at, so I can then locate nearby whitespace and insert some formatting around the word.
Finding out where the click occurred within the text is the trick here. Is that kind of thing possible?
If your page is auto-generated, you might consider pre-processing the page by putting a <span class = 'word'> around every word in every selectable div. You might be able to this with javascript after the fact, and I think that would be your solution regardless, but pre-processing would make it easier.
The problem with relying on the absolute position of the word is that users can scale their fonts, which makes this task especially hard. By wrapping a span around every individual word, you can easily select which word was clicked by applying the click event to the span elements.
I've got a problem with textarea's in Google Chrome. I'm using classic ASP, but this is unimportant as Chrome is actually posting the data incorrectly.
The problem is with a text area. As soon as a string of text is too long to fit one line of the text area, it wraps to the next line (as it should).
My problem is that when submitted, the form data contains a CarriageReturn & LineFeed at every spot where the text wrapped, as well as user generated enter/return events - I can't even tell the difference between the two.
Does anyone know how to fix this? Possibly an option in the text area or something? All other browsers only add CarriageReturns and LineFeeds where the end user has actually put them in.
This should only happen if you set the wrap="hard" attribute on the textarea.
Do you have wrap="hard" set on the textarea ? If so, remove it. If not, can you try setting wrap="soft" as attribute?