Digital Web Magazine

The web professional's online magazine of choice.

In Defense of Fahrner Image Replacement : Comments

By Dave Shea

August 5, 2003

Comments

Mitchell

August 8, 2004 2:42 AM

Dave, very interesting work you guys are doing with the new CSS/XHTML standard and as a fellow designer/developer, thanks for helping us newbies down this exciting but obviously still dark and twisty CSS path.

A couple comments…you mentioned something about xhtml 2.0. I think thats key here. On the one hand we have to remember that the “img” tag, even for screen readers, with all the trillions of images and image tags saturating the web today, are and will be designed to deal with the old-fashioned image tag for some time to come…separation of content from presentation or not. Thats not to say we don’t need to get on board a solution that helps us stay on the separation-of-presentation wagon (its a lil’ ol’ wagon we are on at this point, not a train). What that means is the image tag and sticking content in your page with alt tags is, I think, still a semantic and viable solution, and a very powerful means, as well, in conveying its meaning to a whole host of people, including the blind, what you are saying through your web site using images. On the other hand, with the new stricter XHTML 2.0 and the removal of all kinds of html-based code we have grown so accustomed to using, we do have to get our web designs online with less, and using CSS the way it was designed to be used. But why? Because with xhtml, our sites are for the first time, valid XML! (data islands of sorts) Thats all they are, now, with the new standard, as they should have been when we fist started making web pages. As such it means its the data thats more important…not the design ultimately….not whether we are displaying that image with text behind it, separated or not. Sure, there are some issues about that approaching with newer standards. But I dont think CSS can solve the problem of content versus presentation completely…I dont think it was given that responsibility. XML and XSLT and its family of other tools are, I believe, if you think about it. As designers, we can only take that concept so far….our little wagon can only go so far and so fast.

With this massive push now for xml data online, I think the whole design question of presentation via css only and content separated from that is possibly going to be a moot point, because the future delivery of web content and a huge realm of other web-based data will be more and more via pure xml solutions directly and repurposing of your content anyway, like rss and atom. Most of your “content” power will be directing users to those lean mean pure xml portals that Im certain all sites will have (not that your xhtml is not the most important repurposing of that material). If a screen reader wants to suck down your web text, or a list of valid images for whatever reason, Im certain that a single xml file repurposed via xslt will be able to quickly generate that for them, css excluded. Thats kind of where we are with RSS. Its exciting stuff, if you think about it!

I guess what Im trying to say, is that our struggles with presentation solutions that try to completing dissect content from presentation is an incredibly exciting and powerful concept that we are just now beginning to embrace as designers, but my developer side tells me that it will soon be a very small focus compared to trhe true separation of content from presentation that will form this huge new avalanche of content delivery that xml and xslt versions of your site content will certainly take in the near future….a future where if someone wants to “see” your web page, they may, but your web domain wil also server a whole host of other repurposing of that content via clean rss, xforms, custom web services, b2b content exchanges, syndication, etc. The struggle for a screen reader to find text in an image tag that may be dprecated in ten years anyway, will be nothing compared to the whole realm of data via other xml forms in sites of the future. I hope that makes sense…I think XHTML 2.0 is pointing to what we really need to prepare for. I guess it will be a world where we have custom tags, and modular content delivery and true complex multi-purposing and multi-delivery of our web data in all kinds of alternative ways beyond the brochureware sites we have been accustomed to. I think designers have a hard time seeing the huge train thats coming down the tracks and what thats going to do to how we approach true content delivery, but its going to be allot more exciting, richer, and more complicated that wondering if my extra span or background image has some text to support it. Look out, the XML train is coming!

...so to end, I guess if I was a to gamble on the future and a solution that not only works well now but in the future of custom xhtml tags (and using an FIR solution) I would say having a solution where I can assign any image to any element using a CSS background image would seem to solve the content/presenation problem on the surface. Simply having a simple, readable paragraph or “photo label” beside that image, describing the photograph, would seem to be just as semantic and useable as the fanciest set of hidden tags. Add a title or longdescr to the tag that holds the image and the user has not one but three visible perfectly complaint means of veiwing the image and what it means.

Just some thoughts….keep up the brilliant work on CSS and I’ll keep reading and learning from you guys. I’m one of those who is already swimming in those warm CSS waters. :o)

-MS

Marcus Fridholm

September 23, 2004 10:11 PM

I came up with a solution that seems OK with me. But of course I still have to do a little more “extreme” testing…

The idea is like this (just the style rule as it is all that is necessary):

#element {
height: 60px; /* the image height */
line-height: 60px; /* again */
width: 250px; /* the image width */
text-indent: 250px; /* again */
overflow: hidden; /* clip it */
background: transparent url(sampleheading.png) no-repeat; /* and of course the image */
}

It must be imported to save such old dino’s like NS4 but it seems to work well in both Gecko and MSIE as well as Opera.

I would be really happy if anyone helped me check if it crashes in any app.
I personally like the approach, the simpler the better – just move that text out of the picture :D

Marcus Fridholm

September 23, 2004 10:11 PM

I came up with a solution that seems OK with me. But of course I still have to do a little more “extreme” testing…

The idea is like this (just the style rule as it is all that is necessary):

#element {
height: 60px; /* the image height */
line-height: 60px; /* again */
width: 250px; /* the image width */
text-indent: 250px; /* again */
overflow: hidden; /* clip it */
background: transparent url(sampleheading.png) no-repeat; /* and of course the image */
}

It must be imported to save such old dino’s like NS4 but it seems to work well in both Gecko and MSIE as well as Opera.

I would be really happy if anyone helped me check if it crashes in any app.
I personally like the approach, the simpler the better – just move that text out of the picture :D

Steve Savage

November 4, 2004 6:46 AM

I just use a simple class .hidden for any content I want to hide.

I work for the Cdn Fed Gov, and have had this tested by an internal accessibility group. It works fine for screen readers.

.hidden {
position:absolute;
top:0px;
left:-2000px; /* whatever amount is necessary to move the content off the screen */
}

I use this for any text written for screen readers, but not required for visual display.

Examples: headers of menus, accessibility links, and text replaced by images.

<div class=“hidden”><h2><a name=“menu”>Content Menu</a></h2></div>

<div class=“hidden”>
<h2>Skip to:</h2>
<ul>
<li><a href=”#content”>Content</a></li>
<li><a href=”#menu”>Page Menu</a></li>
</ul>
</div>

<div class=“replacementimage”>
<div class=“hidden”>Stuff to be replaced by image</div>
</div>

Sorry, comments are closed.

Media Temple

via Ad Packs