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).
Related
Would adding WAI ARIA support, through JavaScript, be sufficient to support devices that assist users with disabilities? The script would enhance the markup to make a site more compliant with WAI/ADA recommendations (i.e., adding tabindex, aria- attributes/elements etc.). The concern is that users with disabilities may use devices that don't support JavaScript, thus rendering this approach futile.
Disabled users also are 98 or 99% to surf with JS activated so yes it'll work for most of them (source: latest WebAIM survey).
BUT this method leads to unmaintainable code: it'll break each time a dev or web designer modifies HTML and CSS and JS (and backend?) code (or even a content writer if it's also corrected by your scripts) and you'll have to modify your scripts or worse you won't notice it's now broken in screen readers and other assistive technologies.
It won't correct the contrast ratio between text and background (though it's rarely done once a website is launched).
It won't correct bad semantics, or you'll have to do it in JS on a poor existing HTML code instead of modifying directly templates. Why not make things the less complicated way, it's hard enough to refactor an existing site without breaking things!
It won't modify non explicit links, bad hierarchy of headings, underline links in text and bring back outline (do it directly in CSS).
If you can't zoom at least up to 200% (both in text mode and image+text mode), it won't change anything. Etc
Accessibility is far more than tabindex (make unfocusable elements that should be focusable real link and button elements instead of allowing focusing but without the rest of their behavior).
ARIA needs a modern screen reader to be perceived... and a screen reader to begin with. A magnification device isn't compatible with ARIA for example. That's great for blind people and some partially sighted users (those that use a SR) but not other disabled people.
Web Content Accessibility Guidelines (WCAG 2.0), the W3C/WAI Recommendation for web content has a wider scope to improve accessibility. WAI/ARIA has tremendous possibilities for applications (those that were impossible to use on the web and needed to install a software a few years ago) and advanced components but it should come after WCAG 2.0 (as a complement).
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 was wondering if anyone could offer any advice. I'm an expert HTML / CSS coder...but I have little experience with HTML 5. I have read about the great things it can do and I want to learn it, but im not 100% sure of what I can do with it. I have read a lot of articles regarding HTML 5 but none of them go into enough detail about it to answer my questions.
Aside from making layout easier, can it do things like create a rotating banner? I need to take the banner on the main page of this site
www.newmarklearning.com
and make it ipad / iphone compatible. I know I could use Javascript and a host of other coding options, but i fugued this is a great place I could start messing with HTML 5.
Problem is in not really sure if thats the right technology to use. Can HTML 5 / CSS 3 handle such things or am i limited to Javascript / Ajax etc???
Any help pointing me in the right direction would be great.
Thanks
Craig
Regarding animations, CSS3 offers you a lot of options. See e.g. here for more information on 2D Transforms. There exist 3D Transformations, too. However, only Webkit-based browsers support it right now. This site also offers a list of CSS3's new features.
In your case, to have the banner animated, you would have to combine a transform with a transition property (the transition let's it animate, the transform only describes the targeted rotation/scale/skew). If you want a constant animation (not just once), there might be some Javascript necessary.
Well, apart from that, HTML5 offers you a lot more new features, like offline storage or other things. The only problem is that the user has to have a relatively new browser in order to support everything, which sadly isn't the case right now (I know several companies that still run Windows XP with some IE6 or 7 or something like that - any updates disabled :-/)
Edit: Oh, OK, I just took a look at your site. For such a "slideshow", at least a little bit of Javascript will be necessary, to store the current slide etc.. But every smartphone browser should support it without a problem
do you mean the banner on the right? That changes on a timer, or when a number or arrow is clicked?
It would be easiest to recreate that with JavaScript.
Check out:
http://www.dhteumeuleu.com/
If you want some cool ideas
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.
I have integrated various WYSIWYG HTML editors over the past few years, but I think I have hit a brick wall on this one.
We need a way for people to edit text that turns into VML/SVG when rendered, but remains editable, with minimal styling such as bold, italic, font face and size, and if possible, ability to create a text region anywhere on the canvas. Google Docs has what appears to be one in their presentation editor. Something like that would work ~ its very close to what we are looking for.
Does anyone know of a commercial or free editor that does this (must be browser based), and if not, has anyone approached doing this, and if so, what were your results. Any other info, links, suggestions etc are welcome - I seem to have hit a brick wall on this one.
Thanks.
You might try http://svg-edit.googlecode.com/ though we do not translate to VML (we require IE users to install the Google Chrome Frame plugin).
One important question first: Why specifically should the output of the WYSIWYG editor be in VML/SVG?
===
I am not aware of any existing editor that fits your description. You may have to write one yourself. If you are going to roll your own, I have two suggestions; one of which I am less confident about in terms of capability and one where I am not entirely sure about the performance ramifications because of the sheer amount of libraries involved. Either way, these are the two best bets in my opinion:
1) If you're intent upon VML/SVG, one library I know that can bring the two together is RaphaelJS, which has some degree of text support, but I'm really not sure how sophisticated the degree of manipulation of the text is:
Raphael JS lib: http://raphaeljs.com/index.html
2) Can you instead use VML/Canvas? I would recommend using VML/Canvas via the exCanvas library (which allows you to write code using the HTML5 canvas element, which is automagically translated to VML in IE/Trident browsers), in addition to the new canvas-text library.
Generic canvas information (generic drawing api):
https://developer.mozilla.org/en/Canvas_tutorial
exCanvas (IE compatability layer for canvas element)
http://excanvas.sourceforge.net/
canvas-text (text-specific extension to browsers with poor canvas text support):
http://ajaxian.com/archives/canvas-text-add-text-functions-to-subpar-canvas-implementations