How reliable is font embedding for a very large production site and if relevant, would you do anything special to test cross browser, device, etc?
Thanks
There's nothing wrong with font-embedding as long as you ensure that it works across all browsers and under heavy load.
Always do testing on IE6+ (IE6-IE9), FireFox 3.5+, Opera, Konqueror, Google Chrome, etc. Also make sure you can view everything from a mobile such as the iPhone, HTC Desire, etc.
If you have any doubts that it won't work, then don't use it, or use it under GREAT precautions.
Just do your testing and ensure that nothing is wrong with it before you put it live.
Related
I'm working on an app on my machine and run it on local host. Sometimes browsers dev tools are not accurate and once I am making the changes in my code and then run, it doesn't look like how it was in dev tools. I'm talking about some alignment, responsiveness, not about styling, colors etc.
When I am comparing my app in different browsers it doesn't look the same in all of them, so I'm no sure which one is actually the accurate view.
I have tried Edge, Opera, Mozilla, Chrome. My company is monitoring my pc, so I can't install random stuff on it.
Is there any other option to preview accurately my app? Any extension or some site?
Thanks in advance.
You can always use other browsers like Opera which has developer mode, as well as, Microsoft Edge and Safari that offer web development tools. As for the alternatives for Firefox, I believe it was already answered, check this: What are the alternatives to the Firefox Developer Tools?
Moreover, these might not directly solve your problem but if you are looking for plugins or apps, check these useful tools out: Plunker, Percy, Ghost Inspector, Requestly.
It seems every resource regarding things like CSS3 and HTML5 nag me about particular things not being implemented in older browsers, and hacky workarounds. Really who uses IE 9 or 10 anymore anyway? IE11 is out, Edge is default on W10, and I assume most / all people use it. To me it seems to make the most sense to simply make the page render properly on the latest Chrome (what I use), Firefox, Edge, and Safari..
Ughhh apple. My understanding is that the Windows version of Safari is very outdated and trying to get a (questionably obtained) image of macOS working in a VM has been unsuccessful. I'm not spending a dime for any Apple products just to test my site on their browser. So what can I do in order to test how my site will work in it?
Regarding your question...
Who uses IE 9 or 10 anymore anyway?
Typically, people with older Windows systems. This is important for your website based on whether or not IE 9/10 users will be accessing the website that is being supported. (A review of your website's web logs can shed light on this.) If your website is an internal intranet site, then an organization's IT department may dictate the browsers that users can use. However, large eCommerce websites will often support older browsers out of fear of losing customers to rivals.
Regarding your second question...
How do I go about ensuring the site is functional and looks reasonably
good on apple products conveniently, without any apple products while
on a minimal budget?
Without actual Apple products, something that emulates these displays is needed. One option is the "Inspect" option with the Chrome browser. (Display your website on Chrome, right-click, select "Inspect".) Inspect allows you to choose between a Desktop or Mobile display. With a Mobile display, you also have the option of selecting several Apple displays (e.g. iPhone, iPad, etc.). This is probably the next best thing to having the actual Apple device and its display for website testing.
I have read several articles on feature detection and that it is more reliable than browser detection because browsers lie.
I couldn't find any information on why they lie. Does anyone know the reason why they would do that?
As far as I understand it, Webmasters do browser sniffing to find the capabilities of a browser and limit what they send to the browser. If a browser lies about it's capabilities they will receive more from the webmaster, you can read more:
http://farukat.es/journal/2011/02/499-lest-we-forget-or-how-i-learned-whats-so-bad-about-browser-sniffing
http://webaim.org/blog/user-agent-string-history/
The reason is simple:
Because web sites look at the user agent string and make assumptions about the browser, which are then invalid when the browser is updated to a new version.
This has been going on almost since the begining of the web. Browser vendors don't want their new versions to break the web, so they tweak the UA string to fool the code on existing sites.
Ultimately, if everyone used the UA string responsibly and updated their sites whenever new browser versions come out, then browsers wouldn't need to lie. But you have to admit, that's asking quite a lot.
Feature detection works better because when a new browser version comes out with that feature, the detection will pick it up automatically without the either browser needing to do anything special nor the site owner.
Of course, there are times when feature detection doesn't work perfectly -- eg maybe if a feature exists but has bugs in a particular browser. In that case, yes, you may want to do browser detection as a fall-back. But in most cases, feature detection is a much better option.
Another more modern reason is to just avoid demands to install mobile apps (where product owners contol what I can and can't do with content. No thanks!).
Today Reddit started to block viewing subreddits in case they detect a mobile browser in UserAgent so I had to change it just to be able to view content.
I'm tyring to get phonegap up and running on blackberry storm (9530 simulator). I had been testing my webapp from withing BB's built in browser, and it was looking ok, but then it totally bit once I tried to look at the some code from within phonegap, even though I was pointing phonegap to the same url (I hadn't yet gotten to the point of running code locally on the device).
I tried a test case on google and got similiar results. see below. I suspect that I'm missing something basic here. I would have expect both images to be nearly identical.
Browser
http://www.eleganttechnologies.com/outside/ImgDeviceBB9530WebGoogle.jpg
Phonegap
http://www.eleganttechnologies.com/outside/ImgDeviceBB9530PgGoogle.jpg
[Update]
To shed some light on what is happening, I ran the browser and the embedded browser (phonegap) against the W3 mobile web acid test: http://www.w3.org/2008/06/mobile-test/
I definitely notice differences between the two, but I don't yet know the 'why' and the 'how-to-address'.
Acid via built-in browser
(source: eleganttechnologies.com)
BTW - I ran this earlier today and got a couple more green square than just now.
Acid via browser embedded into phonegap
http://www.eleganttechnologies.com/outside/ImgDeviceBb9530PgAcid.jpg
Disclaimer: I don't know anything about phonegap, but have a pretty good theory. By default the embedded browser control on BlackBerry uses an older version of the rendering engine than the BlackBerry browser itself does.
At the BlackBerry developer conference last year, a talk was given about this, and there's an undocumented option to use the newer rendering engine. \
The option ID is 17000 (yes, a magic number, which could change, use at your own risk etc), and should be set to true. Not sure how you'd pass this option through phonegap (I'm not familiar with the toolkit) but using the BlackBerry APIs it's something like:
BrowserContent content;
...
content.getRenderingOptions().setProperty(RenderingOptions.CORE_OPTIONS_GUID, 17000, true);
I don't know the specifics of the browsers you are using, but I do know that most of the big sites will detect your OS + browser combination to decide what HTML to show you.
If Google is seeing a different user agent, you might get a generic mobile version of the HTML instead os the Blackberry specific HTML you get for the built in browser.
If you have access to a web server, try hitting it with both browser setups and see if there is any difference in the log file. That might tell you something interesting.
As we can see in your Acid tests...
One browser (the built-in one) is reporting correctly as a BlackBerry9530, and the other (phonegap) is not presenting the user-agent ["Testing with ."].
In this case, Google is providing you with the default view of their homepage, whereas when you are reporting yourself as a BlackBerry device, you will get the BlackBerry specific rendering.
By the sounds of things, using phonegap is removing the default user-agent (most probably because it's not recognising your device). As phonegap is open-source, the best bet is to get in there, and debug it and find out what happens with the user-agent when the http requests leave the device and track it back from there.
Maybe one browser has capabilities that another one does not?
Hm. By looking at the screenshot I would say that the second page is probably missing some resources. It may be missing some images, scripts and the CSS files, which would explain different l&f. Knowing how Blackberry Browser Field API works, I would guess that the implementation that uses the BrowserField was not done correctly. Just my guess. In addition to that, when the browser field is initialized the caller needs to configure it properly by enabling the appropriate browser features - scripts, styles etc. Again, the API is done in a very weird way, I have gotten myself into this trap once. When setting the options, you cannot just create one mask (like CSS | WML | SCRIPT) and make one call. Options are numeric and, I believe, non-overlapping - but you still need to call the API for setting each option independently.
Also the way asynchronous loading of the resources for BrowserField takes time to understand.
Just my $0.02.
When you are working on a new website, what combinations of browsers and operating systems do you target, and at what priorities? Do you find targeting a few specific combinations (and ignoring the rest) better than trying to strive to make them all work as intended?
Common browsers:
Firefox (1.5, 2, 3)
Internet Explorer (6, 7, 8-beta)
Opera
Chrome
Common operating systems:
Windows (XP, Vista)
Mac OSX
Linux
Unix
Mainly I just target browsers as the sites I've built don't really depend on anything OS specific. As mentioned above, YAHOO's graded browser support guide is a good starting point on determining which browsers yous should/could support. And Yahoo's User Interface library (CSS+JavaScript) helps massively in achieving this.
But when developing sites I primarily do it on Firefox2 as it has the best web developing tools (firebug + wed developer toolkit). Then I also test my sites with Opera 9.5 as it's my browser of choice for browsing. I've previously lost all hope on supporting IE6 at any reasonable level so these days I just inform my users to upgrade to IE7 which is almost capable of displaying sites similarly to FF2/3+Chrome+Opera.
FF3 and Chrome are so new at the moment that I tend to ignore them, but I must say: They're friggin fast! My javascript/css heavy sites are noticeably faster with them.
I'm doing:
Firefox 2 and up
IE 7 and up
Konquorer or Safari (or maybe now Chrome)
Yahoo's graded browser support is a good guide:
It depends on your audience. If you are heavy on tech users, you may have 50% of you users as Firefox. If you have lots of mom and dads, you will probably have 75-80% of your users being IE 6 or 7. You probably need to get a alhpa/beta out with Google analytics so you can get a measure of your audience.
Where I work, we target
Firefox 2 and 3 on Windows
Firefox 2 and 3 on Mac
Safari on Windows and Mac
IE 6 and 7
We are not specifically targeting any Linux browsers, but if they work in the list above, there's a good chance they work everywhere. We are also testing against Google's Chrome browser on Windows now.
I just figured out this week that if you bend a little and figure out how to validate your HTML you're much more likely not to have to care about cross browser stuff.
Oh yeah, except Javascript.
I get it working in Firefox first, that's what the boss uses. Opera last, that's what Bob uses. Har Har, just kidding Bob.
But even so, you can never be safe because the minutia of browser incompatibility and the fact that 90% of the people you ask can't really tell you which browser they're using.
Can you click help and about? (Pause) No? Oh, that right you're using IE7
And even that old standby doesn't work anymore.
My advice is to lock down IE, like it's a terminal server, and try navigating your website. If you can click on everything and read everything then you're in the clear.
If you use sIFR and someone calls you telling you you're logo is upside down, it's time to prioritize and worry about compatibility again, otherwise IE and FF and you're good to go.
Target none. Test against many.
Where I work, we test the following (in this order of priority, based on data from google analytics), all on Windows:
IE 7
IE 6
Firefox 3
Firefox 2
Safari 3
We don't bother with Opera or older versions of browsers since the percentage of users is very small, however we do our best to code everything to standards, so there shouldn't be any big issues.
Of course, like Milhous said, it depends on your particular audience. YMMV.
The standard suite I'm used to is:
IE6 (win)
IE7 (win)
Firefox 1.5+ (win/mac)
Safari 2+ (win/mac)
Opera 9+ (win/mac)
Chrome (so far, if it clears Safari 3.0 on win, it seems to clear Chrome, too)
You could also generically claim support for IE6/7, Gecko, and WebKit... and it covers everything listed here but Opera, plus a few not listed. It's just a lot harder to test just the rendering engine and not the specific differences in browser versions and feel comfortable with the results.
I agree you should try and make it work in all, but if it is a new site I would seriously consider dropping support for IE6. From a development perspective it will save you hours of hair pulling if you don't need to support it.
You'll have to weigh this against your intended audience and whether you are willing to lose some customers that won't be willing (or able) to upgrade their browser.