53  4885 
Kerberos <me@privacy.net> wrote: I followed Dan Cederholm's image replacement tutorial, to replace a header
tag by a logo.
Is there a reason not to just have an image in there?
It's simpler and more accessible.
The h1 is clickable if no CSS is applied but it I replace
it by the logo, the area isn't clickable anymore when I pass the mouse
over the logo. Is there a way to replace a link by an image that will
still be clickable?
Yes. Make sure that the <a> element still exists and that it fills the
full area of the heading. display: block; takes care of the second
part. The first part depends on exactly how you're hiding the real
heading.
Steve
Steve Pugh wrote: Is there a reason not to just have an image in there?
It's simpler and more accessible.
Actully using the image replace ment is very accessible if done right.
"logic_earth" <Th****@gd-studio.com> wrote: Steve Pugh wrote:
Is there a reason not to just have an image in there?
It's simpler and more accessible.
Actully using the image replace ment is very accessible if done right.
The people who promote it claim that it is but the reality is somewhat
different.
Look at a page that uses it with CSS on and Images Off. Some variants
try to solve that issue but seem to end up introducing other problems.
Steve
.oO(logic_earth) Actully using the image replace ment is very accessible if done right.
_All_ image replacement techniques I've seen so far failed with CSS
on/images off. I don't consider that accessible.
Micha
Michael Fesser <ne*****@gmx.net> wrote: Actully using the image replace ment is very accessible if done right.
_All_ image replacement techniques I've seen so far failed with CSS
on/images off. I don't consider that accessible.
You are behind the times: http://www.mezzoblue.com/tests/revis...e-replacement/
The Gilder/Levin method works quite well.
--
Spartanicus
Spartanicus <me@privacy.net> wrote: Michael Fesser <ne*****@gmx.net> wrote:
Actully using the image replace ment is very accessible if done right.
_All_ image replacement techniques I've seen so far failed with CSS
on/images off. I don't consider that accessible.
You are behind the times:
http://www.mezzoblue.com/tests/revis...e-replacement/
The Gilder/Levin method works quite well.
Breaks at larger font sizes - if the text version needs more space
than the background image then the text starts to leak out from under
the image. Setting overflow: hidden; fixes that but then we're back to
a position where it fails for CSS on, Images off.
Steve
Steve Pugh <st***@pugh.net> wrote: The Gilder/Levin method works quite well.
Breaks at larger font sizes - if the text version needs more space
than the background image then the text starts to leak out from under
the image.
I know, that's why I said "quite well". But this does not constitute
"broken" in my vocabulary, I'd classify that merely as a cosmetic quirk.
I'm not a fan of image replacement techniques, I use only one instance
of it on the index page of my personal site. There it holds up up to
200% zooming, above that the text starts leaking out from under the
image.
The only reason I used it was to see how well it worked (or not), after
having used it the only valid reason for using it is imo if it is
imperative that the text is indexed by SEs.
The proper way remains specifying the image's text as alt content, but
I'm not aware of any SE that indexes alt content in this type of
construct:
<h1><img src="fancyheader.png" alt="fancy header text"></h1>
I can imagine a (commercial) situation where indexing of the above by
SEs is vital.
--
Spartanicus
*Spartanicus* <me@privacy.net>:
The proper way remains specifying the image's text as alt content,
You can still have CSS image replacement with this (even without server-
or client-side scripting):
<http://webdesign.crissov.de/temp/ciwas/image-replacement>.
but I'm not aware of any SE that indexes alt content in this type of
construct:
<h1><img src="fancyheader.png" alt="fancy header text"></h1>
<h1><object data="fancyheader.png">fancy header text</object></h1>
should be easier to parse for them, but you'll in turn have problems with
browsers.
--
Your ad here!
Christoph Paeper <ch**************@nurfuerspam.de> wrote: The proper way remains specifying the image's text as alt content,
You can still have CSS image replacement with this
You seem to think that I want image replacement, I do not. Image
replacement techniques are nasty hacks, the only valid reason I can
think of for using it is, as I mentioned, situations where it is
imperative that the text content is indexed by SEs. The fact that an
image's alt content isn't indexed by SEs is a flaw in current SEs, it's
not a flaw in the coding method.
<http://webdesign.crissov.de/temp/ciwas/image-replacement>.
I fail to see the point of this, it's an image replacement technique
(bad), that doesn't fix the one practical problem that the proper
solution suffers from.
--
Spartanicus
Christoph Paeper <ch**************@nurfuerspam.de> wrote: <http://webdesign.crissov.de/temp/ciwas/image-replacement>.
Btw, there are errors in the displayed code.
--
Spartanicus
*Spartanicus* <me@privacy.net>: Christoph Paeper <ch**************@nurfuerspam.de> wrote:
The proper way remains specifying the image's text as alt content,
You can still have CSS image replacement with this
You seem to think that I want image replacement,
It may seem so, but I didn't. (The modern English word 'you' is quite
overload, being used for second persond singular ('thou') and plural
('ye') and non-personal ('one').)
I do not.
I don't neither, by the way.
Image replacement techniques are nasty hacks,
They are (this one offers at least pretty clean, simple HTML and CSS).
Nevertheless people want to and do use them and I think it's important to
remind them of alternatives without or at least with less negative side
effects for surfers. Or to develop such methods.
the only valid reason I can think of for using it is, as I mentioned,
situations where it is imperative that the text content is indexed by
SEs.
That, however, doesn't seem to be the major reason for those, who use
them. They rather want to be able to change the site's appearance,
including heading images, by just CSS. Whether they actually do make use
of that possibility is another issue.
The fact that an image's alt content isn't indexed by SEs is a flaw in
current SEs, it's not a flaw in the coding method.
Indeed, although 'object' is (in theory) much cleaner than 'img' with
'alt'. The reason for the not-indexing is probably the poor quality of
most alternative texts out there. Actually most markup is ignored by SEs
for general incorrect usage of it. <http://webdesign.crissov.de/temp/ciwas/image-replacement>.
I fail to see the point of this, it's an image replacement technique
(bad), that doesn't fix the one practical problem that the proper
solution suffers from.
It's an image replacement technique without extra (empty) 'span's and the
like, that also works with images off, CSS on. So far I didn't look into
an alternative using 'object', because of browser quirks and I don't know
how well Google etc. handle it.
| Btw, there are errors in the displayed code.
Could you please tell me where? I fail to see them. (And I didn't edit the
files since writing the posting you replied to, when I added the contra
point regarding SEs.)
--
"Opportunity is missed by most people
because it is dressed in overalls and looks like work."
Thomas Alva Edison
Christoph Paeper <ch**************@nurfuerspam.de> wrote: the only valid reason I can think of for using it is, as I mentioned,
situations where it is imperative that the text content is indexed by
SEs.
That, however, doesn't seem to be the major reason for those, who use
them. They rather want to be able to change the site's appearance,
including heading images, by just CSS.
I've always wondered what all the IR fuss was about, I thought it was
about SE indexing, but that doesn't strike me as something that the
"dezigners" types who seem to love IR are that concerned with.
Being able to change a sites appearance without editing the html doesn't
strike me as an advantage either, but I'm no designer.
| Btw, there are errors in the displayed code.
Could you please tell me where?
<h1><img src="image-replacement-src.img" alt="Testtext</h1>
--
Spartanicus
Steve Pugh <st***@pugh.net> wrote: http://www.mezzoblue.com/tests/revis...e-replacement/
The Gilder/Levin method works quite well.
Breaks at larger font sizes - if the text version needs more space
than the background image then the text starts to leak out from under
the image. Setting overflow: hidden; fixes that but then we're back to
a position where it fails for CSS on, Images off.
I can't imagine why it would, I just tried it and it appears to cause no
drawbacks here.
--
Spartanicus
Spartanicus <me@privacy.net> wrote: Steve Pugh <st***@pugh.net> wrote:
http://www.mezzoblue.com/tests/revis...e-replacement/
The Gilder/Levin method works quite well.
Breaks at larger font sizes - if the text version needs more space
than the background image then the text starts to leak out from under
the image. Setting overflow: hidden; fixes that but then we're back to
a position where it fails for CSS on, Images off.
I can't imagine why it would, I just tried it and it appears to cause no
drawbacks here.
Why what would what?
The GL method does break at larger font sizes.
Setting overflow: hidden does break if CSS is on and Images are off.
Please post a URL of a demo showing otherwise.
Steve
Steve Pugh <st***@pugh.net> wrote: Breaks at larger font sizes - if the text version needs more space
than the background image then the text starts to leak out from under
the image. Setting overflow: hidden; fixes that but then we're back to
a position where it fails for CSS on, Images off.
I can't imagine why it would, I just tried it and it appears to cause no
drawbacks here.
Why what would what?
As quoted "fail for css on, images off".
The GL method does break at larger font sizes.
Setting overflow: hidden does break if CSS is on and Images are off.
I see what you were referring to now, it breaks when css is on, images
off *and* text is zoomed beyond the size of the image. Not something
that warrants particular concern.
--
Spartanicus
Spartanicus <me@privacy.net> wrote: Steve Pugh <st***@pugh.net> wrote:
Breaks at larger font sizes - if the text version needs more space
than the background image then the text starts to leak out from under
the image. Setting overflow: hidden; fixes that but then we're back to
a position where it fails for CSS on, Images off.
I can't imagine why it would, I just tried it and it appears to cause no
drawbacks here.
Why what would what?
As quoted "fail for css on, images off".
The GL method does break at larger font sizes.
Setting overflow: hidden does break if CSS is on and Images are off.
I see what you were referring to now, it breaks when css is on, images
off *and* text is zoomed beyond the size of the image. Not something
that warrants particular concern.
Really?
Text too small to read - increase text size.
Text as images too small to read - disable images and read the alt
attribute instead.
The same people will be doing both actions.
Steve
Steve Pugh <st***@pugh.net> wrote: I see what you were referring to now, it breaks when css is on, images
off *and* text is zoomed beyond the size of the image. Not something
that warrants particular concern.
Really?
Text too small to read - increase text size.
Text as images too small to read - disable images and read the alt
attribute instead.
The same people will be doing both actions.
Good point, my view of image replacement is skewed because the only
instance where I've used it uses an image with very large text and more
than usual room for text expansion.
--
Spartanicus
"Unknown User" <me@privacy.net> wrote: On Thu, 13 Jan 2005 18:22:24 +0000, Spartanicus <me@privacy.net> wrote:
Replying to old threads poses problems.
As quoted "fail for css on, images off".
This thread has been purged from my message base due to it's age, I've
no idea what this quote refers to.
Then what image replacement method do you suggest?
The only good image replacement technique is no image replacement.
What makes you think you need one?
--
Spartanicus
"Unknown User" <me@privacy.net> wrote: The only good image replacement technique is no image replacement.
What makes you think you need one?
SEO :)
There's your answer, code for humans, not some (broken) bot.
<h1><img src="fancytext" alt="Fancy text"></h1>
--
Spartanicus
Spartanicus wrote: "Unknown User" <me@privacy.net> wrote:
The only good image replacement technique is no image replacement.
What makes you think you need one?
SEO :)
There's your answer, code for humans, not some (broken) bot.
<h1><img src="fancytext" alt="Fancy text"></h1>
I'd use it because the fancy text image is not part of the page content,
which is what putting it in an <img> element implies.
Another way of thinking about it: what happens when I turn off CSS when
using the method you recommend? All the font style, colours and borders,
any decoration that isn't part of the user stylesheet or UA stylesheet
is gone--but that bit of text decoration remains, faking its way in
among the <body> content.
Text styling *should* be done via CSS. Because of the primitive state of
typography on the web--or because one might want to do something really
fancy with header text, approaching calligraphy rather than
mass-produced type (which computers make possible for arbitary
text)--one may resort to image replacement. That doesn't mean we
shouldn't do IR in CSS.
"Firas D." <us****@firasd.org> wrote: The only good image replacement technique is no image replacement.
What makes you think you need one?
SEO :)
There's your answer, code for humans, not some (broken) bot.
<h1><img src="fancytext" alt="Fancy text"></h1>
I'd use it because the fancy text image is not part of the page content,
which is what putting it in an <img> element implies.
Only in rare occasions can text (or an image of text) rightfully be
considered *not* to be content. In which case SEO doesn't apply as a
reason for using IR. Note that coding decorative images as background
images fails to free up the occupied screen space in css on, images off
mode, this is a daily annoyance for me as someone who browses with
images off.
Using the image element doesn't imply content, supply null alt content
for decorative images. Ideally decorative images should disappear when
css is off, alas due to limited support for the content:url() css
method, using the image element can be considered as the best option for
decorative images.
Another way of thinking about it: what happens when I turn off CSS when
using the method you recommend? All the font style, colours and borders,
any decoration that isn't part of the user stylesheet or UA stylesheet
is gone--but that bit of text decoration remains, faking its way in
among the <body> content.
Hardly an issue, using images of text prevents people from zooming the
text with images on, which is a real drawback.
Text styling *should* be done via CSS. Because of the primitive state of
typography on the web--or because one might want to do something really
fancy with header text, approaching calligraphy rather than
mass-produced type (which computers make possible for arbitary
text)--one may resort to image replacement.
Some might consider typographical expression as an excuse to use images
of text instead of real text, it does not form an argument for IR.
--
Spartanicus
Spartanicus wrote: Only in rare occasions can text (or an image of text) rightfully be
considered *not* to be content.
The text is content. The image is *not*.
Using the image element doesn't imply content, supply null alt content
for decorative images. Ideally decorative images should disappear when
css is off, alas due to limited support for the content:url() css
method, using the image element can be considered as the best option for
decorative images.
<snip> Some might consider typographical expression as an excuse to use images
of text instead of real text, it does not form an argument for IR.
Ah. My position is not for IR; rather, it's against stuffing decorative
images in the <img> element.
So, can we agree that this:
<style type="text/css">
body {background-color: white;}
#head {content:before (url:'head.png'); color: white; }
</style>
<h1><span id="head">IE Is Pathetic</span></h1>
Is better than this?:
<h1><img src="head.png" alt="IE Is Pathetic" /></h1>
Ideally, in the first example we shouldn't need an extra <span> and we
should be able to say #head {visibility: hidden;} without breaking
content generation, but alas.
"Firas D." <us****@firasd.org> wrote: Only in rare occasions can text (or an image of text) rightfully be
considered *not* to be content.
The text is content. The image is *not*.
There is content (required) and decorative (optional). Thus a bitmapped
representation of text is content unless it can be argued that it serves
an optional purpose only.
Using the image element doesn't imply content, supply null alt content
for decorative images. Ideally decorative images should disappear when
css is off, alas due to limited support for the content:url() css
method, using the image element can be considered as the best option for
decorative images.
<snip> Some might consider typographical expression as an excuse to use images
of text instead of real text, it does not form an argument for IR.
Ah. My position is not for IR; rather, it's against stuffing decorative
images in the <img> element.
So what practical coding method do you suggest for decorative images?
So, can we agree that this:
<style type="text/css">
body {background-color: white;}
#head {content:before (url:'head.png'); color: white; }
#head{color:white}
#head:before{content:url('head.png')}
</style>
<h1><span id="head">IE Is Pathetic</span></h1>
Is better than this?:
<h1><img src="head.png" alt="IE Is Pathetic" /></h1>
Better for what? You've not specified what you think the first example
should achieve, and what the "head.png" image portrays.
Also note that IE isn't the only browser that doesn't support url based
generated content (Opera <=6 are other examples).
Ideally, in the first example we shouldn't need an extra <span>
The span in your example is superfluous.
--
Spartanicus
Spartanicus wrote: "Firas D." <us****@firasd.org> wrote:
So what practical coding method do you suggest for decorative images?
I'm not as interested in the practical here as in the ideal :) In terms
of practice, I intend to use IR if the need arises. I hope they come up
with a method that addresses your CSS on + images off issue; sounds
irritating.
Better for what?
Semantics. Accessibility. Usability. Just general web-design practice.
#head{color:white}
#head:before{content:url('head.png')}
</style>
<h1><span id="head">IE Is Pathetic</span></h1>
Is better than this?:
Ideally, in the first example we shouldn't need an extra <span>
The span in your example is superfluous.
Hmm, but that would put the heading image 'before' the h1 tag, would it
not? (Not that that matters when the text itself is in <h1>.)
But when I try it out (eg. http://firasd.org/weblog/2005/02/dem...tyle=barchart), it
seems to insert itself in the flow inside the elements that it's
generated before. I wonder whether the spec clarifies this (does
#x:content:before put generated content before #x or within the #x
element); it doesn't seem to on first glance.
"Firas D." <us****@firasd.org> wrote: So what practical coding method do you suggest for decorative images?
I'm not as interested in the practical here as in the ideal :) In terms
of practice, I intend to use IR if the need arises.
What need?
I hope they come up
with a method that addresses your CSS on + images off issue; sounds
irritating.
Several already exist, one I've previously pointed out.
Better for what?
Semantics. Accessibility. Usability. Just general web-design practice.
Your quoting style is "creative", this usually points to an attempt to
hide something. I note that you still are not providing an explanation
as to what your example should do (that wasn't obvious from the code you
posted, even if we ignore the coding errors). You also appear to
contradict yourself, first you declare to only be interested in
theoretically optimal methods, then you list two phrases that are
difficult to consider outside of a practical context, the same applies
to "general web-design practice".
Ideally, in the first example we shouldn't need an extra <span>
The span in your example is superfluous.
Hmm, but that would put the heading image 'before' the h1 tag, would it
not?
In the code you posted the span serves no purpose.
http://firasd.org/weblog/2005/02/dem...style=barchart
Could not connect to remote server.
--
Spartanicus
Spartanicus wrote: "Firas D." <us****@firasd.org> wrote:
Your quoting style is "creative", this usually points to an attempt to
hide something.
Excuse the misquote, it was because I had snipped that part, then
decided to address it, so went back and copied it into the drafting
window rather than hit 'reply' again.
I note that you still are not providing an explanation as to what your example should do (that wasn't obvious from the code you
posted, even if we ignore the coding errors).
I proposed it as a CSS way to use images as text, apart from IR and
instead of putting it in the <img> element. I'd gotten the idea from
your sentence, "Ideally decorative images should disappear when css is
off, alas due to limited support for the content:url() css method, using
the image element can be considered as the best option for decorative
images."
So it was a code implementation for making decorative images disappear
when CSS is off, using content:url(). Were you thinking of some other
implementation of content:url()? The head.png is a decorative graphic of
the heading text.
Hmm, but that would put the heading image 'before' the h1 tag, would it
not?
In the code you posted the span serves no purpose.
I realized. I concur. I was just wondering what the tree looked like
when the span is removed. Does the browser assume that, given:
<style type="text/css">
#head {color: white;}
#head:before {content:url('head.png');}
</style>
<html><body>
<h1 id="head">IE Is Pathetic</h1>
</body></html>
That it should render as (a):
<html><body>
<img src="head.png" />
<h1 id="head">IE Is Pathetic</h1>
</body></html>
or (b):
<html><body>
<h1 id="head"><img src="head.png" />IE Is Pathetic</h1>
</body></html>
http://firasd.org/weblog/2005/02/dem...style=barchart
Could not connect to remote server.
Works for me. Try again? It's not essential to the issue anyway.
"Firas D." <us****@firasd.org> wrote: I note that you still are not providing an explanation
as to what your example should do (that wasn't obvious from the code you
posted, even if we ignore the coding errors).
I proposed it as a CSS way to use images as text, apart from IR and
instead of putting it in the <img> element. I'd gotten the idea from
your sentence, "Ideally decorative images should disappear when css is
off, alas due to limited support for the content:url() css method, using
the image element can be considered as the best option for decorative
images."
An image with a bitmapped representation of text accompanied by a
textual alternative/replacement is not decorative, it is content.
I was just wondering what the tree looked like
when the span is removed. Does the browser assume that, given:
<style type="text/css">
#head {color: white;}
#head:before {content:url('head.png');}
</style>
<html><body>
<h1 id="head">IE Is Pathetic</h1>
</body></html>
That it should render as (a):
<html><body>
<img src="head.png" />
<h1 id="head">IE Is Pathetic</h1>
</body></html>
or (b):
<html><body>
<h1 id="head"><img src="head.png" />IE Is Pathetic</h1>
</body></html>
B http://firasd.org/weblog/2005/02/dem...style=barchart
Could not connect to remote server.
Works for me. Try again? It's not essential to the issue anyway.
Moreover the relevance to this thread is unclear to me, and I have a
feeling that explaining it would only cause more confusion.
--
Spartanicus
in comp.infosystems. www.authoring.stylesheets, Firas D. wrote: I realized. I concur. I was just wondering what the tree looked like
when the span is removed. Does the browser assume that, given:
<style type="text/css">
#head {color: white;}
#head:before {content:url('head.png');}
</style>
<h1 id="head">IE Is Pathetic</h1>
or (b):
<h1 id="head"><img src="head.png" />IE Is Pathetic</h1>
B. See spec. http://firasd.org/weblog/2005/02/dem...style=barchart
Could not connect to remote server.
Works for me. Try again? It's not essential to the issue anyway.
Seems to be extremily slow server, and I never got CSS file. I'm on fast
connection (100Mb/s)
--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Utrecht, NL.
Spartanicus wrote: "Firas D." <us****@firasd.org> wrote:I proposed it as a CSS way to use images as text, apart from IR and
instead of putting it in the <img> element. I'd gotten the idea from
your sentence, "Ideally decorative images should disappear when css is
off, alas due to limited support for the content:url() css method, using
the image element can be considered as the best option for decorative
images."
An image with a bitmapped representation of text accompanied by a
textual alternative/replacement is not decorative, it is content.
We're just going round in circles here... I disagree, but to each his own. http://firasd.org/weblog/2005/02/dem...style=barchart
Could not connect to remote server.
Works for me. Try again? It's not essential to the issue anyway.
Moreover the relevance to this thread is unclear to me, and I have a
feeling that explaining it would only cause more confusion.
It was just relevant to the question about the implicit tree in content
generation. And the answer (that 'b' is rendered) fit in with my
findings in that example.
Thanks for your responses.
"Firas D." <us****@firasd.org> wrote: An image with a bitmapped representation of text accompanied by a
textual alternative/replacement is not decorative, it is content.
We're just going round in circles here... I disagree, but to each his own.
This is not an issue on which we can agree to disagree, please state
your reasons for why you think it is decorative.
--
Spartanicus
Spartanicus wrote: "Firas D." <us****@firasd.org> wrote:
An image with a bitmapped representation of text accompanied by a
textual alternative/replacement is not decorative, it is content.
We're just going round in circles here... I disagree, but to each his own.
This is not an issue on which we can agree to disagree, please state
your reasons for why you think it is decorative.
Because I feel that ideally, the only thing harboured in <img> elements
should be stuff the page can't do without, such as photos in a gallery
or something.
Now it's a murky issue, and I can see your point too--that if the
appropriate alternate text isn't alt="", then it's hardly decorative.
I just think that when CSS is dropped, decoration--and this includes
stylized text images--should go away. Otherwise there's something
suboptimal in the techniques being employed. I'd also like to have the
possibility of alternate styesheets changing the way the text is
stylized. So on and so forth--basically, I think that images of text are
part of a page's style, not its structure or content. The text the image
is representating /is/ the content.
Reasonable people might disagree :)
in comp.infosystems. www.authoring.stylesheets, Firas D. wrote: Spartanicus wrote: "Firas D." <us****@firasd.org> wrote:
An image with a bitmapped representation of text accompanied by a
textual alternative/replacement is not decorative, it is content.
We're just going round in circles here... I disagree, but to each his own.
This is not an issue on which we can agree to disagree, please state
your reasons for why you think it is decorative.
Because I feel that ideally, the only thing harboured in <img> elements
should be stuff the page can't do without, such as photos in a gallery
or something.
What you feel is irrelevant to us.
Now it's a murky issue, and I can see your point too--that if the
appropriate alternate text isn't alt="", then it's hardly decorative.
Exactly.
I just think that when CSS is dropped, decoration--and this includes
stylized text images--should go away.
Well, that is exactly what happens on most text browsers, unless some
special setting is used. Have you ever actually used text only browser?
Lynx, Links...
And in browser where there is possibility to show image, it makes great
sence to show image placeholdersborders. Notice that this is meaningful
data, not just decoration (just like links are blue and underlined is not
just meaningless decoration). It means that it is alt text, and you can
show image (for example by right click menu)
Otherwise there's something
suboptimal in the techniques being employed. I'd also like to have the
possibility of alternate styesheets changing the way the text is
stylized.
Will be in CSS3. And still it is better to use
<img src="default" alt="Foobar">
And in alternative style
img[src="default"] {content:url(alternative)}
(notice that current support for attribute selector src is not
implemented similarly on different browser...)
So on and so forth--basically, I think that images of text are
part of a page's style, not its structure or content. The text the image
is representating /is/ the content.
If you use text images only for small stylish issues, you are doing bad
thing in first place....
Reasonable people might disagree :)
Yes, and unreasonable might agree.
--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Utrecht, NL.
Lauri Raittila wrote: Because I feel that ideally, the only thing harboured in <img> elements
should be stuff the page can't do without, such as photos in a gallery
or something.
What you feel is irrelevant to us.
Ray of sunshine, aren't you? Spartanicus prompted me to explain, hence I
did, using 'I feel' as a way to avoid saying 'I think' many times over.
Because, you know, I am open to changing my point of view based on
whatever he had to say in response. I'd just use imperatives otherwise,
wouldn't I? Maybe that'd satisfy you. Jeez.
I'm really not fond of the line-by-line nitpick, but yes, any of the
methods discussed in this thread work just fine in Lynx. I'm not worried
about Lynx when discussing the merits of putting <img> elements in the
body for stylized text vs. putting in plain text and using content
generation to achieve the same.
in comp.infosystems. www.authoring.stylesheets, Firas D. wrote: Lauri Raittila wrote:
Because I feel that ideally, the only thing harboured in <img> elements
should be stuff the page can't do without, such as photos in a gallery
or something.
What you feel is irrelevant to us.
Ray of sunshine, aren't you? Spartanicus prompted me to explain, hence I
did, using 'I feel' as a way to avoid saying 'I think' many times over.
Well, that is juat as irrelevant, if you don't tell us reason why you
think so.
Because, you know, I am open to changing my point of view based on
whatever he had to say in response. I'd just use imperatives otherwise,
wouldn't I? Maybe that'd satisfy you. Jeez.
Problem is that you didn't really have many arguments to support your
thoughts, and you don't seem to answer our questions about them.
I'm not worried
about Lynx when discussing the merits of putting <img> elements in the
body for stylized text vs. putting in plain text and using content
generation to achieve the same.
Then, could you say what you are worried?
--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Utrecht, NL.
Lauri Raittila wrote: in comp.infosystems.www.authoring.stylesheets, Firas D. wrote:
Problem is that you didn't really have many arguments to support your
thoughts, and you don't seem to answer our questions about them.
Maybe we're just unable to communicate--I haven't been on Usenet for a
while and find line-by-line nitpicks extremely tangential to the
discussion, so snip most of the stuff I reply to. Apologies.
I'm not worried
about Lynx when discussing the merits of putting <img> elements in the
body for stylized text vs. putting in plain text and using content
generation to achieve the same.
Then, could you say what you are worried?
Semantics. Is an image really a heading?
Or, here, let me turn it around: Is there a reason you see that content
generation for stylized text is worse than putting <img> elements in
<h1>? I'd love to know.
(Apart from UA support--because if content generation fails then they
get a good old plain text headline, and nothing's better than that!)
"Firas D." <us****@firasd.org> wrote: An image with a bitmapped representation of text accompanied by a
textual alternative/replacement is not decorative, it is content.
We're just going round in circles here... I disagree, but to each his own.
This is not an issue on which we can agree to disagree, please state
your reasons for why you think it is decorative.
Because I feel that ideally, the only thing harboured in <img> elements
should be stuff the page can't do without, such as photos in a gallery
or something.
I'm interested if you can argue a rationale to justify that feeling. You
may feel that all hamsters should be painted orange, that doesn't make
it correct.
Now it's a murky issue, and I can see your point too--that if the
appropriate alternate text isn't alt="", then it's hardly decorative.
There's nothing murky about it, imo you are plainly wrong. Whether or
not something should be considered as content has a fundamental effect
on how it should be coded.
I just think that when CSS is dropped, decoration--and this includes
stylized text images--should go away.
No argument that decoration should disappear when css is switched off,
but you've not produced a rationale as to why this should include
essential content.
I'd also like to have the
possibility of alternate styesheets changing the way the text is
stylized.
Using bitmapped representations of text is a practical hack, no matter
how it's implemented (this includes content:url() methods). Ideally we'd
have css methods available to us to for example create drop shadows
behind text, this isn't the case yet. You can't attack what is a
practical hack on the ground of that it is theoretically sub optimal,
that much is obvious.
--
Spartanicus
Spartanicus wrote: "Firas D." <us****@firasd.org> wrote:
Using bitmapped representations of text is a practical hack, no matter
how it's implemented (this includes content:url() methods)
This does get to the root of the issue. Agreed. It's also jarring
because the bitmap is unselectable and unsearchable.
Ideally we'd have css methods available to us to for example create drop shadows
behind text, this isn't the case yet.
This hack will not go away. It should be somehow provided for in the specs.
Check this out: http://photomatt.net/2005/02/04/lifehacker/
That <h2> that says Lifehacker, notice the loop around the top of the L?
See the snow on the letters spelling the <h1>?
No CSS can anticipate that.
(Turn of CSS, and beautifully enough, the bitmapped text is gone.)
Firas D. wrote: Spartanicus wrote:
Using bitmapped representations of text is a practical hack, no matter
how it's implemented (this includes content:url() methods)
This hack will not go away. It should be somehow provided for in the specs.
Look what I found: http://www.w3.org/TR/2003/WD-css3-co...14/#inserting3
I believe that this should take care of the issue, should it not?
And those who can't abide by it can just suppress content replacement
for h1, h2, h3 in their user style sheets.
in comp.infosystems. www.authoring.stylesheets, Firas D. wrote: Lauri Raittila wrote: in comp.infosystems.www.authoring.stylesheets, Firas D. wrote:
Then, could you say what you are worried?
Semantics. Is an image really a heading?
Depends on image, of course. But if you replace some text that is heading
by image that is bit better to come up with your message, then image is
of course content.
If that image doesn't have such function, then it should not replace
content.
Or, here, let me turn it around: Is there a reason you see that content
generation for stylized text is worse than putting <img> elements in
<h1>? I'd love to know.
It is not very often that these are semantically identical cases, but
when they are, there is technical reason that they don't usually work,
when images are off.
(Apart from UA support--because if content generation fails then they
get a good old plain text headline, and nothing's better than that!)
You forget that CSS/image support is not that simple. It is entirely
possible to turn on both, one or neither.
--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Utrecht, NL.
in comp.infosystems. www.authoring.stylesheets, Firas D. wrote: Spartanicus wrote: "Firas D." <us****@firasd.org> wrote:
Using bitmapped representations of text is a practical hack, no matter
how it's implemented (this includes content:url() methods)
This does get to the root of the issue. Agreed. It's also jarring
because the bitmap is unselectable and unsearchable.
IE does select images. Image replacement methods don't help on selecting
stuff.
Images are not unsearchable (alt text).
Ideally we'd have css methods available to us to for example create drop shadows
behind text, this isn't the case yet.
This hack will not go away. It should be somehow provided for in the specs.
Well, it is coming to be.
Check this out:
http://photomatt.net/2005/02/04/lifehacker/
That <h2> that says Lifehacker, notice the loop around the top of the L?
See the snow on the letters spelling the <h1>?
I would think that text with snow on letters, as well as other with loop
are content, because they clearly are logo like stuff.
No CSS can anticipate that.
Well, relatively easy for latter, find unicode character for infinity and
use it, or image of it.
(Turn of CSS, and beautifully enough, the bitmapped text is gone.)
Turn off images and you see nothing.
Also notice that alt text on image on upper right is worse than
inexistant.
--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Utrecht, NL.
"Firas D." <us****@firasd.org> wrote: Using bitmapped representations of text is a practical hack, no matter
how it's implemented (this includes content:url() methods) This hack will not go away. It should be somehow provided for in the specs.
Meaning?
Look what I found:
http://www.w3.org/TR/2003/WD-css3-co...14/#inserting3
I believe that this should take care of the issue, should it not?
There are probably other proposed methods in css 3 that do (in part)
attempt [1] to provide more control over text decoration, but generated
content isn't one of them.
[1] I don't expect these upcoming methods to be able to replace current
practices, the people who draft css specs imo don't understand style and
design one bit.
--
Spartanicus
Spartanicus <me@privacy.net> writes: [1] I don't expect these upcoming methods to be able to
replace current practices, the people who draft css specs
imo don't understand style and design one bit.
Oh dear. Being typographically somewhat naïve (although not
a complete ignoramus), I had vaguely hoped that they might
understand it at least one bit (possibly even a whole byte),
because they clearly aren't too hot on specifying formal
languages either, and without that, there isn't much left.
--
Jón Fairbairn Jo***********@cl.cam.ac.uk
Spartanicus wrote: The only good image replacement technique is no image
replacement.
code for humans, not some (broken) bot.
I agree in principle. But Google does not index alt text unless the alt
text is for an image that is part of an <a> element. I suppose they do
that to prevent people from alt-spamming, e.g.,
<img src="myCampingTrip.jpg" alt="Britney Spears free music">
or some such nonsense. In the end, honest markup fails because some
people are not honest in their markup.
<h1><img src="fancytext" alt="Fancy text"></h1>
That is the best solution for humans, certainly.
--
Brian
*Spartanicus* <me@privacy.net>:
[1] I don't expect these upcoming methods to be able to replace current
practices, the people who draft css specs imo don't understand style and
design one bit.
Well, you are free to raise your concerns on <ww*******@w3.org>.
--
"If you never fall, you dance in constant fear of falling."
Suzanne Farrell
Lauri Raittila wrote: in comp.infosystems.www.authoring.stylesheets, Firas D. wrote: This hack will not go away. It should be somehow provided for in the specs.
Well, it is coming to be.
Sweet. Could you refer me to some relevant properties/selectors?
Firas D. wrote: Lauri Raittila wrote:
in comp.infosystems.www.authoring.stylesheets, Firas D. wrote:
This hack will not go away. It should be somehow provided for in the
specs.
Well, it is coming to be.
Sweet. Could you refer me to some relevant properties/selectors?
I meant, refer some CSS 3 properties/selectors to me that are relevant
to replacing elements with images.
in comp.infosystems. www.authoring.stylesheets, Firas D. wrote: Firas D. wrote: Lauri Raittila wrote:
in comp.infosystems.www.authoring.stylesheets, Firas D. wrote:
This hack will not go away. It should be somehow provided for in the
specs.
Well, it is coming to be.
Sweet. Could you refer me to some relevant properties/selectors?
I meant, refer some CSS 3 properties/selectors to me that are relevant
to replacing elements with images.
I already did (content:url()). Example works on Opera. But implemention
sucks big time. (so if images are turned of, you still don't see anything
meaningful)
There is/has been discussion about what else should/shouldn't be there,
and how things should exactly be, but I'm pretty sure something will be
in CSS3
You can google css3 and content to find the reference. It's first one. My
browser died while doing it, and since it is 2:30am I think I better not
start it again...
--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Utrecht, NL. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Jeff Gillingham |
last post by:
I'm using a stylesheet to place a small 'background image' in the
upper left corner of several pages. Is there a simple way of making
that image a clickable link? Thanks.
|
by: inonzuk |
last post by:
Hi everyone,
I'm new to javascript and have the following problem:
I have two image buttons:
1)
<td><a href="http://localhost/gamerules.php" target="mainwindow"><img
onMouseOver="return...
|
by: crazychrisy54 |
last post by:
Hi there
I just wondered if there is any way using GD to insert a clickable
button or some clickable text into a image? It is possible to create
images for buttons but what if you want a...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
| |
