I'm looking for some feedback on this issue, i'm using Sencha Touch 2.0 to build hybrid apps packaged via PhoneGap/Cordova.
I would love to use a font to embed symbols (& get rid of resolutions issues auto-magically). I just love http://fortawesome.github.com/Font-Awesome/ for desktop & i'm wondering if it can fit in mobile apps as well.
However, I'm also trying to get the best possible perf.
Idea is to be able to use theses symbols on huge lists (>500 items). And i'm totally clueless on how theses methods (png vs. inlined-base64 vs. font) would compare.
Looks like Sencha team is using inlined-base64 over static pngs.
FontAwesome
I'm working on a project where we used to use FontAwesome and everything was working fine on iOS. But we had a big problem, it didn't work on Android and we didn't figure out how to solve this issue. So if you don't consider making your app for Android phones or if it happens to work fine for you, then I would suggest to go for it. With a webfont, like you said, you don't have to care about screen resolutions, you can change the colors and the size of the icons easily which I found quite convenient.
PNG
I guess the only problem with PNGs would be the number of HTTP request you make to get them. So the only advice I can give you is to use sprites. You could use something like Glyphicons which gives you icons pretty much like FontAwesome.
Inline Base64
The only problem with this solution is that images URIs must not be larger than 32k (according to When to consider base64 (DATA: URI) images?). It's apparently not supported by IE6/7 which I think is not an issue because Sencha only support webkit browser.
So, from my experience, go for FontAwesome if possible, otherwise sprites should always be the way to go for static images.
Hope it helped
Related
I'm starting to use phonegap and phonejs to write mobile hybrid applications. I've followed the tutorial http://phonejs.devexpress.com/Documentation/Tutorial/Getting_Started/Your_First_Application and the app works but both on the emulator and on the device the widgets are extremely small (see screenshot https://db.tt/ZhdrOt0R, sorry for the volume dialog on the screenshot). Like this, the app is completely unusable. I checked the various css files for font-size and other size tags but there are so bloody many places...
This leads me to a more generic question: I'd like buttons with rounded corners, different margins etc. What's the strategy to change the style? There are so many classes, is there any how to how to address this other than in a trial-and-error fashion?
Thx
Kai
My manager tells me not to use icon fonts on our websites, as it is another http request plus the extra kBs to download. Also because I would have to use content before for the font (I can't change the html), he prefers background images so it works in IE7.
Personally I love the little things, so nice and crisp and resizeable!
I get it if we only use a couple of icons on a website but if I would use, say 5 icons on a site - what do you guys think? Is it worth using an icon font or is he right thinking that it is not?
I am just a sucker for anything new and exciting, and this year it is the retina display.
Icon fonts and high density screens
Using icon fonts will be more and more relevant as more high resolution/density displays become available.
A 16×16px icon can look horrible on a high density display (>300ppi). It may either display incredibly small or unsharp due to automatic scaling. A 1em font icon on the other hand will render correctly and sharply regardless of screen density.
It of course all boils down to your
application users and
your requirements (IE7 seems to be the major breaker)
For now sprites are the way to go.
Downsides?
Icon fonts have a different problem as well. All icons are single colour. There's no font standard as of yet to have multi-colour capability. And it likely won't be. At least not for fonts. There are possibilities of doing multi-colour using SVG fonts which isn't a font standard/format per se but can be font container and used as a font delivery mechanism in your browser. Doing multi-colour icons as SVG fonts makes it possible to have colourful scalable icons (thanks to #Joey).
Vectorised icon images would better suit full colour resizeable icons.
Requests and font icons
Your boss' argument about additional request are simply false. It doesn't really matter whether your icons are part of a file or (in best case) part of a sprite image.
Both yield an HTTP request to fetch the resource. File size heavily depends on complexity and format but it may be that sprite image will be smaller. But having a few kilo larger font file doesn't really make much difference. They both get cached on the client afterwards.
I personally use Font Awesome as my primary resource for fonts, In my case I load it from the CDN hopping other pages that use it already fetched it and this was cached by the browser.
If file size is a concern, I can recommend to you this incredible awesome tool
http://fontello.com/
It allows you to merge several fonts into one single file, and only includes the icons you actually use.
http://www.icnfnt.com/ does the same for fontawesome, but I kinda like more fontello because it allows to use more fonts.
icon fonts is the way to go honestly in my opinion...
EDIT I lately have being using this app a lot too: http://icomoon.io/
When you use fonts, different browsers on different platforms will give different results. PNG files will give stable and independence results.
I have implemented a font icon library using icomoon and it works well on all the browsers including ie7. For small sets of icons this is a suitable practice, the font's scale properly, can be changed to any colour you require and you don't have to worry about PNG/GIF transparent background colours matching.
However... If your library becomes larger (mine is now around 40 icons), it becomes increasing difficult to maintain. If the designer ceases to work on the project, or you need to change the icons, it is a laborious process to update the fonts. Everything then needs to be retested. It is also difficult to dynamically icons using CSS (for ie7).
So, given the difficulty of maintenance, I'm considering switching back to a series of sprites (of different colours). The reasons being:
Any designer can easily add a new icon to the set.
The CSS doesn't need to be retested or altered.
You don't have to screw around with javascript workarounds for IE.
You don't need javascript at all.
For retina displays, simply create a verion of the sprite at twice the size,. You will probably need to have a different version of the CSS for retina regardless, as all the other images on your site will have the same density problem.
I would recommend 2 solutions to your problem these is what i would use for best customers support like they wanna change the text, size or other stuff
Use Fontsquirrel to make a webfont and embed it in your website trough your css and add it in your ftp directory if thats not getting pretty then use google web fonts
If non of that looks like it should i would go for the image solution your boss said..
All this also depend on which amount of time you have to solve your problem and such
Btw if you cant access the html i thought you could access the css which you can do trough most backends, if you cant then go for the image!
Last but not least, if you decide to go with the image solution, make a sprite which you direct trough on a background position. This way you only have to load 1 picture for all your little icons.
He's right. I'd use css sprites in this case. And if you have to support ie7 (I'm so sorry) you don't really have any options. Exploring those things on your own - of course, you never know what will come in handy or when.
The other day I was cruising around and stopped on http://www.justbenicestudio.com/studio/websymbols which had a nice little article on using #font-face for icons in websites. To quote the author, "There are those points in every interactive designer's career when he becomes fed up with producing the same set of graphics all over again for every website he designs."
I was curious if #font-face would work for the app that I work on. Check out the test.
It's not perfect so I'm looking for suggestions and opinions before I start implementing this. Do you think it's too soon? A waste of time? Or is it the most awesome thing since ajax?
I would personally suggest that it's too soon, most browsers support #font-face so you will be relatively safe but I don't see any good reason not to play it safe and produce the image. You're probably saving the user more time and bandwidth by giving them the one small image than the entire font. If you use a photo editor like photoshop or gimp, just keep your files and they will be ready for the next time you need them.
I have used #font-face only on text, but in that link you posted the button looks great. The only inconsistency I find is with cross-browser "compatibility" (but only from a design point of view). It's minor issues, though, and non-existent if you are designing for mobile (you mentioned app). Browsers render the font differently when it's text (for example, IE9 is not picking up the italics, but the render is less pixelated than chrome).
I think it's an issue of adaptability vs looks. Buttons made with images (preferably sprites, for my taste) will always look good, but you have to edit the images every time you want to make a new button. Buttons with #font-face are easy peasy to duplicate and modify, plus they might help with seo, but you have the browsers rendering difference.
Is it normal that fonts I used to create site layout are pixelated? I use Georgia, and in photoshop I've smooth lines everything looks great. But when I tried to slice it up and code the css, Georgia font same size looks noticeably uglier!
What are your thoughts?
p.s. I use em to declare sizes in css.
That's because photoshop is using anti-alias technique on text.
Both OS and browser will impact the appearance of text in web page.For example, Mac OS has anti-alias text on all system UI. For windows, I believe they have an option called 'ClearType', once switched on all system UI will have smooth texts.
All fonts on the web will look a little pixellated unless you're on a Mac which renders type considerably better than PC.
The best way I have found to replicate how a font will look on the web is to set the Anitialiasing in Photoshop to 'sharp'.
It is conceivable that there will be CSS markup in the future that will allow antialiasing in the browser rather than OS based.
It is a common problem.
See this article
http://jontangerine.com/log/2007/10/smoothing-out-the-creases-in-web-fonts
The alternative is to use something like Cufon that generates images for your text. Best practice would be to only use it for headings.
http://cufon.shoqolate.com/generate/
I've found this too - each browser renders fonts differently. I often find fonts look much better in IE. Sometimes I opt to use images created in PS to get that smooth look, but for the most part I think people are used to how fonts are rendered in their browser of choice.
In photoshop, there's an option to "smooth" text.
See this image. Bottom right corner.
Remove this anti-alising to have a better view (but not exact) of how the font will look in browser.
I've been reading a lot of ways recently of how to avoid having to use Photoshop for things like gradients and shadows on buttons, when you can use CSS3 Box Shadow for such features. Now this is great, but obviously legacy browsers and most IE browsers don't yet implement CSS3 features, so my question is, why save yourself extra work in Photoshop when you can use CSS3 but then HAVE to use Photoshop for other browsers to see the desired effects? Isn't that just extra work?
you can use CSS3 but then HAVE to use Photoshop for other browsers to see the desired effects?
Often you don't really care whether the other browsers see the desired effects. If it's just a subtle background gradient effect, the site's going to work fine and still look reasonable with a flat background in downlevel browsers.
Compatibility was more of a problem when CSS 2 Positioning was at this stage: an unsupported positioning feature could lead to an unusable layout. But for essentially frivolous effects like backgrounds, borders and shadows, it's not critical if the effect goes missing.
There are a few reasons. From a developer/designers perspective, using CSS3 can be more flexible. An image is more or less just a static image. With CSS you can use script or CSS to animate or adjust the styling, and have advanced integration between the various technologies. This allows you to be able to do some things that are not possible or difficult just using images.
The page weight is also lower usually when using CSS, which allows the page to load faster, especially on slow connections or mobile devices. It also reduces HTTP requests (although you can use data uris too) which reduces latency and thus speeds up page loading.
Using CSS is often more maintainable and quicker, as you can adjust say a background colour or a shadow quickly just by changing the CSS, while with images you have to open up photoshop, edit the file, resave, etc. This is fantastic for quick tweaks.
There are also some people (myself included) that are much more comfortable in code than they are using graphics packages. For me it is easier to use CSS, but your milage may vary.
Also from the browser perspective we want to move the web platform forward and increase the capabilities. SVG is an example of another technology that doesn't work across all browser versions yet, but adds a lot of power. Although it may not be possible to deploy sites using certain CSS3 properties or SVG without fallbacks right now (depending on your audience or client) there will be a time in the future when old browsers are dead and what we are adding today works for all users. There was a time when most of CSS2.1 wasn't supported for example, while now you can rely on most of it if you don't need to design for IE6.
There are some parts of CSS3 that you can happily use without fallbacks, if you have a client that doesn't require all browsers to look the same. border-radius is an example, or giving a solid colour fallback to old browsers and applying transparency for newer browsers.
The world is moving forward, you can't ignore it. as long as old browser will show a button and new browser will show a more nice one, you are ok.
Otherwise, we were still be working on VT100... as why using "Windows" if most monitors doesn't support more than 4 color graphics and has 80X22 resolution....
If your bosses accepts the idea of having two versions of looks and feel and a warning. CSS3 is a good idea.
So, you use CSS3 features in your code and forget about the browsers that are not compatible -- they will see the "low-graphics version", you might want to issue a non-intrusive warning (like the one we get as alerts in StackOverflow), saying, "Your browser is not compatible with CSS3. To see this website in high graphics please upgrade your browser. Click the link here to update now."
But, depends on where you work. Big companies with lot of resources may like to stick with Photoshop and smaller once may like a light-weight CSS3 code that degrades silently in non-compatible browser.
Well you can always use ChromeFrame, to impose nice behavior on IE. Assuming that a lot of products will insist for it the near future (yeah we can argue against this), chances are that most IE users will have chromeFrame even before your application would insist for it. Once you take a decision on this, decision on using CSS3 properties or HTML5 elements is - well - hell yeah!!
Marvin