I resently found out that in chrome you can highlight text in the link. This can be done by adding #:~:text= to the link. Example: This link does not highlight anything while This link highlights my chosen context. Since I discoverd this I'm using it all the time for showing somthing to a colleague.
My question is what is the browser suport for this? And if I try to highlight a whole paragraph it doesn't work, so what is the limmit?
I searched for a while without anny sucess.
Edit
After long trying i found that there is not a spesivic limit to this. It stops at a dot F.E. This is will work. and if i go farther like This won't bequse the text im searching goes trough after the first dot!
Edit 2
Having another look at the documentation I saw that you can add a begin and end preifelx. When useed you can select a whole paragraph like This.
[For ongoing detailed browser support information: Scroll-To-Text Fragment support on Can I use]
Well, after some obscure googling I got this
TL;DR - it's a very interesting chrome-specific feature Scroll To Text Fragment. As mentioned here there is no support in other browsers, albeit IE/Edge is in "public support" state (as they say, it used to be in IE5). Documentation is here, and I don't see any size limits. Maybe the problem is in line break/begin-end paragraph special symbols handling?
UPD: other idea: there was a limit on GET-request length - 2,048 characters. Now it should be bigger, but maybe chrome still somehow cut/doesn't process too long URLs?
UPD2: The first guess is right. This link to wikipedia works, albeit this, only one character more, doesn't. The problem is in 0A/0D "carrage return/line feed" characters: if they are present in text, even encoded, highlight won't work at all. Possibly it's a bug and should be reported to Chrome, but still. Good thing for checking this is to paste selected text in Chrome "Search" tool: if it doesn't find pasted text and you see some strange characters - whoopsie.
Related
My problem can be best described by attaching these two screenshots: [1] [2]
In the second image, notice the "Continue Reading" link is rendered in sans-serif (?), and in the first image the problem is clear.
Basically, this only happens in Chrome on Windows.
So it seems like any line containing an HTML special character will have its font-family affected, and rendered in some sort of default-type fonts. I realize these custom characters may not be present in my first-choice font, but why are other characters affected as well? How can I remedy this?
If it's of any help, here's a link to my website. I'm using Ideal Sans SSm by H&FJ.
edit: It seems that my question isn't that clear after all. If you look at image [1], you can see how Chrome renders my fonts after an HTML character has been used. This is how the HTML looks like:
Especially if you’re new to OS X, this is the very first app you want to have. Holding ⌘ for a bit longer presents you with a list of active shortcuts, both global and app-specific ones. CheatSheet is also useful for existing Mac users looking to expand their shortcut vocabulary for extra effectiveness.
As seen in image [1], when this code is inserted, a different font is rendered.
Note: on my live website I currently have span tags around the special characters (that's a ⌘, by the way) in order for visitors not to suffer from this. This can actually help us with a direction towards the answer: Why is it that when the special character (any special HTML character) is wrapped in span tags, it and only it is affected by this, but when it's wrapped in span tags, the whole line is affected.
I'm observing this super weird bug on a news site maybe someone has seen before.
In the html text, if the first characters in a line of text are numerals, they are not displayed by the browser.
The html is coming through via a CMS, which forces the line breaks in the editor, but no tags are inserted. CMS data is XSLT processed into html templates.
When this text is sent to the browser, you can see the new lines are formed (without br tags), and you see that the numerals are still within the content. But these new lines are only honored by the browser if a white-space property is set using one of the "pre" values.
Seems to be related to the white space property as i can use the inspector to add white-space:pre-line/pre-wrap and boom, they appear.
Really keen to hear some thoughts on this, or could this be a possible Chrome bug?
Link to an example article here:
tvnz.co.nz/national-news/flights-cancelled-130km-h-winds-hit-wellington-5508294
In the last paragraph of that article you can read/inspect to see the missing numeral values.
So I really don't understand why this happens, but it has something to with the zoom setting... There are all kinds of articles about chrome bugs w/ the zoom setting, but none seem to address exactly what you were seeing...
If you inspect the page and change the zoom from 1 to .99999 it works... Again, I got the suggestion from this link but I'm at a loss to explain exactly what is broken w/ chrome, but it does seem like a chrome bug...
In Google Chrome, you can use shortcuts for elements with contenteditable='true':
CTRL + B : Set the highlighted text to bold, for example
What happens under the hood is, the <b> tag is attached or removed to the marked phrase, word whatever.
How is this done? Where do "they" know from, whether the element is already set to bold, and, primary question, where it is located?
I am asking this because i can't get rid of this problem, mentioned earlier today:
Get the highlighted text position in .html() and .text()
Edit:
I tried the following
Rich-Text-Editing
But first, it won't load correctly, but this should be caused by my own failure.
Second, for learning purposes, i would like to implent my own minified version.
As i am really at JavaScript, i could not figure out how this is be done.
document.getSelection() / window.getSelection() should work for whatever you'd like to do with the selected stuff.
Element styles get inherited. How this is kept track of depends on the CSS implementation.
Taking a look at the source code of Chrome might pretty much help.
I have a reoccurring problem with the Android Browser. This is a mobile website NOT a webview. Things as simple as
<li>
Some Text
</li>
<li>
Some Text
</li>
Renders fine everywhere but in Android, where between the list items I get a little rectangle, (like the character not found in this font rectangle) between them. I can only assume that in my code there is a line-break or white space character that is recognized as such everywhere but for Android. Its very annoying and I have yet to find any documentation on the subject. Occasionally I have to resort to the 'Jesus Fish' hack to get rid of it. For those who don't know this hack its an old last resort from ie6's handling of whitespace and linebreaks hack looks like this:
<li>something</li
><li>something</li
><li>something</li>
I am using intelliJ IDE if that helps. Does anyone have any idea why this occurs?
The real correct answer is...
Check your CSS rules. If you have text-rendering:optimizeLegibility then the boxes appear ONLY in Android devices.
I figured this out by chopping my CSS file in half, then half again and so on until the boxes disappeared. Having narrowed down the location in the CSS, I re-added the last bit I deleted and then I deleted rules one at a time. Eventually, I hit the offending CSS rule and narrowed it down further. So, in a nutshell, this is the correct answer.
Before View:
Offending CSS:
After Rule Removed:
There is also this bug report at Google:
http://code.google.com/p/android/issues/detail?id=15067&q=text-rendering&colspec=ID%20Type%20Status%20Owner%20Summary%20Stars
Try editing the same file (with the fix deleting ALL space between lists) on Notepad or Notepad++ and add the spacing and ident with it ane verify again, probably your IDE is adding some character.
If you have notepad++ you might want to convert it to UTF-8 using the Encoding menu, also add the charset definition to the add of the document.
I am trying to get ellipsis in Mozilla.I have found out some jquery plug in which helps to form ellipsis in Mozilla but when huge amount of data comes it does not handle well forming script error in the page.
I think actually the jquery handles each words by word which takes a lot of time to execute which is the cause of script error. Is there any simple way to show ellipsis in Mozilla or any jquery plug in which can handle large data.
[EDIT] Please note: Since I posted the original answer here, things have changed. The hack detailed below only works for Firefix version 3.x. It does not work in FF4, 5 or 6. There is no known fix for this issue in these versions of Firefox.
However the ellipsis feature is due to be included in Firefox 7, due out in a month or two, so you don't have too long to wait now, and with the auto-update feature they've now added to Firefox, most users should move to the new version soon after it's been released.
For more info on this topic see this question: text-overflow:ellipsis in Firefox 4? (and FF5)
I already noted this caveat below in the comments, but since people are still upvoting this answer, they may not reading the comments, so I am editing the answer to put it at the top here. I will leave the original answer in-tact below for reference. And it does still work in FF3.x, so it might be better than nothing.
Original answer follows:
Firefox is the only browser that doesn't (currently) support the CSS Ellipsis feature.
The good news is that this is a work-around. It's not very well known, but it does work nicely.
It works by using a bit of custom XUL which is then referenced in the stylesheet using the custom -moz-binding style declaration. (XUL is Mozilla's XML-based user-interface definition language. The whole of the Firefox UI is written using it)
Firstly, you'll need to create a file containing the XUL definition. It should look like this:
<?xml version="1.0" encoding="UTF-8"?>
<bindings xmlns="http://www.mozilla.org/xbl" xmlns:xbl="http://www.mozilla.org/xbl" xmlns:xul="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">
<binding id="ellipsis">
<content>
<xul:window>
<xul:description crop="end" xbl:inherits="value=xbl:text"><children/></xul:description>
</xul:window>
</content>
</binding>
</bindings>
Save this file as ellipsis-xbl.xml somewhere on your web server.
Then go to your stylesheet:
.myellipsiselement {
word-wrap:normal;
white-space:nowrap;
overflow:hidden;
-moz-binding:url(ellipsis-xbl.xml#ellipsis);
-o-text-overflow:ellipsis;
text-overflow:ellipsis;
}
Obviously, change the URL of the binding to wherever you've saved it on your site.
Now, firefox supports ellipsis. Yay!
There is one big caveat that you need to be aware of though: XUL is different from HTML in that HTML ignores white space, while XUL does not. Because the binding means your HTML code is effectively being treated as XUL in this instance, you will find that if you have any white space in the element being truncated, it will become visible.
This means that you will get some bizarre display problems if you have HTML like this:
<div>
some text here that needs an ellipsis
</div>
You need to move the opening and closing tags onto the same line as the text, like so:
<div>some text here that needs an ellipsis</div>
But once you've done that, this technique should work perfectly -- at least until Firefox starts supporting the normal CSS ellipsis... at which point it's anyone's guess what will happen!
We've been using this technique extensively, but credit where it's due - we learnt about it from here: http://ernstdehaan.blogspot.com/2008/10/ellipsis-in-all-modern-browsers.html