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.
Related
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.
It seems the starting   was ignored in the title tag.
Demo below:
<title> pika</title>
I wondered is there a way to hack this, maybe using a foreign character which looks like a space? Any advice?
There are potential reasons for doing this. Especially if search engines isn't a consideration. In a web app, you may want to dynamically change the title for effect, for example.
In the situation I had, we wanted to flash an emoji if you moved to another tab and activity occurred on the hidden tab. Were only using Chrome and this worked for us. Getting the spacing right is still a trick.
The character is called a Mongolian space and is not strictly considered a space character for classification purposes. I found that if you lead with this, you can put whatever you want after, for example:
<title> Title</title>
No, you shouldn't format the title in any way.
It's just information to the browser, that it will display outside the page itself. Typically it's shown in the name of the browser or on the tab for the page.
Do you really think spaces is a good solution? What will happen with different screen resolutions? How spaces will behave on tabs?
Hello,
I have the website DaltonEmpire (http://daltonempire.nl, check out for yourself), and when I got home today, it showed error 500. I had made really tiny HTML changes at school via my new CodeAnywhere app, but this was not supposed to happen. After some cleaning up of my PHP, just removing whitespaces, the page loaded.
But now, the background is completely gone and there all all kinds of weird &nspb; tags between my HTML according to Chrome Developer Tools [1], which weren't there before. In my actual code, of course there's whitespace to order my HTML, but that's just spaces, no &nspb;'s, and that never happened before.
Also, the body background is not loaded [2], and the Developer Tools indicate that CSS responsible for the background is not included at all [3] (rather than overwritten or not loaded), even though it is clearly in a <style> block with the body selector [4]. Manually adding that [5][6] bit through the Developer Tools seem to fix this.
Has anyone any idea how this could happen/how this could be solved?
The strangest thing is, I did not change anything specific at all that I can recall. What has caused this?
I need my website to be fixed as fast as possible, as my visitors are students to get their educative documents and in two days is their test week.
Thanks in regard,
Isaiah van Hunen
Attachments:
Weird &nspb;'s
Background not loaded
Background CSS not included?
Background CSS is included
Adding manual Background CSS
Background loads
I can help with 1).
is a formatting entity:
it is the entity used to represent a non-breaking space. It is essentially a standard space, the primary difference being that a browser should not break
(or wrap) a line of text at the point that this occupies.
http://www.sightspecific.com/~mosh/www_faq/nbsp.html
Microsoft Word puts it into HTML files, and so do other WYSIWYG editors.
Unfortunately, CodeAnywhere seems to have the same issue.
Do you have an earlier version of the code that you can open in Notepad/Notepad++/Atom in order to add the whitespace manually there (with ` tags or the like)? That might help.
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...