I have seen a few sites now that use SIFR, and I can see the benefits. I have (quickly) looked into other plugins similar, but SIFR seems to be quite good. So it good in terms of cross-browser compatibility?
I was part of a team that used SIFR in the design of a web application in 2008 so we could get a custom font for headlines.
It works OK most of the time but we frequently ran into problems where the SIFR text would be unnaturally wrapped.
That is
A Headline
Would Look
like This
Whenever this happened, we'd have to have our designer look at it and fix it, usually through some fiddling with the CSS.
The other thing I don't like about SIFR is the way the content flashes or blinks as it's replaced. This is really hard to avoid.
All in all, we spent a lot more time fixing SIFR issues that we thought we would, and in the final analysis I don't think it was worth it.
These days, I might look at a CSS-only solution like TypeKit or Kernest.
It basically runs on everything that has Flash enabled.
On browsers that have flash disabled or no plugin installed a fall back with basic CSS styling can be used.
I use SIFR in a number of sites, CMSs and web apps.
SIFR's fallback behaviour is quite good, so you don't need to worry much about compatibility. It works fine with all major flash-enabled browsers. Due to the replacement of "native" HTML tags it's perfect for SEO, too.
Setting sIFR up is tricky, be prepared for some initial debugging, changing relative paths, and so on. I tend to forget how to set it up every time, it's not very intuitive. But when it works, it works all right. On older machines, you will notice the split second SIFR needs to do the actual replacement. It can be notable and is not nice. On modern, fast machines you will notice nothing, as long as you just replace a few headlines and such. Sifr is not suitable for replacing entire paragraphs of text.
An alternative I have been meaning to check out some time is Cufon. While many people here like it, I can't say much about it myself. It's definitely also worth a look before you commit yourself to a solution.
Related
I'm having a issue which is hard to debug. I'm using a Javascript library (the JQuery Flexslider plugin) in a number of different places on my site. It's all working fine except for one particular phone where it doesn't work and slows down everything on the page.
So far, I've only seen it happen on this one device. Other devices of the same type do not have the issue. This person has an iOS that's a few versions out of date and not much memory, so I think it's a memory issue.
An old hack was to move the carousel element that has the issue on the page with Javascript, but I want to find and fix the root issue.
How can I start debugging this? I'm not sure how to test for a memory issue on a device.
If you're on a Mac, then you can plug in and use remote debugging via Safari, where you'll have access to the tools, including the profiler (not sure the state of Safari support in Windows). There are numerous resources for showing how to remotely debug a device, unless it is a really old version of iOS you should be fine, you’ll have to enable the develop menu via settings but after that its plain sailing if you know your debugging tools.
I'd agree that it doesnt really sound like a memory issue, although jQuery tends to be hungry in that respect, I dont know the plugin in question but the quality of plugins is hugely variable in jQuery-land. Old phones and old versions of jQuery certainly never played well together.
When you say one phone, you mean one type of phone + iOS version? The question isnt clear, its almost reads like you have 2 identical phones/os's where 1 works and 1 does not.
If you use Chrome you can use the Heap profiler
First open your developer tool and start recording.
Next start using your page and try to replicate your issue, stop recording and review the stats.
This is likely not a memory issue, but a cpu issue. The way jQuery does animation is processor constrained on older dvices. Factors that are easiest to handle include:
size of the page (html length and complexity)
animation steps, length, and complexity
You have a couple of options here, but the simple answer is you are asking too much of the older processor. Assuming you are using this plugin http://www.woothemes.com/flexslider/ you could try disabling or simplifying some of the transition effects. animation and animationSpeed would be the first I would suggest.
If you are interested in not changing the experience for most users you could consider tying into the start and end functions on the callback api and checking the time it took to perform the first transition, then reinitialize a simpler version of the slideshow for that device.
The hard thing here is there isn't really a right answer. If one of the above options doesn't fix it you're likely looking at choosing/building a different slideshow, degrading the experience for everyone, or determining the best way you feel comfortable with choosing who gets the degraded experience.
I have an idea for a web application for which I would require full control over the functionality of the embedded text editors and the text editors must function exactly the same across all browsers. The standard contenteditable functionality is not sufficient to my needs on this occasion.
So I have been experimenting with various ways to implement a custom text editor. My first approach was to detect mouse clicks for caret insertion (though with no visible caret since there doesn't appear to be a way to achieve this). This worked rather well, but unfortunately there was no way to display the caret (aka flashing I-beam).
This means that my flashing caret must also be custom made. I can only think of two good ways to achieve this in a way which will be compatible across all browsers.
The first (and probably better) option would be to implement a custom layout engine in JavaScript much like Google have done with Google Docs.
The second solution (probably a lot easier) would be to encapsulate each character within its own <span> element and thus allowing the faux caret to be placed between specific characters. This does mean that there will be a LOT of span elements, but this would certainly achieve what I need whilst taking advantage of the browser layout engine. Another benefit with this approach is that I do not need to rely upon dodgy browser-specific text selection hacks.
So my question, is option #2 a really bad idea? If so, why?
First of all - do you really need to work on your own editor? There are Firepad and Etherpad with their pretty cool collaborative editing and perhaps more open source editors not based on contenteditable. It's really hard to create such editor, so it does not make sense to waste time on it.
However, if you really want to work on your own solution and you need exactly the same behaviour across all browsers, then you're doomed ;). Even if you'll avoid contenteditable there are definitely other things that can go wrong.
Anyway, the answer:
First option is very hard and time consuming at the beginning but it gives you a lot more power than the second one. E.g. having completely custom layout engine, you'll be able to implement page breaks without waiting for the CSS3's implementation (on which you will never could rely on, because you want exactly the same behaviour across all browsers). And in fact, you'll be able to bypass most of browsers' rendering differences. But, unless you've got a team of decent JS devs and few months (at least), I wouldn't even start thinking about that.
The second solution - reusing DOM is more realistic. I would perform some performance tests first, but having span per character would be easy to find out where the caret should be placed after mouse click. Without that it requires some trick... Which I don't know. You can try to check how Etherpad and Firepad (which uses Ace code editor) deal with that, but still - wrapping will be the easiest choice and at least on decent browsers it should not cause performance issues, unless you want to edit really long documents (but then you can start some optimizations).
I've seen this question many times online, but none of them really have what I need.
Is there any available multi-select drop-down combo-box written in Javascript available, so that I can avoid reinventing the wheel?
(I'm still learning web programming, so I'm not too comfortable with making my own pop-ups yet...)
What I need is pretty much this:
(source: googlecode.com)
However, this one has several flaws:
The latest version doesn't seem to have the button on the side
The width grows arbitrarily big, or remains a fixed size (I need a "maximum width" option)
The control should look native in the browser, not custom-made. The arrow here is just a PNG file, and it pays no attention to what the browser actually displays for a regular combo-box.
Any ideas?
There are plenty of plugins available which I think you're already aware of. However, I'm not sure if there is a way to detect how the browser renders it actually.
Even in IE/XP, there's no easy way to tell if Visual styles are turned off or not (other than hacks like scrollbar width calculation etc).
Found one that claims to have native look and feel (not sure if you can do checkboxes in options): http://www.thunderguy.com/semicolon/2009/07/16/simple-combo-box-jquery-plugin/
Client wants to use a SIFR font for their entire website. Doesn't seem like a good idea to us. We've used SIFR in the past for headings but never for much more than that.
Anyone have any good technical reasoning or resources describing why this is a bad idea?
I would highly suggest taking a progressive enhancement approach instead of sIFR. CSS allows for custom font-faces to be used and they're fairly cross-browser compliant nowadays. For browsers that do not support font-face, they will simply fall back to some other specified font-family that want to use. The concept is to use more bleeding edge styles in your CSS while still gracefully falling back for browsers without adequate support.
From Mike Davidson's announcement of sIFR 2.0:
I looked at the page and he had replaced every single word with sIFR text… even complete paragraphs and 300-word passages. Do not do this please! sIFR is for headlines, pull quotes, and other small swaths of text. In other words, it is for display type — type which accents the rest of the page. Body copy should remain browser text. Additionally, we recommend not replacing over about 10 blocks of text per page. A few more is fine, but once you get into the 50s or so, you’ll notice a processor and speed hit.
So it's not a good idea. In fact, these days, sIFR itself isn't really necessary (Mike's announcement is from 2005). CSS3's new font features are a much better way to bring awesome fonts to your users.
SIFR is not actively developed anymore (last release dates from 2008: http://novemberborn.net/2008/10/sifr2-0-7-143).
I am thinking as a challenge i should write a javascript based game. I want sound, images and input. A background to simulate a screen (like 640x480 with all my images in it) would be useful to separate the rest of the page from the 'game'. What should i look at?
Some things i would need
Framecontrol. A way to get the current time (or delta).
Image, displaying it and moving it. How do i display full image. Knowing pixel access may be cool.
Input A way to lock it in a box (like flash does) is cool.
Sound play simple sounds on demand (like when i get a hit). Several sounds at once would be great
Bottlenecks. What are things that will kill the CPU?
Restrictions. What cant i do? I hear i cant 'sleep' to wait. I must set a callback
Good or best pratice. What are good things i can do to either keep speed up or to lower glitch or compatibility problems.
I'm going to answer this looking at things from a mootools javascript perspective:
Framecontrol. A way to get the current time (or delta).
periodical()
Image, displaying it and moving it. How do i display full image.
setStyles()
Input A way to lock it in a box (like
flash does) is cool.
Plain old CSS
Sound play simple sounds on demand
(like when i get a hit).
Swiff, remote();
Bottlenecks. What are things that will
kill the CPU?
Internet Explorer.
Restrictions.
3D ... ?
What are good things i can do ... to
lower glitch or compatibility
problems.
Use a framework.
As a starting point, you may want to write it for Opera, as Opera provides a game canvas that will help you out.
For some examples of games in javascript:
http://dev.opera.com/articles/view/3d-games-with-canvas-and-raycasting-part/
http://my.opera.com/WebApplications/blog/show.dml/200788
This one is interesting, it is demos of games using the canvas element.
http://www.canvasdemos.com/tag/games/
The best way to see where the problems are is to start writing the game, and then you will see what may be a problem. By looking at demos you can get an idea what performance issues they encountered. For example, a full 3D Doom game will have problems, but, as the first article above explains, there are some ways to optimize for javascript.
Once you get it working with Opera, then you can look at Firefox 3.5+ and Safari, as well as Chrome, and see if you can make some changes to have it work on those. How many platforms it works on depends on how much work you want to do for it. For a proof-of-concept pick the easiest browser for your task.
The best place to start would be to get very familiar with the <canvas> tag (it allows you to draw anything on screen)
This may help a lot:
http://benfirshman.com/projects/jsnes/
its an online NES emulator that renders everything on screen - the source is also available
Hope that helps =)