Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 12 of 12
  1. #1
    Regular Coder
    Join Date
    Nov 2009
    Posts
    110
    Thanks
    7
    Thanked 9 Times in 9 Posts

    @font-face and NoScript Firefox Addon

    I thought that using @font-face was just CSS and shouldn't require javascript. But when using the NoScript Firefox addon with all scripts blocked the @font-face custom fonts don't load.

    I am guessing this is not because the fonts require javascript but because NoScript sees them as some kind of active content (NoScript doesn't only block java and javascript but also flash and all sorts of other types of active content). The fact that NoScript is a pretty popular addon (I use it myself) concerns me because I really want to be sure the custom fonts are working for as wide a range of browsers as possible.

  • #2
    Senior Coder Arbitrator's Avatar
    Join Date
    Mar 2006
    Location
    Splendora, Texas, United States of America
    Posts
    3,372
    Thanks
    32
    Thanked 286 Times in 280 Posts
    Quote Originally Posted by linehand View Post
    I am guessing this is not because the fonts require javascript but because NoScript sees them as some kind of active content (NoScript doesn't only block java and javascript but also flash and all sorts of other types of active content). The fact that NoScript is a pretty popular addon (I use it myself) concerns me because I really want to be sure the custom fonts are working for as wide a range of browsers as possible.
    Apparently, NoScript now blocks @font-face and the new HTML 5 audio and video elements by default for "untrusted sites" via the Embeddings Tab in the NoScript options window.

    I'm curious what your question is though since you didn't actually pose one.
    For every complex problem, there is an answer that is clear, simple, and wrong.

  • #3
    Regular Coder
    Join Date
    Nov 2009
    Posts
    110
    Thanks
    7
    Thanked 9 Times in 9 Posts

    Just Curious

    Yeah, I guess I didn't really have any specific question. Just interested in others' thoughts on this.

    Personally I think NoScript users make up a lot of the traffic that gets logged as not supporting JS..

    @font-face is standard css yet it gets blocked by script-blockers which raises the question of standards in general. I mean a big part of why we are using CSS is because it is a standard which should work across all platforms as long as you follow the standards but now standard features of CSS are being blocked as dangerous. So if overly powerful features get added to CSS then the very benefit of using CSS as a standardized layout foundation breaks down.

    It just really limits how much you can do with @font-face if you can't count on it working. It also means that while @font-face could be a great alternative to image replacement, if it might just get blocked along with JS and Flash then we can't count on it as a replacement for image replacement. So what, use custom fonts but then, where it is very important, still use image replacement as a fall back for no custom fonts?

    Unfortunate that something which could help simplify an overly complex issue ultimately only manages to add yet another layer of complexity.

    Anyway, my real questions would be better taken up with the makers of NoScript. I am curious about the technical details of exactly how firefox handles these fonts and how dangerous they could really be.

    I guess the biggest question I would have for you lot then is; how to set up a bulletproof fallback option in-case @font-face is a no-go?

  • #4
    The Apostate Apostropartheid's Avatar
    Join Date
    Oct 2007
    Posts
    3,215
    Thanks
    16
    Thanked 265 Times in 263 Posts
    Not dangerous. Just possibly annoying. Pre-emptive blocking, perhaps.

  • #5
    Senior Coder Arbitrator's Avatar
    Join Date
    Mar 2006
    Location
    Splendora, Texas, United States of America
    Posts
    3,372
    Thanks
    32
    Thanked 286 Times in 280 Posts
    Quote Originally Posted by linehand View Post
    Personally I think NoScript users make up a lot of the traffic that gets logged as not supporting JS..
    Right. Good applications should generally not require scripting to be present to access content though. Your average NoScript user is going to be more technically saavy than your average 'net user, so they'll probably find a way to work around this issue (by declaring the site "trusted" or otherwise).

    Quote Originally Posted by linehand View Post
    @font-face is standard css yet it gets blocked by script-blockers which raises the question of standards in general. I mean a big part of why we are using CSS is because it is a standard which should work across all platforms as long as you follow the standards but now standard features of CSS are being blocked as dangerous. So if overly powerful features get added to CSS then the very benefit of using CSS as a standardized layout foundation breaks down.

    It just really limits how much you can do with @font-face if you can't count on it working. It also means that while @font-face could be a great alternative to image replacement, if it might just get blocked along with JS and Flash then we can't count on it as a replacement for image replacement. So what, use custom fonts but then, where it is very important, still use image replacement as a fall back for no custom fonts?
    CSS is for styling documents; as long as the document is marked up properly, this should generally not be a problem. When the font fails, you'll simply get unstyled text which is significantly batter than if, say, you use an image for text and forget to provide fallback.

    As it is, you cannot rely on consistent display for most things on the Web including images since these can be disabled or customized so not much has changed.

    Quote Originally Posted by linehand View Post
    Unfortunate that something which could help simplify an overly complex issue ultimately only manages to add yet another layer of complexity.
    It does help: (1) it means that you can style header and body text with less bandwidth usage, in general; (2) you lose the overhead of having to maintain an image and alt text; (3) users can view your text more rapidly*; (4) users can view fully formatted text even when images are disabled.

    * In Safari, they've decided to delay text rendering until the font has loaded though; apparently, they consider displaying content less important than avoiding the so-called "flash of unstyled text". Then there's a WIE bug where the entire page isn't loaded until the fonts are.

    Quote Originally Posted by linehand View Post
    I guess the biggest question I would have for you lot then is; how to set up a bulletproof fallback option in-case @font-face is a no-go?
    There is no such thing as "bulletproof" on the Web.

    Quote Originally Posted by Apostropartheid View Post
    Not dangerous. Just possibly annoying. Pre-emptive blocking, perhaps.
    Blocking users is just going to get people to not use your site. Doing that because they can't view your pretty font would be pretty stupid, IMO.
    For every complex problem, there is an answer that is clear, simple, and wrong.

  • #6
    Regular Coder
    Join Date
    Nov 2009
    Posts
    110
    Thanks
    7
    Thanked 9 Times in 9 Posts
    Some very good points you bring up.

    I think Apostropartheid meant preemptive blocking on the user's end not the website's end. Like a user installs adblocking software to preemptively block all ads, a user may wish to preemptively block all fonts because they don't like them or think they are a just waste of bandwidth or something.

    I agree that @font-face can simplify some things greatly. I seldom use image replacement though and where I might use image based text would only be in places where it was rather important, like in a logo where it is important that it looks exactly as it should. In those rare cases where I would use a graphic as text using @font-face becomes very appealing because it can get around IE6s poor support for PNG alpha.

    In cases where I might use an image though, I would only consider using @font-face if I had a pretty foolproof way to hide the text and show an image instead if a visitor's browser didn't support @font-face (or they had it disabled).

    In the case of using a nice font for your body text and such it is less of an issue because it is easy to fall back on default fonts without breaking your design/layout. I generally wouldn't ever use IR on regular body text or normal headings anyway though. In cases of putting graphics and type together tightly to create a specific design arrangement were changing the font would cause it to fall apart, well, I guess @font-face is less of an option without a pretty solid graphic fall-back.

    The case of an image with graphical text in it being disabled is a more graceful deterioration because you get the alt text which explains the graphic and you know right off that it is because image is missing that it looks this way. In the case of an element which includes an image and some text but the text is actually real text laid over the image and positioned precisely, then if the font changes that element will look like broken garbage (rather than just being missing with alt text to explain) and there won't be any clear indication to the user that it is because the font is missing (whereas it is plainly obvious what the problem is when images are missing).

    I realize there is no such thing as truly bulletproof (and if there were we would just invent some better bullets) but I am still trying to come up with a way to determine if @font-face works for the user and if it doesn't work then to hide the text and show an image instead. I don't really mind if the solution is tied to javascript.. So if no JS they just get an Image, if they have JS then they get @font-face but if the fonts don't get DLed into the users cache then they just get the images again. So load a JS which loads the css file with the @font-face rules, then the JS has to be able to check somehow to see if the fonts worked and if they did then the JS could run a second CSS file which would hide the images and show the texts. So if the JS doesn't run they get images, if the JS runs but they don't get the fonts then they get images, if the JS runs and to fonts work then the images are hidden and the text is revealed.. I could use some help though because I don't know any javascript.

  • #7
    Senior Coder Arbitrator's Avatar
    Join Date
    Mar 2006
    Location
    Splendora, Texas, United States of America
    Posts
    3,372
    Thanks
    32
    Thanked 286 Times in 280 Posts
    Quote Originally Posted by linehand View Post
    I agree that @font-face can simplify some things greatly. I seldom use image replacement though and where I might use image based text would only be in places where it was rather important, like in a logo where it is important that it looks exactly as it should. In those rare cases where I would use a graphic as text using @font-face becomes very appealing because it can get around IE6s poor support for PNG alpha.
    A logo, even if it includes text, should be an image; a logo requires an exact appearance and an image suits that purpose well.

    Considering that you mention that you would only use @font-face in rare cases, it might be better to just stick with images since you're not going to get as much benefit from font caching, bandwidth savings, decreased overhead, etc. If you want custom fonts in MSIE6, you can already do that; that browser supports EOT and conditional comments.

    Quote Originally Posted by linehand View Post
    The case of an image with graphical text in it being disabled is a more graceful deterioration because you get the alt text which explains the graphic and you know right off that it is because image is missing that it looks this way.
    If you need to "explain the graphic" and a fallback from styled text to unstyled text is not adequate in doing that, then custom fonts are not the solution you were looking for anyway. You would only need to be indicating that the font is missing if it was a part of your content and, thus, users were missing out on key information; content doesn't belong in a style sheet.

    Quote Originally Posted by linehand View Post
    In the case of an element which includes an image and some text but the text is actually real text laid over the image and positioned precisely, then if the font changes that element will look like broken garbage (rather than just being missing with alt text to explain) and there won't be any clear indication to the user that it is because the font is missing (whereas it is plainly obvious what the problem is when images are missing).
    I'm afraid that this solution doesn't make the slightest bit of sense. Not only can you not rely on fonts to render precisely the same between browsers/OSes (due to differences in kerning support, anti-aliasing methods, etc), but you would be defeating the purpose of using the custom font since an image would still need to be downloaded. In such a case, you may as well continue to use alt text as fallback.

    Quote Originally Posted by linehand View Post
    I realize there is no such thing as truly bulletproof (and if there were we would just invent some better bullets) but I am still trying to come up with a way to determine if @font-face works for the user and if it doesn't work then to hide the text and show an image instead. I don't really mind if the solution is tied to javascript.. So if no JS they just get an Image, if they have JS then they get @font-face but if the fonts don't get DLed into the users cache then they just get the images again. So load a JS which loads the css file with the @font-face rules, then the JS has to be able to check somehow to see if the fonts worked and if they did then the JS could run a second CSS file which would hide the images and show the texts. So if the JS doesn't run they get images, if the JS runs but they don't get the fonts then they get images, if the JS runs and to fonts work then the images are hidden and the text is revealed..
    In order to create the no-JS situation, you would have to have the images on the page display by default which would mean that they would be downloaded regardless of support or create a second, alternative copy of every page for these users (this might be tenable if browsers didn't download or stopped downloading content that was invisible or removed from the DOM, but I don't believe they do). Again, this would defeat a major part of the purpose behind @font-face. If the font style is so important to the interpretation of your content, you are probably better off sticking with images.

    @font-face is meant to be used in cases where fallback to a less desirable font is acceptable. When that's not acceptable, this is the wrong solution.
    For every complex problem, there is an answer that is clear, simple, and wrong.

  • #8
    Regular Coder
    Join Date
    Nov 2009
    Posts
    110
    Thanks
    7
    Thanked 9 Times in 9 Posts
    Quote Originally Posted by Arbitrator View Post
    A logo, even if it includes text, should be an image; a logo requires an exact appearance and an image suits that purpose well.
    Just using a logo as an extreme example of an element that may be mixed graphics and text where the positioning and style of the text in relation to the graphics is important.

    Quote Originally Posted by Arbitrator View Post
    Considering that you mention that you would only use @font-face in rare cases, it might be better to just stick with images since you're not going to get as much benefit from font caching, bandwidth savings, decreased overhead, etc. If you want custom fonts in MSIE6, you can already do that; that browser supports EOT and conditional comments.
    Did I say that? I thought I said that I would only use image based text (or image replacement) in rare cases, and thus cases where fallback to default fonts would be problematic would be rare. At least that is what I meant. It really depends on the situation. For instance if you are using the same custom fonts for body and headings and other elements where fall back to default fonts won't be an issue so only one or two elements will need to be replaced with graphics even though all your text had been using the custom fonts.

    Quote Originally Posted by Arbitrator View Post
    If you need to "explain the graphic" and a fallback from styled text to unstyled text is not adequate in doing that, then custom fonts are not the solution you were looking for anyway. You would only need to be indicating that the font is missing if it was a part of your content and, thus, users were missing out on key information; content doesn't belong in a style sheet.
    In the case of an image which has some text in it, when the image doesn't display you get the alt text and you know it was meant to be an image. If it was using a font and the font is missing but not the images then it will appear but the text will be all big and overlapping or something - it would have been better to just have it not appear at all and just have some plain alt text. Of course you are right though, it just doesn't make sense to try to use fonts in this manner on the web (at least not without a better fallback solution than default fonts), they are better suited to general text than to graphical elements.

    As for content not belonging in the stylesheet. You are right also, and that is one more reason why it would be better to just use images (with their alt text) in your content. If you are already using the same fonts for regular body text and such though, then using stylesheets to refashion a real text version of the graphical content wouldn't come at any great cost (since you were going to send those fonts anyway) and would still leave the straight graphic with alt text in the content where it belongs.

    Quote Originally Posted by Arbitrator View Post
    I'm afraid that this solution doesn't make the slightest bit of sense. Not only can you not rely on fonts to render precisely the same between browsers/OSes (due to differences in kerning support, anti-aliasing methods, etc), but you would be defeating the purpose of using the custom font since an image would still need to be downloaded. In such a case, you may as well continue to use alt text as fallback.
    It is true that you can't really on fonts to display exactly the same, but you can set up graphical textual elements so that minor changes in kerning and anti-aliasing won't compromise the design. Say you had a very narrow font and you have left enough room in the design to account for minor font rendering differences, but changing to a default font will cause the font to be way too wide to even fit, combined with it being the wrong style font entirely. Images don't display exactly the same across systems either. I wouldn't be so concerned with antialiasing personally because if someone has no font smoothing in their browser then they are probably quite used to looking at jagged text and that's their prerogative. You can also minimize the font differences in font rendering by not allowing the use of local versions of fonts.

    Yeah the image still had to be downloaded but the fonts were going to get downloaded anyway.

    Quote Originally Posted by Arbitrator View Post
    In order to create the no-JS situation, you would have to have the images on the page display by default which would mean that they would be downloaded regardless of support or create a second, alternative copy of every page for these users (this might be tenable if browsers didn't download or stopped downloading content that was invisible or removed from the DOM, but I don't believe they do). Again, this would defeat a major part of the purpose behind @font-face. If the font style is so important to the interpretation of your content, you are probably better off sticking with images.
    It is certainly true that I am probably better off sticking with images for the type of graphical text I'm talking about, but I just don't want to..

    Quote Originally Posted by Arbitrator View Post
    @font-face is meant to be used in cases where fallback to a less desirable font is acceptable. When that's not acceptable, this is the wrong solution.
    For the most I think this is true. Yet it is still just kind of cool to have a graphically rich page where all the text is real text but that will look right (not identical, but not wrong, just right) in all browsers and even be able to fall back to graphics in any case where it might not look right (due to lack of fonts). Maybe it is not the best idea but I am going to have fun making it work anyway. So even if it's not the best idea, it would be nice to have some help on how to get the JS to determine whether the @font-face rules worked or not..

    All I have so far is this
    // JavaScript Document
    Code:
    document.write('<link href="assets/font-face-rules.css" rel="stylesheet" type="text/css">')
    
    Some kind of function to determine whether or not those fonts worked
    and then if they did work then to go to the next step,
    if they didn't work then to skip the next step and finish
    
    document.write('<link href="assets/hide-images-show-text.css" rel="stylesheet" type="text/css">')
    Anyone know what should go in the middle?
    Last edited by linehand; 11-12-2009 at 09:38 AM. Reason: minor clarification

  • #9
    Senior Coder Arbitrator's Avatar
    Join Date
    Mar 2006
    Location
    Splendora, Texas, United States of America
    Posts
    3,372
    Thanks
    32
    Thanked 286 Times in 280 Posts
    Quote Originally Posted by linehand View Post
    Did I say that? I thought I said that I would only use image based text (or image replacement) in rare cases, and thus cases where fallback to default fonts would be problematic would be rare.
    Perhaps I misinterpreted your comment, but it sounded like you said cases where you would use custom text via images were rare. Since you want to render this same text using @font-face instead, it sounded like cases (i.e., the aforementioned cases) where you would use @font-face would also therefore be rare.

    Quote Originally Posted by linehand View Post
    It really depends on the situation.
    I was only addressing your specific situation as I interpreted it, not a general situation.

    Quote Originally Posted by linehand View Post
    For instance if you are using the same custom fonts for body and headings and other elements where fall back to default fonts won't be an issue so only one or two elements will need to be replaced with graphics even though all your text had been using the custom fonts.
    So, in other words, you want fallback to what you would normally see on a Web page today (heading text as images and body text as text) if @font-face is not supported? I'm afraid I'm not sure how you would do that.

    Quote Originally Posted by linehand View Post
    In the case of an image which has some text in it, when the image doesn't display you get the alt text and you know it was meant to be an image. If it was using a font and the font is missing but not the images then it will appear but the text will be all big and overlapping or something - it would have been better to just have it not appear at all and just have some plain alt text.
    In either case, you're getting plain, fallback text so I don't see what difference it makes. Actually, in WIE, the fallback is worse, since you're not getting plain text, but a replaced element with unstylable text in it.

    For some reason that I don't understand, you want to relate that the custom font is missing to the user. The thing is, in this situation, I don't see how relating this information is useful to the user and why you would, thus, want to relate it in the first place. I can see how you would want to relate that if the image were, say, a photo since the user is clearly missing out on information that can't be related by a text fallback, but this case merely involves stylized versions of text; the style is a decoration and doesn't convey any additional information so there's no loss in content (only an aesthetic) when the stylization is missing.

    Quote Originally Posted by linehand View Post
    As for content not belonging in the stylesheet. You are right also, and that is one more reason why it would be better to just use images (with their alt text) in your content. If you are already using the same fonts for regular body text and such though, then using stylesheets to refashion a real text version of the graphical content wouldn't come at any great cost (since you were going to send those fonts anyway) and would still leave the straight graphic with alt text in the content where it belongs.
    I think you missed my point. I was trying to say that you shouldn't convey key information (i.e., content) in a style sheet. If the appearance of the text is key information (as opposed to what the text actually says), then you should not be using @font-face to display that text.

    Example: If I have a header that says "Table of Content" and there's some other key information that can only be gleaned from the way that text looks (i.e., the font used), then an image needs to be used to display that text since the appearance has become content. On the other hand, if this header only indicates what it says, than @font-face is fine and so is a fallback to another font. I don't see how telling the user that a custom font is missing via using an image instead is going to help them here since they haven't actually missed out on anything key.

    So, yes, of course, this would be fine for body text and I wasn't arguing otherwise. You're not putting content into the style sheet when you change the font used by the body text because the way that text looks doesn't matter as far as content goes; the content is all in what the text actually says. I'm also arguing that this applies to header text as well though (a point on which you seem to disagree by indicating that the appearance of this text is so important as to warrant images as fallback if @font-face fails).

    Quote Originally Posted by linehand View Post
    It is true that you can't really on fonts to display exactly the same, but you can set up graphical textual elements so that minor changes in kerning and anti-aliasing won't compromise the design. Say you had a very narrow font and you have left enough room in the design to account for minor font rendering differences, but changing to a default font will cause the font to be way too wide to even fit, combined with it being the wrong style font entirely. Images don't display exactly the same across systems either. I wouldn't be so concerned with antialiasing personally because if someone has no font smoothing in their browser then they are probably quite used to looking at jagged text and that's their prerogative. You can also minimize the font differences in font rendering by not allowing the use of local versions of fonts.
    The point was that your mentioned idea of overlapping the text over an image was totally unworkable because they would have to be pixel identical for you to not notice that they were overlapped. Of course, you mentioned yourself that the idea wouldn't work, so I guess I shouldn't have bothered commenting on it.

    Quote Originally Posted by linehand View Post
    Yeah the image still had to be downloaded but the fonts were going to get downloaded anyway.
    The fonts are supposed to be downloaded; the point was that you're losing out on the major benefit of not having to download images; with such a solution, you are increasing bandwidth usage instead of decreasing it because now you have to download images AND fonts instead of just images. Not only are you using more bandwidth to serve this information, but your users are getting a degraded experience because that have to wait for all of this to load in the background even when it's not needed (which in turn affects the load time of other content on the page).

    Quote Originally Posted by linehand View Post
    It is certainly true that I am probably better off sticking with images for the type of graphical text I'm talking about, but I just don't want to..
    In other words, you want to use this feature "just because" rather than using the right tool for the effect you want? That's good for learning, but I wouldn't do it on a production site.

    Quote Originally Posted by linehand View Post
    For the most I think this is true. Yet it is still just kind of cool to have a graphically rich page where all the text is real text but that will look right (not identical, but not wrong, just right) in all browsers and even be able to fall back to graphics in any case where it might not look right (due to lack of fonts). Maybe it is not the best idea but I am going to have fun making it work anyway.
    Good luck with that.

    Quote Originally Posted by linehand View Post
    So even if it's not the best idea, it would be nice to have some help on how to get the JS to determine whether the @font-face rules worked or not..

    All I have so far is this
    // JavaScript Document
    Code:
    document.write('<link href="assets/font-face-rules.css" rel="stylesheet" type="text/css">')
    
    Some kind of function to determine whether or not those fonts worked
    and then if they did work then to go to the next step,
    if they didn't work then to skip the next step and finish
    
    document.write('<link href="assets/hide-images-show-text.css" rel="stylesheet" type="text/css">')
    Anyone know what should go in the middle?
    You might want to ask in the JavaScript forum. I know how to script, but don't know how to detect via scripting whether @font-face is supported or not.

    Since you're new to scripting, I'll point out that document.write is poor practice. You should be using DOM methods to construct nodes:

    Code:
    if (whatever) { // replace "whatever" with a condition
    	var d = document;
    	var link_element = d.createElement("link");
    	link_element.setAttribute("rel", "stylesheet");
    	link_element.setAttribute("media", "all");
    	link_element.setAttribute("type", "text/css");
    	link_element.setAttribute("href", "assets/hide-images-show-text.css");
    	d.getElementsByTagName("head").item(0).appendChild(link_element);
    }
    For every complex problem, there is an answer that is clear, simple, and wrong.

  • #10
    Regular Coder
    Join Date
    Nov 2009
    Posts
    110
    Thanks
    7
    Thanked 9 Times in 9 Posts
    I think you're kind of missing the point a little bit.

    First I don't know that @font-face offers any kind of bandwidth savings no matter how it is used. For standard text which can safely fall back to default fonts then it is entirely superficial and only adds non-essential data transfers. As a replacement for IR I have my doubts as to how much bandwidth it could save - with a subset of just the letters used in your images the font files could be small but then you would need new ones every time you changed anything. In general a complete font with most common characters in regular, bold, italic, and bold italic is going to weigh 100k or more. It is kind of beside the point though as the primary use of @font-face is for general text and the added download size is purely for non-essential appearance.

    Let me give you an example. Say you had a site where you deemed it important for certain text elements to appear a certain way. Maybe headings or maybe where text interacts closely with other graphical elements. Important enough to use images in place of actual text. By using an IR technique you can make it so that there is real text within the content of the site which can be read by screen readers, search engines, etc but that is hidden in some manner for general viewing and the images are made visible instead.. Whether or not this is the best type of IR method to use is not the point here - plenty of people do use this type of method.

    Then you figure the site would look even better if all this body text were to use the right font so you use @font-face and the site looks better that way but it won't be broken without it. Yeah it uses a bit of bandwidth but you optimize the rest of your site well enough that you can afford it.

    Now without doing anything more than that (provided they got the fonts ok) you already have everything you need in place to just hide those images and show the text versions instead. No need to be putting content in stylesheets or vice versa, or making the style of font suddenly be considered content. All of that is just over complicating it. Everything was already in place using your already established method of building the site, you just hide the image versions and unhide the text version.

    This raises two main questions. Well actually one question and one problem.

    First the problem: It all hinges on the fonts working. But images are already in place as a fallback so we just need a method of knowing whether the fonts worked or not.

    And the question: Why would you want to do this? Ok sure you already have everything in place so doing it shouldn't be a problem but why bother? The images are more likely to render closer to identical than the fonts anyway. Well maybe you just want to for the heck of it to see how it works - then when you try it you just feel like it looks better that way across a wider range of browsers, in-spite of the minor rendering differences. You tweak the design a little looking at how the fonts render in different browsers so that they will look fine across all the browsers your traffic uses.

    Having a text and an image based version of the same piece of content within the HTML could be seen as redundant, but that is straying into the debates overs particular forms of IR. There can be some benefits to having the 2 versions of that content as well - a search engine can't see the image for what it is which means it can't tell that the text and image versions are identical so it looks like more content to a search engine and depending upon how it is used it can be made to make the content more accessible on a wider range of devices.

    Finally I guess the difference between an image fallback (with alt text) and a component designed with a combination of graphics and text is that they get a very ugly version without the font whereas they just get a very plain version without the image. Sure, either way they get the important text but in the case of the pure image, if it fails they get plain alt text (boring and plain) whereas if your graphical text which needs the font uses a default font, yes they still get the info but it is all messed up and looks like the designer was on crack (ugly and broken).

    If one were to choose between plain and boring as a fallback or ugly and broken, one would probably choose the former. Now just because the fonts are important to the proper display of that info does not mean that the fonts suddenly become content, (though I see how this could have been implied) because without them it could just show the graphic version which works fine and without that it shows the alt text of the graphic which is plain and boring, and with no style whatsoever then you could see the text version but not laid out all broken because there wouldn't be any layout, just semantics where it could be arranged in a semantically sensible manner to be fine without any style or layout (or fonts), and yeah you would see the image version too but as far as the site being seen as a repository of semantically organized content then having the image versions of certain key info there beside the text version of that key info could only be seen as an asset to that repository of content..

    I don't see how having a really robust fallback option for the use of custom-fonts in a variety of different contexts should be seen as a bad thing.

  • #11
    Senior Coder Arbitrator's Avatar
    Join Date
    Mar 2006
    Location
    Splendora, Texas, United States of America
    Posts
    3,372
    Thanks
    32
    Thanked 286 Times in 280 Posts
    Quote Originally Posted by linehand View Post
    For standard text which can safely fall back to default fonts then it is entirely superficial and only adds non-essential data transfers.
    The same can be said for image-based text.

    You are unnecessarily compounding that problem when you make it so that multiple heavy formats have to be downloaded only to have one entirely discarded.

    Quote Originally Posted by linehand View Post
    As a replacement for IR I have my doubts as to how much bandwidth it could save - with a subset of just the letters used in your images the font files could be small but then you would need new ones every time you changed anything. In general a complete font with most common characters in regular, bold, italic, and bold italic is going to weigh 100k or more.
    In English, I'd expect that you could simply subset to the alphabet and punctuation in most cases. Depending on formatting rules for say, your headers, you may also be able to eliminate the bold italic or other faces (I can't remember having used Bold Italic for anything in final output). Additionally, you can compress files for further reductions.

    As for having to make frequent changes, I don't think they would be frequent and, if anything, less so than having to make a new image every single time you want to do so much as change the color of the text.

    Quote Originally Posted by linehand View Post
    It is kind of beside the point though as the primary use of @font-face is for general text and the added download size is purely for non-essential appearance.
    Responsiveness (including bandwidth concerns) are never beside the point IMO. You cut where you can.

    Regarding "general text", the text authors most often want to change seems to be headers since that's where they have the most freedom to use odd fonts and effects so I don't know if that was the primary target. I don't think I've seen any real site yet that uses them for body text.

    Quote Originally Posted by linehand View Post
    Let me give you an example. Say you had a site where you deemed it important for certain text elements to appear a certain way. Maybe headings or maybe where text interacts closely with other graphical elements. Important enough to use images in place of actual text.
    So will this "important" interaction be lost when you convert to actual text via CSS3 Fonts? Do you have a visual example of such an interaction that I can look at? (As a graphic designer, I'm kind of curious.)

    Quote Originally Posted by linehand View Post
    Yeah it uses a bit of bandwidth but you optimize the rest of your site well enough that you can afford it.
    What are these optimizations? (Remember, you not only have to optimize now against the fonts but also against the hidden images that are going to be downloaded.)

    Quote Originally Posted by linehand View Post
    Now without doing anything more than that (provided they got the fonts ok) you already have everything you need in place to just hide those images and show the text versions instead.
    But won't this destroy the important interaction you mentioned earlier? Does this only work if you using a single font for both the headings and body text?

    Quote Originally Posted by linehand View Post
    Everything was already in place using your already established method of building the site, you just hide the image versions and unhide the text version.
    Should this method, then, be applied to newly minted sites or just sites where you've already spent time creating the images?

    Quote Originally Posted by linehand View Post
    Well maybe you just want to for the heck of it to see how it works
    Great methodology.

    Quote Originally Posted by linehand View Post
    then when you try it you just feel like it looks better that way across a wider range of browsers, in-spite of the minor rendering differences. You tweak the design a little looking at how the fonts render in different browsers so that they will look fine across all the browsers your traffic uses.
    Isn't this a reason to stop using images?

    Quote Originally Posted by linehand View Post
    Having a text and an image based version of the same piece of content within the HTML could be seen as redundant, but that is straying into the debates overs particular forms of IR.
    How are debates over the best technique and employing redundant techniques simultaneously the same thing? Or am I misinterpreting what you're saying again?

    Quote Originally Posted by linehand View Post
    There can be some benefits to having the 2 versions of that content as well - a search engine can't see the image for what it is which means it can't tell that the text and image versions are identical so it looks like more content to a search engine
    In order to have both the images and CSS3 Fonts, you're going to have to either serve duplicate content (i.e., img element with an alt attribute and plain text) or dynamically insert the text to be styled. Doesn't duplicated content harm your search engine rankings? Do they read dynamically inserted text? What indication is there that they treat alt text and just plain text differently? (I'm afraid I'm not that familiar with SEO concepts.)

    Quote Originally Posted by linehand View Post
    and depending upon how it is used it can be made to make the content more accessible on a wider range of devices.
    How so? With CSS3 Fonts alone, you will invariably get the text in whatever font. I don't see how images can ever be more accessible. (I'm thinking of "accessible" in the usability sense, by the way; as far as I can tell, the only thing that would be more "accessible" is the design, not the content.)

    Quote Originally Posted by linehand View Post
    Finally I guess the difference between an image fallback (with alt text) and a component designed with a combination of graphics and text is that they get a very ugly version without the font whereas they just get a very plain version without the image. Sure, either way they get the important text but in the case of the pure image, if it fails they get plain alt text (boring and plain) whereas if your graphical text which needs the font uses a default font, yes they still get the info but it is all messed up and looks like the designer was on crack (ugly and broken).
    Maybe I'm in the minority, but when I'm using a Web site using exclusively Web-safe (i.e., "boring and plain") fonts for heading and body text, I'm not thinking "the designer was on crack". Most sites I've seen with ugly or inaccessible fallbacks were apparently crafted by people that didn't consider styling the fallback content or who decided to create a pixel-precise layout; both are bad practice.

    I'm curious if you have some example Web sites you can show that look hideous with fallbacks and don't run amok of these problems?

    Quote Originally Posted by linehand View Post
    If one were to choose between plain and boring as a fallback or ugly and broken, one would probably choose the former. Now just because the fonts are important to the proper display of that info does not mean that the fonts suddenly become content, (though I see how this could have been implied) because without them it could just show the graphic version which works fine and without that it shows the alt text of the graphic which is plain and boring, and with no style whatsoever then you could see the text version but not laid out all broken because there wouldn't be any layout, just semantics where it could be arranged in a semantically sensible manner to be fine without any style or layout (or fonts), and yeah you would see the image version too but as far as the site being seen as a repository of semantically organized content then having the image versions of certain key info there beside the text version of that key info could only be seen as an asset to that repository of content..
    I'm afraid I can't follow this well since I don't understand what you're trying to say.

    All I can say is that "fallback" and "broken" are not synonymous in this case. The only way something is broken is if meaning is lost. If you have text that says "Hello World" in Spiffy Font X and it falls back to "Hello World" in Verdana, I don't see what's broken. The designer's intent is not intact, but the content is still comprehensible by the reader and therefore not "broken".

    Quote Originally Posted by linehand View Post
    I don't see how having a really robust fallback option for the use of custom-fonts in a variety of different contexts should be seen as a bad thing.
    It isn't per se. But consider the costs in bandwidth in using multiple solutions simultaneously (including additional HTTP requests); maintenance in image creation, content duplication, extra code complexity; and writing that robust script. But, uh, if you want to do it, I'll stop arguing with you. Go for it.
    For every complex problem, there is an answer that is clear, simple, and wrong.

  • #12
    Regular Coder
    Join Date
    Nov 2009
    Posts
    110
    Thanks
    7
    Thanked 9 Times in 9 Posts
    When your heading falls back to default fonts it is no big deal, however if the heading was overlapping some graphic element in a specific arrangement then with the wrong font it might be way to big and overlap all wrong and become illegible. Of course they are still getting the content, who cares if they can read it right? Semantically the font and the css-fallback are equally irrelevant. When ALL styling is removed is the real fallback.

    So, being that it is all just style adjustments anyway, if you were really concerned with bandwidth you would just send unstyled content but people don't do that for very many websites because style, usability, presentation, and other aspects of design do matter on the web and do impact how well a site will do. So of course I want to have as much control over the different levels of fallback as I possibly can have.

    I want to know what the site will look like with javascript and without javascript, with images and without, with fonts and without, with images and no css, with css and no images, etc. etc.. on all the different browsers. I can also use css to rearrange and restyle certain elements if javascript is enabled. Why wouldn't I want to be able to restyle things a little bit if my custom-fonts are in use? Or use a little css to restyle something if the fonts didn't work? Both the custom fonts and the css to change the style a little are purely presentational so what could be wrong with using presentational controls to adjust presentation for various presentational situations?

    Really I would just like to ask you one simple question though: Is there something wrong with wanting know whether a custom font is working so that some style adjustments can be made?

    Edit: oops, you already had already answered that:
    Originally posted by Linehand
    I don't see how having a really robust fallback option for the use of custom-fonts in a variety of different contexts should be seen as a bad thing.
    Originally posted by Arbitrator
    It isn't per se. But consider the costs in bandwidth in using multiple solutions simultaneously (including additional HTTP requests); maintenance in image creation, content duplication, extra code complexity; and writing that robust script. But, uh, if you want to do it, I'll stop arguing with you. Go for it.
    Except that is pulling all sorts of other things that we might have talked about but weren't actually a part of that question in to it. The question says nothing about using multiple solutions or image replacement. Maybe you aren't using IR either way. The question is much simpler than all that. Just to be able to tell whether custom-fonts are in use and tweak some CSS settings. Exactly the same way I can make my page look good without Javascript but then if JS is present I can automatically run some additional CSS to set things up better for the JS.

    It is not really up to you to decide whether I should or should not send fonts, images, neither, both, or some combination thereof. Both the content and appearance of the site (as well as whatever is needed to achieve them) completely depend on the nature of the site. The ability to make some style changes if custom fonts are supported seems like a totally reasonable and useful feature.

    If anything, it would probably even help to alleviate some of the issues you describe - because you could check first and then just send what is needed to each user agent depending on what they can support. There is no reason you should have to send all your fonts and images just to run the test. You could just send one letter of one font to test and then adjust your CSS accordingly and only send what is needed to whoever needs it (someone else has already come up with a tiny script to do the test with one letter). And mind that this does not even necessarily mean sending images to replace text at all (that is but one possibility among many yet you are very focused on that one), maybe I just want to tweak a couple style rules if custom-fonts are supported.

    Anyway, you make it sound as if wanting to control the appearance of my site through the use of CSS were completely insane... well thanks for your thoughts all the same.
    Last edited by linehand; 11-15-2009 at 06:43 AM.


  •  

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •