Want to remove img-border w/ xhtml, not html

[Russell Hoover]

I want to make sure that no border (around a specific small "blog-button"
image) ever appears in FF or IE, or any other browswer. I couldn't seem do
it with xhtml, so I reverted to

border="0"

inside the "img" tag. This of course does not validate as xhtml. it does
what I want it to do (gets rid of the border, in both browsers), but I want
all my code to be validated, well-formed xhtml.

How might I do this correctly using either xhtml or css?

The image in question is at <http://rjbox.net, about halfway down the
page.

The code in question is here:

99 Should you happen to agree with this you&rsquo;ll appreciate the
100 philosophy over at <a href="http://no-www.org"><img
101 src="http://no-www.org/images/blog-button.gif"
102 alt=" No-www.org "
103 title=" No-www.org "
104 border="0" /></a: “Succinctly, use of the www subdomain is
105 redundant and time consuming to communicate. The internet, media, and
106 society are all better off without it.”&nbsp;<br /><br />

--
// [e-mail] //

[John Hosking]

Russell Hoover wrote:

I want to make sure that no border (around a specific small "blog-button"
image) ever appears in FF or IE, or any other browswer. I couldn't seem do
it with xhtml, so I reverted to

border="0"

inside the "img" tag. This of course does not validate as xhtml.

It doesn't validate as HTML 4.01 strict either.

it does
what I want it to do (gets rid of the border, in both browsers), but I want
all my code to be validated, well-formed xhtml.

When people say that here, someone invariably comes along and asks /why/
you want that. Usually the poster doesn't know, or thinks they know
(they want the most current code). Be aware (perhaps you already are)
that XHTML is not all it's cracked up (or talked up) to be. Chances are,
you really ought to be using HTML 4.01 Strict. Especially since... well,
see my comments below.

>
How might I do this correctly using either xhtml or css?

You make it sound like they're mutually exclusive. They're not; use both.

>
The image in question is at <http://rjbox.net, about halfway down the
page.

You were close; use a img { border-style: none; } . This will apply to
all the images in links rather than just the one you asked about, but
that's what this particular page specifies anyway.

Maybe I also be so bold as to offer a few other comments? Since you're
already styling (and you seem to care so much about "good XHTML"), get
rid of the extra <brtags everywhere. First of all, they are not XHTML
either: you need to close all elements, here with <br/>. Second of all,
you don't need them and they are neither semantically correct nor
flexible. Where you want to modify spacing for an element, use a margin
(or padding) style. E.g., p {margin-bottom: 2em;}.

Of course, you'll then have to add actual <ptags. Seems you haven't
really marked up your code at all. Most of the text is a big long DIV:
<div class="justify">. Trade that in for a <p>, add <pand </ptags to
deliminate paragraphs (that's what they're for), and style the <pwith
align:justify (I prefer align:left because justify can be hard to read,
but you choose. If you change your mind you can change it quickly in one
place, the .css file).

Your CSS rules for a elements should be in the order
link-visited-hover-active, otherwise the cascading won't work out the
way you probably expect. (Google for "Las Vegas Has Animals" ...)

On all your images, you can apply an id and then style the dimensions.
Replace height="37" width="90" with CSS:
#vimimg { height:37px; width:90px; }

