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/
Related
I'm trying to disable text ellipsis ('...' at the end of text) / overflow-wrap so as to be able to read the full text of the option element within the select element. At the moment the text is getting cut off even though there's plenty of white space left. The catch is that I have to do this using Greasemonkey (not written any code so far), just editing in browser console till I find the correct css option. Things I've tried so far:
changing an option/select width to "100%".
changing option/select line-height to "normal"
changing option/select padding to "0"
changing option/select font-size to something smaller.
setting option/select text-overflow to "clip"
setting option/select white-space to "normal"
var menu = document.querySelector('select');
var option = document.querySelector('select option[value="neteng-deployment-agg-pod1-dub-primary"]');
I'll also attach an image to help explain what I mean:
I am not sure but looks like IE problem.
First of all check the same page with Firefox and Google Chrome.
My gut feeling that this is quite browser default specific, and that it would require browser-specific css hacks to change this, can you confirm if this is the same behaviour in all browsers on your machine?
edit: with knowledge that is same in all browsers:
there's a good chance replacing the default select element with some fancy jquery versions that replace select elements with mirror versions using normal html markup may solve it
https://sitepoint.com/13-jquery-selectboxdrop-down-plugins
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?
Intro
I'm using tinyMCE to edit markup style syntax (TeX-like equations). To denote places where processing will be required after the content is submitted from tinyMCE, I am adding span elements to allow custom CSS to highlight the markup and attach id attributes to it. I'm having some difficulty getting sensible caret positioning behaviour when moving between the span and the enclosing paragraph - often the caret will skip a character when moving from the beginning of the span to outside the span.
A concrete example
(I'm running Firefox 12 on a MacBook)
test.html: http://pastebin.com/m8nAmetz
CSS styling for eqn and inline classes: http://pastebin.com/cQVRGVMS
Pressing the right arrow with the caret positioned before the CSS rendered '$' into the span results in the caret moving to after the first m in 'moreinterestingeqnstuff', and the same process repeated after the second f in '...stuff' results in the caret skipping the first space after the span. Clicking to select caret position briefly positions the caret correctly, before it is pushed into one of the above error states.
The questions
Have I done something wrong here? If not, does anyone know if this is a tinyMCE bug or a browser bug and if a workaround exists in either of these cases?
Update: OK, I guess I'll have to enter handling pseudo elements (see below) as a feature request with the tinyMCE folks. However, even without the pseudo-elements, I have an issue with the caret handling. In this fiddle http://fiddle.tinymce.com/EGbaab I have removed the inline class, which removes the before and after styling. If I want to insert a character directly after the span, I can't, as moving the caret to immediately after the last f in '...stuff' immediately places it inside the span. Is there a way to disable this feature in tinyMCE, or alternatively what's the best way to implement this behaviour?
Hmm, you have not done anything wrong here, but you need to know that the movement of the caret does not take care of css pseudo elements like after and before. They are used here. So this is obviuos not a bug.
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 am making an application where tags can be added to posts, much like stackoverflow's tagging system. I want to display a list of all common tags, each in a little box that fits the tag perfectly (like the <input type="submit"> tag stretches to fit the size of the word). How can I do this and have the <div>s align themselves horizontally with text-wrapping in their containing div? I.e. something like this, where each word has <div id="tag">:
tag1 thisisalongtag
biology physics
thiswordwraps science
one two three four
The easiest solution is to style the tag elements with display: inline-block, which allows text-wrapping while preventing margin-collapsing.
DEMO
display:inline-block
doesn't work on all browsers (older IEs... including 7)
try this instead:
http://jsfiddle.net/mtwDX/
tags are inline but with white-space:nowrap; and a proper line-height set
hope this helps
I'm not sure that I completely understand your question but there are different ways to achieve this "tag" effect.
You could set the div's to float:left, clear:left and give it a little padding (5px on all sides). Then put all of your tags in a fixed-width container and they should tile themselves horizontally until they run out of room, at which point they will wrap down to the next "line" below.
An even simpler way is to just use inline elements, such as anchor tags, which are being used on this site (stackoverflow). The elements naturally flow horizontally until they run out of room and then wrap. If you inspect them you'll see there is not much to their styles. And they are behaving the way an inline element is expected to behave.
Sometimes the solution is simpler than you think. You might not need to bother with div's or floating. But without more information it's hard to say exactly what will work for you.