Certain characters, most notable all apostrophes, are showing up as question marks (?) in my website for certain users. Normally I'd say "easy, that's a UTF-8 char encoding problem".
But here's what's odd -- the issue only appears for a few international users. On American computers the site appears 100% fine. There is no explicit internationalization being done on the site; everyone gets the same content.
I have the usual headers and meta in place:
in header:
Content-Type: text/html;charset=UTF-8
in html:
<head><meta charset="utf-8"/></head>
The content is coming via
Unix file system -> SOLR -> Spring Boot -> Apache
Any ideas why the same page appears differently for certain international users? My best guess is that perhaps the content is not really UTF-8 encoded and that some browsers are better than others at failing gracefully? As far as I can ascertain though the content truly is UTF-8 -- I ran tests against the raw data from the filesystem according to this
How can I be sure of the file encoding?
Even among international users though, one user has the issue on Chrome while another's Chrome is fine but only sees the problem on Safari. (Chrome and Safari are both 100% fine for me). I've personally verified that the problem does exist on their computers, but cannot reproduce it on my own. Coincidentally both verified cases are using Mac-family products (a macbook and an ipad), dunno if that's significant.
Related
A website that I am working on is loading slow in IE for certain users. It is loading OK in other browsers but not IE.
The site is http://tinyurl.com/ctzxlv8.
Any help/suggestions are much appreciated.
A common problem with browsers is that not all run same syntax same way. Of course, there is a standard html, but each browser tries to extend syntax in order to be able to run more webs... browsers developers think: more flexibility -> more webs reproducible -> more users.
But this can be a trap for web developers when you are using just one browser to check if your web runs. For instance: I use a lot firefox, but it accepts a lot more syntax than just the standard one. It could run my code perfectly, but IExplorer could have some problems trying to understand my non standard code.
All I want to say is, check your html syntax on a validator. Your site has 65 Errors, 124 warning(s). Fix them to a standard code, will probably help ;-).
I'm working on a large website that has hundreds of pages with headers, footers, pop-ups w/ iframes, buttons, logos, etc all over it.
It's been developed for several years. The entire time there have been no DOCTYPE tags, so all the code that has been written for it has been written against quirks mode.
Here is my question:
What are the likely issues to run into if switching the whole thing to non-quirks mode?
Are there going to be so many issues that it isn't worth it to switch?
You should go and try it. Make a test installation and test it.
I did the same thing lately and there were some problems. Most of time I had no big problems, but sometimes it is really very hard to fix everything, because standard mode simply doesn't support some weird behaviour of qwirks mode. But I am happy to have the conversion done. Also those pages didn't look the same in all browsers, because qwirks isn't 100% same everywhere.
As I have been learning, I have developed a bad habit of only doing things in chrome. More recently I have started looking at stuff I make in other browsers; it sucks. I have noticed that the positioning in firefox is a little different, safari is basically the same, and IE is a hot mess. For now I am just going to focus on getting things to work correctly in firefox. Is there a sort of if Firefox conditional statement?
There is no equivalent to IE Conditional Comments in Mozilla based browsers like Firefox.
Depending on your server-side platform (if any), you could elect to sniff the browser type and conditionally include different style-sheets. Of course, you want to avoid this as much as possible. Usually by fixing things to work consistently across all browsers, you end up with better, more robust, site that will probably save you time in the long run.
Regarding CSS differences, you might consider starting with a reset CSS, such as the one suggested in Joe's answer, to provide a uniform baseline.
Regarding standardization of HTML and other features between the browsers, you might want to check out modernizer.
I find this script will solve a lot of quirks (minus IE of course) reset.css
When uploading a PDF file from an HTML form, the mime-type Firefox (WinXP) provides in the request header is:
Content-Type: /home/www/vesta/services/stamper/data/e5456e0699badbe373740d28eca79d09:
I've seen plenty of application/pdf and application/download, but never anything like this.
[BTW, I understand that trusting the file extension and the mime-type reported by the browser is unreliable, since it all comes from the client-side. Of course, server-side introspection methods are more reliable. But I'm still interested in this unusual browser behavior.]
Anybody ever seen something like this? Many thanks in advance.
See this Ubuntu bug report and Mozilla bug #373621.
For some reason, Firefox has been convinced (via mimeTypes.rdf) that PDF files have a different MIME type. Delete the offending entry from your mimeTypes.rdf file (in your profile directory).
Had it happen to me on a Gentoo Linux, and completely out of the blue as well, without any software updates or anything else. Two days ago I was uploading PDF files as application/pdf, today I see I am sending exactly the same weird content type as the OP.
We want to make an audio based web based app that will have many sound snippets. We want to cache these files so that performance is good and not dependent on network speed. Can HTML5 cache audio for offline mode?
It certainly seems to me that this should work, and I can't find any documentation that says it shouldn't work (either from the W3C or from vendors like Apple), but putting audio files as resources in cache manifest just doesn't seem to work with Safari on the iPad & iPhone at least.
Sounds play fine when the app is in online (although it seems to load them anew each time and not cache them) and it doesn't complain about the resources not being there when in offline mode (which is does immediately if you forget to include a JavaScript, CSS, HTML or image resource).
Instead of complaining (or loading); if the element has a control that control is replaced with a box that says "Cannot play audio file.". Alternatively, if it's an element without a control - i.e. accessed via JavaScript all to .play() - then it simply just doesn't play (it doesn't cause any errors, there is just no sound, the JavaScript otherwise continues to execute normally).
I have tested this with pretty small (<20k) files and the result is the same, so it doesn't seem to be size related, just a blanket refusal to copy. I'm not sure if you can encode sound as a resource in a page (e.g. encoded in base64) the way you can with images, but I'm going to investigate that option - I suspect that would be possible. I tried encoding audio data as data URI strings and even tried generating audio on the fly - both work fine in Safari on the desktop but do not work on the iPhone / iPad OS (at least on version 3.x - I have not tried on iOS 4, but it won't be out for a week, and is not expected for the iPad for a few months, even if they do fix it).
I would guess the refusal to cache sound files in iOS is an implementation bug or intended limited functionality. It's certainly annoying and a show stopper for a lot of use cases.
I am not sure what happens with other HTML5 clients, I'd be interested to know (in particular on Andriod). Google's support for audio hasn't been stellar either, so it may suffer from the same limitations.
You could always develop a decoding/encoding layer that talks to the client SQLlite DB
I don't see any reason why you can't specify audio files in the cache manifest.