Also, you might rethink your alt content. The titles are okay ("Built
with Vim"), but for an alt attribute I'd put something like "Vim logo"
because, well, that's what the image is. In any case, I would definitely
get rid of the extra spaces in the alt texts; I don't know how screen
readers react to them.

You have a bunch of &nbsp in your <title>. What line-breaking do you
expect the title to suffer without them? In any case, I believe &nbsp;
is not valid XHTML. Check the W3C docs.

Your meta tags are not self-closed as XHTML requires, either.

You're serving to all user-agents as Content-Type: text/html.

I'm more convinced than ever that you ought to just replace your doctype
with one for HTML 4.01 strict, validate it, and relax.

HTH. GL!
--
John

[Jukka K. Korpela]

Scripsit John Hosking:

You were close; use a img { border-style: none; }

Was he? After your analysis of the page, I'm reluctant to take any look at,
so I can't tell whether there's anything close to this CSS construct there.

Anyway, it does not really satisfy the request "I want to make sure that no
border (around a specific small "blog-button" image) ever appears in FF or
IE, or any other browswer." Surely a user style sheet like
a img { border-style: solid !important; }
(or an equivalent browser setting) beats the rule in the author's style
sheet.

Of course, the request was utterly foolish, as is the idea of using a
button-like image instead of a link inside text. By the way, when
"successful", removing the border also removes the essential distinction
between visited and unvisited (and hovered and active) links.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

[Chris Morris]

John Hosking <Jo**@DELETE.Hosking.name.INVALIDwrites:

Also, you might rethink your alt content. The titles are okay ("Built
with Vim"), but for an alt attribute I'd put something like "Vim logo"
because, well, that's what the image is.

I'd completely disagree - if the purpose of the image (when visible)
is to say that the document is built with Vim, then the alt text
should be "Built with Vim".

If the purpose of the image is to show what the Vim logo looks like,
then "Vim logo" might be okay, though "The Vim logo is
[description]" would probably be better.

I think the general best rule for alt text is to consider what text
you *would* place there if someone had deleted all your image folders
and you wanted the page to still make sense to readers while the image
was retrieved from backups.

--
Chris

[Michael Fesser]

..oO(John Hosking)

>Also, you might rethink your alt content. The titles are okay ("Built
with Vim"), but for an alt attribute I'd put something like "Vim logo"

Nope.

>because, well, that's what the image is.

The 'alt' attribute doesn't describe the image, but _replaces_ it in
case the image can't be shown.

Micha

[John Hosking]

Chris Morris wrote:

John Hosking writes:

>>Also, you might rethink your alt content. The titles are okay ("Built
with Vim"), but for an alt attribute I'd put something like "Vim logo"
because, well, that's what the image is.

I'd completely disagree - if the purpose of the image (when visible)
is to say that the document is built with Vim, then the alt text
should be "Built with Vim".

Okay, but you don't have to *completely* disagree. ;-)

In any case, if we go with this argument, he should put "Created with
Vim," because that is the phrase it turns out actually appears on the
image. But I started with the assumption that if the meaningful content
represented by that gif is exactly the same as the discernible text in
the image, then the gif might as well be replaced with the actual text,
"Created with Vim." But since the gif is there, it must be to catch the
eye with the graphical smoothness and worldwide recognition of the Vim
logo. Here's a compromise suggestion: alt="'Created with Vim' logo".

>
If the purpose of the image is to show what the Vim logo looks like,
then "Vim logo" might be okay, though "The Vim logo is
[description]" would probably be better.

Okay, except I suppose neither of us expect anyone to care about a
design description of the logo. More likely is that the purpose is to
use the recognition value of the logo. *Most* likely is that he put the
gif on his page because he could. ;-)

>
I think the general best rule for alt text is to consider what text
you *would* place there if someone had deleted all your image folders
and you wanted the page to still make sense to readers while the image
was retrieved from backups.

That sounds like a good rule. My rule has been to put some clue as to
what the image *is* (without so much about why it's there). The title
attribute can provide a hint as to what the image *represents*. I'll
have to think about your rule, though. What do blind visitors want? What
do screen readers work best with?

--
John (disagreeing only *partially*, at most)

[Chris Morris]

John Hosking <Jo**@DELETE.Hosking.name.INVALIDwrites:

That sounds like a good rule. My rule has been to put some clue as to
what the image *is* (without so much about why it's there). The title
attribute can provide a hint as to what the image *represents*. I'll
have to think about your rule, though. What do blind visitors want?
What do screen readers work best with?

Having tried screen readers a bit, I think it's about the same as for
text browsers - it works better if there's no obvious clue that
there's an image there at all (in general: exceptions for thumbnails,
galleries, etc. where the image(s) are the major part of the content).

There's trial versions of screen readers and speech browsers freely
available (JAWS and IBM Home Page Reader seem to be two commonly used
ones) - I'd recommend downloading them and trying them out (with the
monitor off, of course!). Once you've tried them and know roughly what
it feels like to use them, you can probably then manage simulating
them with a text browser such as Lynx.

(I don't recommend just using Lynx without trying a speech-based
browser at all, because while what they can parse and display is
similar, the display method is very different, and that does need
considering)

--
Chris

[John Hosking]

Michael Fesser wrote:

.oO(John Hosking)

>>Also, you might rethink your alt content. The titles are okay ("Built
with Vim"), but for an alt attribute I'd put something like "Vim logo"

Nope.

>>because, well, that's what the image is.

The 'alt' attribute doesn't describe the image, but _replaces_ it in
case the image can't be shown.

Hello Micha

You seem to take the same view as Chris Morris, the value of which I can
easily see (um, not just agreeing with Chris, I mean the actual
viewpoint...).

I think I have been working from my readings which included the page at
http://www.access-board.gov/sec508/g...194.22.htm#(a), which contains
as example (sadly, there aren't more):
HTML Source Code: <img src="art/logo-green.gif" alt="Access Board Logo">

Even fewer examples(!) are to be found at the W3C:
http://www.w3.org/TR/WAI-WEBCONTENT/...ext-equivalent
http://www.w3.org/TR/WAI-WEBCONTENT-...ext-equivalent
http://www.w3.org/TR/WCAG10-CORE-TECHS/#text-equivalent
the above last includes this: "A good test to determine if a text
equivalent is useful is to imagine reading the document aloud over the
telephone. What would you say upon encountering this image to make the
page comprehensible to the listener?" On the phone I'd have to say,
"...and then there's a logo that says 'Created with Vim'."
The only example I found on the W3C accessiblity pages is at
http://www.w3.org/TR/WCAG10-HTML-TEC...ext-equivalent, namely
Example <IMG src="magnifyingglass.gif" alt="Search">

So, as I now see it, the United States Access Board tends to think more
literally, while the W3C is leaning toward the functionality/useful
purpose of an image or object. Of course, they both could have offered
more discussion about good and bad examples.

Thanks to you and Chris for challenging my ideas about alt texts; it's
given me something to think about on my future pages.

--
John

[John Hosking]

Chris Morris wrote:

>
Having tried screen readers a bit, I think it's about the same as for
text browsers - it works better if there's no obvious clue that
there's an image there at all (in general: exceptions for thumbnails,
galleries, etc. where the image(s) are the major part of the content).

Thanks, Chris, for this and your earlier response. See also my response
to Michael Fresser.

>
There's trial versions of screen readers and speech browsers freely
available (JAWS and IBM Home Page Reader seem to be two commonly used
ones) - I'd recommend downloading them and trying them out (with the
monitor off, of course!). Once you've tried them and know roughly what
it feels like to use them, you can probably then manage simulating
them with a text browser such as Lynx.

I was going to ask you where I can get them and especially, what
differences were pertinent between the two, but then I thought I'd spare
you, and Google a little on my own. The very first hits I got included
the phrase "IBM Home Page Reader is Dead." Apparently, IBM is
discontinuing Home Page Reader. So I guess that's *one* difference...

>
(I don't recommend just using Lynx without trying a speech-based
browser at all, because while what they can parse and display is
similar, the display method is very different, and that does need
considering)

I've been using a Lynx emulator for a few years, with some enlightening
results, but I see it's not the be-all and end-all. Thanks again.

--
John

[Chris Morris]

John Hosking <Jo**@DELETE.Hosking.name.INVALIDwrites:

I was going to ask you where I can get them and especially, what
differences were pertinent between the two, but then I thought I'd
spare you, and Google a little on my own. The very first hits I got
included the phrase "IBM Home Page Reader is Dead." Apparently, IBM is
discontinuing Home Page Reader. So I guess that's *one* difference...

If IBM aren't providing it any more, you can download the trial
version from http://browsers.evolt.org - even if it's no longer
developed then it'll still give you an idea of what it's like to use
audio-based browsing.

HPR was a speech browser (it used IE to do the HTTP side of things),
whereas JAWS and similar are screen readers (and so can be used with
applications other than web browsing). I thought a trial version of
JAWS was available, but maybe not. It probably doesn't matter too much
*which* screen reading software you test with, though (though JAWS did
do a little bit better when combined with IE).

I've been using a Lynx emulator for a few years, with some
enlightening results, but I see it's not the be-all and
end-all. Thanks again.

A Lynx emulator? Why not just use Lynx - it's available for all major
operating systems.

--
Chris

[Spartanicus]

John Hosking <Jo**@DELETE.Hosking.name.INVALIDwrote:

[good advice snipped]

>Maybe I also be so bold as to offer a few other comments? Since you're
already styling (and you seem to care so much about "good XHTML"), get
rid of the extra <brtags everywhere.

Consecutive line break tags are always a bad idea, but there are
occasions where a single line brake tag is appropriate.

>First of all, they are not XHTML
either: you need to close all elements, here with <br/>.

Indeed, although when the document is served as text/html as the OP is
allegedly doing the advice in appendix C should be followed by inserting
a space: <br />.

>On all your images, you can apply an id and then style the dimensions.
Replace height="37" width="90" with CSS:
#vimimg { height:37px; width:90px; }

There should only be one instance of a given id per document, class
would be the thing to use for such an occasion. It should also be noted
that since CSS should be considered 100% optional, the functionality
(preventing unnecessary reflows) offered by providing the dimensions
means that usually the dimension should preferably be specified in the
markup.

>I believe &nbsp; is not valid XHTML. Check the W3C docs.

Perfectly valid, but indeed much abused.

--
Spartanicus

[John Hosking]

Spartanicus wrote:

John Hosking <Jo**@DELETE.Hosking.name.INVALIDwrote:

>... get rid of the extra <brtags everywhere.

Consecutive line break tags are always a bad idea, but there are
occasions where a single line brake tag is appropriate.

A good expansion of what I meant when I said "extra". The vast majority
of the <br>s in the source were in strings of three or more (up to
*five*). A couple of single instances were used as padding in an <h2>
element. Only one single-instance <brthere really qualified as
appropriate, IMO.

>

>>First of all, they are not XHTML
either: you need to close all elements, here with <br/>.

Indeed, although when the document is served as text/html as the OP is
allegedly doing the advice in appendix C should be followed by inserting
a space: <br />.

Yes, right.

>

>>On all your images, you can apply an id and then style the dimensions.
Replace height="37" width="90" with CSS:
#vimimg { height:37px; width:90px; }

There should only be one instance of a given id per document, class
would be the thing to use for such an occasion.

The rule you mention is right, but I saw that his images are several
different sizes. I didn't want to mention a class, because then he'd be
confused. ;-) I should maybe have said, "On each of your uniquely-sized
images, apply an id, for all of the common-sized images, a class..."

It should also be noted
that since CSS should be considered 100% optional, the functionality
(preventing unnecessary reflows) offered by providing the dimensions
means that usually the dimension should preferably be specified in the
markup.

Yes, this *should* be noted. It's a problem. Although for this
particular page, there wouldn't be that much reflowing, would there? Or
would that wreak havoc anyway with screen readers?

--
John

[Andy Dingley]

Russell Hoover wrote:

I reverted to border="0" inside the "img" tag. This of course does not validate as xhtml.

It would validate fine as XHTML. It's invalid because it's under a
Strict doctype, whether that's XHTML or HTML. It would still be valid
under XHTML Transitional.
First of all, use HTML. rather than XHTML. XHTML gains you nothing.
It's also harder to use correctly.

You're not using XHTML anyway, you're using Appendix C XHTML instead --
authoring it as XHTML and then sending it out as HTML, where it's
treated by the browsers as broken but auto-fixable HTML. This is better
than using "pure" XHTML, which just fails to work completely for a
significant number of browsers. However you're making life hard for
yourself, compared to HTML.

In particular, lose the following
<?xml version="1.0" encoding="utf-8"?>

and
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

I'd also note that the markup itself is bogus (valid, but badly
structured). If your code is still using repeated
<br /><br /to control layout, then the site _really_ isn't in a state
to benefit from XHTML.
To return to your stated question, you have a couple of options
regarding the "border" issue:

- Drop back to a Transitional doctype and keep "border" as an
attribute. This is a pragmatic fix to make your page valid for least
effort. If that's all you need, then do just this.

- Switch to controlling your borders through CSS. This is a better
approach for any long-term maintenance of the page. You'll probably use
a selector and rule a bit like this:
a img { border: none; }

You might find it useful to use a class attribute too, if you only
wanted this behaviour in a few places, not for every linked image.

[Russell Hoover]

On 15 Jan 2007 03:32:54 -0800, Andy Dingley <di*****@codesmiths.comwrote:

>
It would validate fine as XHTML. It's invalid because it's under a
Strict doctype, whether that's XHTML or HTML. It would still be valid
under XHTML Transitional.

Thanks to all who commented. Clearly I have a number of fundamental issues
to resolve. I'm 50 pages into the O'Reilly CSS guide and my site is on
hold til I get a better grasp of how to proceed.

[Andy Dingley]

Russell Hoover wrote:

I'm 50 pages into the O'Reilly CSS guide and my site is on
hold til I get a better grasp of how to proceed.

I'm not sure the O'Reilly will help! There's a shortage of good HTML
/ CSS tutorials that teach _good_ style, as opposed to merely
annotating the spec. O'Reilly's (animal engraving covers) aren't one of
them. However their "Head First HTML & CSS" is a good one and I'd
strongly recommend it.

This stuff isn't hard to teach or to understand, but most people just
come into it from the wrong direction, read the wrong book and then
find themselves knowing details but not the big picture. Then they show
up here and wonder why their sites get shredded.

[Roy A.]

Andy Dingley skrev:

Russell Hoover wrote:

I'm 50 pages into the O'Reilly CSS guide and my site is on
hold til I get a better grasp of how to proceed.

I'm not sure the O'Reilly will help! There's a shortage of good HTML
/ CSS tutorials that teach _good_ style, as opposed to merely
annotating the spec. O'Reilly's (animal engraving covers) aren't one of
them. However their "Head First HTML & CSS" is a good one and I'd
strongly recommend it.

This stuff isn't hard to teach or to understand, but most people just
come into it from the wrong direction, read the wrong book and then
find themselves knowing details but not the big picture. Then they show
up here and wonder why their sites get shredded.

Did you mean "Head First HTML with CSS & XHTML"?

[Andy Dingley]

Roy A. wrote:

Did you mean "Head First HTML with CSS & XHTML"?

That's the one. It's particularly good on how it treats XHTML. It
mentions it (because people buying books look for it) and then tells
you exactly why you shouldn't be using it.

[Roy A.]

Andy Dingley skrev:

Roy A. wrote:

Did you mean "Head First HTML with CSS & XHTML"?

That's the one. It's particularly good on how it treats XHTML. It
mentions it (because people buying books look for it) and then tells
you exactly why you shouldn't be using it.

And why shouln't you be using XHTML? If served properly, it should be
okey.

[Andy Dingley]

Roy A. wrote:

And why shouln't you be using XHTML? If served properly, it should be
okey.

Because it fills newsgroup archives with stuff that you clearly didn't
bother searching for before.

[Roy A.]

Andy Dingley skrev:

I'm 50 pages into the O'Reilly CSS guide and my site is on
hold til I get a better grasp of how to proceed.

I'm not sure the O'Reilly will help! There's a shortage of good HTML
/ CSS tutorials that teach _good_ style, as opposed to merely
annotating the spec. O'Reilly's (animal engraving covers) aren't one of
them. However their "Head First HTML & CSS" is a good one and I'd
strongly recommend it.

If you are using HTML 4.01 and want to validate your document, you may
want something before the head element. "Head First HTML & CSS" may be
a good book (I say "may" because av haven't read it), but I wouldn't
throw away my other books. O'Reilly has many good books, with or
without animals on the front cover. And I would think other publishers
also could offer some help.

[Roy A.]

Andy Dingley skrev:

Roy A. wrote:

And why shouln't you be using XHTML? If served properly, it should be
okey.

Because it fills newsgroup archives with stuff that you clearly didn't
bother searching for before.

I tried to search for "Head First", but couldn't find anything on the
subject. I guess I have to buy the book.

[Sherm Pendley]

"Roy A." <ro*********@gmail.comwrites:

Andy Dingley skrev:

>Roy A. wrote:

And why shouln't you be using XHTML? If served properly, it should be
okey.

Because it fills newsgroup archives with stuff that you clearly didn't
bother searching for before.

I tried to search for "Head First", but couldn't find anything on the
subject.

The book hasn't been mentioned here that I can recall.

The reasons for not using XHTML have been discussed TO DEATH here. What it
basically amounts to is that IE cannot be convinced to handle it correctly.
Serving it with the correct MIME type results in IE handling it as plain
vanilla XML with no default stylesheet, and serving it as text/html with an
XHTML doctype throws IE into so-called "quirks mode".

As bad as IE's "standards mode" is, either of these two alternatives are
worse, and the only way to trigger "standards mode" in IE is a text/html
document with an HTML4 doctype.

Sigh. Yet another promising technology killed by MS. :-(

sherm--

--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net