I want specific text (ranges/nodes) in a DOM to be highlighted (spellchecking) without inserting additional Nodes into the DOM. Unfortunately, the solutions (I found for spellchecking) that exist out there all rely on modifying the DOM (adding additional SPANs that wrap the text ranges).
Would absolute positioning of DIVs with a lower z-order than the text range that has to be highlighted (for example, black text on top of a yellow background/rectangle) work? Of course, this might be problematic whenever the window/container size changes.
Do you know of any other solutions that would work?
Related
When clicking on a result from a Google SERP, sometimes a Scroll to Text Fragment is added to the URL request, e.g. https://example.com/#:~:text=Lorem%20Ipsum, and highlights the targeted text in purple. That's pretty neat, but it break my CSS layout.
On one of my divs elsewhere on the page (not the one that gets highlighted), I'm using an absolutely-positioned :before element to add a rounded effect to the top of a 100%-wide div.
how it normally looks
The rounded pseudo-element is trimmed off of either side, since it is position: absolute, and not in the page flow. But, when there's a Scroll-to-Text Fragment added, which highlights a paragraph further up the page, for some reason the pseudo element is allowed to push the screen wider and break page layout.
how it looks if there's a scroll-to-text highlight on the page
Am I forgetting something about how CSS works, or is this a bug?
As a workaround I tried to detect this with JS window.location.hash so that I could dynamically remove my pretty rounded effect, but the Scroll to Text Fragment hash is not detected by JS (at least in Chrome). Thanks for any help.
How can one know if an element is in front of another element, if the overlaying element is transparent? The purpose for this is if you're artificially clicking a page element by its ID, and you're ensuring there's no overlay on top of the element that would make confirm the click as synthetic (as a normal user would have to click on the overlay).
Case 1: The overlay is a child of the clickable element To Detect it: Ensure there's no children of the clickable element that look unusual.
Case 2: The overlay has an absolute position and a higher z-index to overlay the clickable element
To Detect it: No clue! Unless you iterate through the bounding rectangles and z-index of every element in the DOM or go through the entire DOM looking for particular style attributes. That is expensive.
So, given the number of ways an element can be made to overlay another element, how can a user script detect elements overlaying elements? I suspect a very verbose method of going through the entire DOM could be avoided.
It turns out there's two ways to do this, and by this I mean two ways to find out if any given element is the top most element regardless of opacity.
Adapted from this blog post post and using their code (with some modifications) it's possible to see the top most element at any given mouse position. I modified their code to look for the computed style zIndex of any elements at a position. The downside to this approach is it's computationally costly in that you're looking at the positions of every element in the DOM more or less.
This stack question about checking whether an element is really visible on screen received an answer that linked to a browser method document.elementFromPoint which when given some screen coordinates returns the top most element, regardless of opacity but in accordance with its display style. It appears as though that function is supported in at least Firefox and Chrome.
In the end, there's two solutions to choose from, with the latter likely being the best solution in terms of reliability and cost.
I have a content editable element on my page and while it works somehow I'm having some problems in Google Chrome browser because it seems to sometimes wrap element into span elements with inline styles which is particularly irritating.
If I call
document.execCommand("removeFormat", false, null);
after block/paragraph conversion it does remove those spans. But there are two major problems:
It also removes italics and bold formatting within selection (although I suppose I can live with that)
It only removes formatting within selection, but if you run some block formatting (like (un)ordered list), more than just the selection gets formatted and everything outside selection still retains spans with inline styles.
You can observe this behaviour in this JSFiddle (open with Google Chrome).
What I thought I could do
So I thought I could do the following:
When I want to do some block formatting I modify selection to include whole paragraphs/text lines
Do formatting
Remove formatting in selection
Restore original selection
But I've been having problems with #4, as original selection nodes have been within those span elements that don't exist any more so I can't restore my selection.
How should I solve this one?
Problem TLDR
When you select partial line and make it as an (un)ordered list, Google Chrome inserts span elements with inline styles.
I would like to remove those irritating spans with inline styles while preserving original selection.
I have two simple textareas where in i want to highlight the javascript code being written.
As soon as the user types the function in the text area , the keywords etc have to be displayed in different color or so.
I tried to hack this script . But couldnt get what i wanted.
You could check Ace (demo) and CodeMirror (demo).
I suppose Textarea that can do syntax highlighting on the fly? and Online Code Editor questions will be useful for you as well.
I've always been interested in having textarea elements with added functionalities such as code highlighting, while still remaining as simple editable textareas. I've experimented a little bit here: http://www.dcc.uchile.cl/~jmunoz/
It's far from optimal and quite buggy, but still... It allows text highlighting using arbitrary rules. I used to have a working version which allowed to change the text color (And not just the background), but It had some issues.
Basically what I do is adding a div overlay with exactly the same content and font style as the text area but with transparent fonts. The text inside has span elements wrapping certain words and phrases which may have special backgrounds, borders, etc.
To allow for different font colors, I tried making the textarea text transparent while showing the overlay div text. The main issue there was that the cursor became transparent too.
I would say that using a div with editablecontent seems like a much better option.
I think that you can use a div or section tag with content editable attribute. Inside this div or section you can use an additional markup for higlight functions, vars and etc. But this attribute work only in new browsers that support html5 attribute content editable. Here is a demo
If you need a simple js highligter, may be this one https://github.com/cloudhead/hijs is usefull for your task
Because a text area cannot contain markup, you cant so highlighting per se. The approach I used for an inline spell checker was to overlay divs for words that were spelled incorrectly. This was possible because it was possible to get the x and y location of words inside the text.
However it may be preferable to overlay the textarea with a content editable div which would allow you to wrap content in spans etc and then apply styling.
I have a justified text node into which I want to insert an inline placeholder ( element if you like) whose only content is a "" that shouldn't have any width (and chrome inspector says as much too). I have noticed that when I insert this node inline into the text node, the whole line "jiggles" as if recalculating the layout, although this should not affect it.
I have also tested that if the text node I insert it into is left-aligned, this slight movement does not happen. Is this just inherent to the way the browser calculates text placement in a justified text element or could there be any workaround for this?
As I suspected, the issue, rather no issue, is due to the way "justify" works. First to confirm that "justify" text-align is causing this, check the jsffidle : http://jsfiddle.net/e7Ne2/29/
Both divs are same -> except that First div has text-align: justify and the other does not.
You will see that first div shows that behaviour but not second div.
This is because "justify" works this way (from wiki):
In justified text, the spaces between words, and, to a lesser extent, between glyphs or letters (kerning), are stretched or sometimes compressed in order to make the text align with both the left and right margins.
So, when we introduct a &zwb;, the text gets reorganized. This behaviour not consistent because not all characters are modified with &zwb;. So, when &zwb; alters the text, few letters "may be" stretched/compressed leading to the seemingly weird behaviour
The best I can find on it is that support for the zwj is not complete in all browsers. Your code is taking the inserted span tag and removing it with that .text() call, so it's unwrapping the zwj and causing display issues wherever it lands between letters.
I'm not sure what the end application is supposed to be, but using the jQuery .html() function would probably be better (you'll just need to check and make sure you're not writing inside of a tag), because the .text() function strips tags.
Reference:
http://api.jquery.com/text/