473,416 Members | 1,774 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,416 software developers and data experts.

Inline DIVs Under Netscape/Opera

i want to display a series of inline, fixed-width DIVs that will wrap into
columns - a table, basically. i can do it under Internet Explorer, but the
same code under Netscape or Opera does not behave as expected. the DIVs
"collapse" into small rectangles (i put a border around them so i could
see), but their contents (some middle-aligned text) span the width of the
page. if not for the borders that i added, it would appear that each DIV was
width: 100%. rather than a number of smaller columns, i get one big, fat
column. what am i doing wrong? here's the code (with only two columns, for
simplicity):

<?xml version="1.0" encoding="us-ascii"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-US">
<head>
<title></title>
<meta http-equiv="Content-Type" content="application/xhtml+xml;
charset=us-ascii" />
<style type="text/css">
div.productListing {
display: inline;
width: 128px;
text-align: center;

/* temp */
border: solid 1px red;
}
</style>
</head>
<body>

<div class="productListing">
<div class="productImageContainer"><img class="productImage" src="#"
alt="Cufflinks" /></div>
<div class="productName">Gold Cufflinks</div>
<div class="description">They are cufflinks and they are gold.</div>
<div class="price">$59.90</div>
</div>

<div class="productListing">
<div class="productImageContainer"><img class="productImage" src="#"
alt="More Cufflinks" /></div>
<div class="productName">Gold Cufflinks</div>
<div class="description">These cufflinks are also gold.</div>
<div class="price">$69.90</div>
</div>

</body>
</html>
Jul 20 '05 #1
30 2749
On Wed, 28 Jan 2004 23:46:40 GMT, Adam Siler <as****@icglp.com> wrote:
i want to display a series of inline, fixed-width DIVs that will wrap
into
columns - a table, basically. i can do it under Internet Explorer, but
the
same code under Netscape or Opera does not behave as expected.
...
<?xml version="1.0" encoding="us-ascii"?> ... div.productListing {
display: inline;
width: 128px;
text-align: center;


You can't set width on 'inline' elements, according to the spec. MSIE 6
also knows this, but you switch one it's Quirks mode with the XML prolog,
so it uses bugward compatible rendering.

What you could try, is either using 'inline-block' (CSS 2.1) or keep the
DIVs as 'block', and float or position them next to each other.

--
Rijk van Geijtenbeek

The Web is a procrastination apparatus:
It can absorb as much time as is required to ensure that you
won't get any real work done. - J.Nielsen
Jul 20 '05 #2

"Rijk van Geijtenbeek" <ri**@opera.com> wrote in message
news:op**************@news.individual.net...
On Wed, 28 Jan 2004 23:46:40 GMT, Adam Siler <as****@icglp.com> wrote:
i want to display a series of inline, fixed-width DIVs that will wrap
into
columns - a table, basically. i can do it under Internet Explorer, but
the
same code under Netscape or Opera does not behave as expected.


..
<?xml version="1.0" encoding="us-ascii"?>

..
div.productListing {
display: inline;
width: 128px;
text-align: center;


You can't set width on 'inline' elements, according to the spec. MSIE 6
also knows this, but you switch one it's Quirks mode with the XML prolog,
so it uses bugward compatible rendering.

What you could try, is either using 'inline-block' (CSS 2.1) or keep the
DIVs as 'block', and float or position them next to each other.


I had posted this same question recently, in particular about a series of
links that I wanted to display as a horizontal arrangement of buttons, with
said "buttons" being <span>s styled via CSS. (I got an explanation about
quirks mode and inline blocks in response.)

This morning I had another idea which I had wanted to add belatedly as a
follow-up, but I'll take this opportunity to do it here. It seems to me that
an array of buttons, whether horizontal or vertical, might reasonably be
conceived structurally as a one-dimensional table of elements. So it would
be reasonable to create a one-row table with a link in each one, and apply
styling to the TDs.

Jul 20 '05 #3
"Harlan Messinger" <h.*********@comcast.net> wrote:
You can't set width on 'inline' elements, according to the spec. MSIE 6
also knows this, but you switch one it's Quirks mode with the XML prolog,
so it uses bugward compatible rendering.

What you could try, is either using 'inline-block' (CSS 2.1) or keep the
DIVs as 'block', and float or position them next to each other.


I had posted this same question recently, in particular about a series of
links that I wanted to display as a horizontal arrangement of buttons, with
said "buttons" being <span>s styled via CSS. (I got an explanation about
quirks mode and inline blocks in response.)

This morning I had another idea which I had wanted to add belatedly as a
follow-up, but I'll take this opportunity to do it here. It seems to me that
an array of buttons, whether horizontal or vertical, might reasonably be
conceived structurally as a one-dimensional table of elements.


A table signifies a relationship between the data contained, a list of
links forming a navbar does not mean that they are related, as such
using a table to mark them up is wrong.

Creating a properly marked up horizontal navbar with css is easy:
http://www.alistapart.com/articles/taminglists/

--
Spartanicus
Jul 20 '05 #4

"Spartanicus" <me@privacy.net> wrote in message
news:rq********************************@news.spart anicus.utvinternet.ie...
"Harlan Messinger" <h.*********@comcast.net> wrote:
You can't set width on 'inline' elements, according to the spec. MSIE 6
also knows this, but you switch one it's Quirks mode with the XML prolog, so it uses bugward compatible rendering.

What you could try, is either using 'inline-block' (CSS 2.1) or keep the DIVs as 'block', and float or position them next to each other.
I had posted this same question recently, in particular about a series of
links that I wanted to display as a horizontal arrangement of buttons, withsaid "buttons" being <span>s styled via CSS. (I got an explanation about
quirks mode and inline blocks in response.)

This morning I had another idea which I had wanted to add belatedly as a
follow-up, but I'll take this opportunity to do it here. It seems to me thatan array of buttons, whether horizontal or vertical, might reasonably be
conceived structurally as a one-dimensional table of elements.


A table signifies a relationship between the data contained, a list of
links forming a navbar does not mean that they are related, as such
using a table to mark them up is wrong.


Depending on the circumstances, I disagree. One type of web page I work
displays a list of items, on each of which the same operation can be
performed:

Thing 1 Edit Send Delete
Thing 2 Edit Send Delete
Thing 3 Edit Send Delete

where "Edit", "Send" , and "Delete" are all links. Conceptually this is
identical to:

Thing #: Edit Send Delete
-----------------------------------------------------------------------
Thing 1 [button] [button] [button]
Thing 2 [button] [button] [button]
Thing 3 [button] [button] [button]

This is certainly a table, no? Editing, sending, and deleting are indeed
related, by virtue of the very fact that they are all members of the set
"operations to perform on 'this' item". They're just as much related to each
other, with respect to the object on which they are to operate, as are the
area, population, and GNP of a country.

In the case where a page displays information on *one* item, rather than
listing rows for a *number* of items, if the actions to be performed by the
links are still related in the sense that they are all actions to be applied
to 'this' item, then this is just the trivial reduction of the general case
above to a single item, and a one-row table makes sense.

Creating a properly marked up horizontal navbar with css is easy:
http://www.alistapart.com/articles/taminglists/


Granted. The problem was to come up with a way that works *now*. I haven't
tested it, but how well does this work in current browsers?

Jul 20 '05 #5
On Thu, 29 Jan 2004 14:01:16 -0500, Harlan Messinger
<h.*********@comcast.net> wrote:
"Spartanicus" <me@privacy.net> wrote...
"Harlan Messinger" <h.*********@comcast.net> wrote:
This morning I had another idea which I had wanted to add belatedly as
a follow-up, but I'll take this opportunity to do it here. It seems to
me
that an array of buttons, whether horizontal or vertical, might
reasonably be conceived structurally as a one-dimensional table of
elements.
A table signifies a relationship between the data contained, a list of
links forming a navbar does not mean that they are related, as such
using a table to mark them up is wrong.
Generally, yes. But it is hard to see how using a single-row table will
actually do any harm for usability or accessibility.
Creating a properly marked up horizontal navbar with css is easy:
http://www.alistapart.com/articles/taminglists/


Granted. The problem was to come up with a way that works *now*. I
haven't tested it, but how well does this work in current browsers?


The list they use themselves on top of the page works pretty good across
current browsers.

--
Rijk van Geijtenbeek

The Web is a procrastination apparatus:
It can absorb as much time as is required to ensure that you
won't get any real work done. - J.Nielsen
Jul 20 '05 #6
"Harlan Messinger" <h.*********@comcast.net> wrote:
A table signifies a relationship between the data contained, a list of
links forming a navbar does not mean that they are related, as such
using a table to mark them up is wrong.


Depending on the circumstances, I disagree. One type of web page I work
displays a list of items, on each of which the same operation can be
performed:

Thing 1 Edit Send Delete
Thing 2 Edit Send Delete
Thing 3 Edit Send Delete

where "Edit", "Send" , and "Delete" are all links. Conceptually this is
identical to:

Thing #: Edit Send Delete
-----------------------------------------------------------------------
Thing 1 [button] [button] [button]
Thing 2 [button] [button] [button]
Thing 3 [button] [button] [button]

This is certainly a table, no?


No.
Creating a properly marked up horizontal navbar with css is easy:
http://www.alistapart.com/articles/taminglists/


Granted. The problem was to come up with a way that works *now*. I haven't
tested it, but how well does this work in current browsers?


Fine, try it.

--
Spartanicus
Jul 20 '05 #7
On Thu, 29 Jan 2004 14:01:16 -0500, Harlan Messinger
<h.*********@comcast.net> wrote:
http://www.alistapart.com/articles/taminglists/


Granted. The problem was to come up with a way that works *now*. I
haven't
tested it, but how well does this work in current browsers?

I've used this basic technique with great success.

Why did you assume this wouldn't work now?
Jul 20 '05 #8
On Fri, 30 Jan 2004 01:16:10 +0100, Rijk van Geijtenbeek <ri**@opera.com>
wrote:
Generally, yes. But it is hard to see how using a single-row table will
actually do any harm for usability or accessibility.


It's also hard to see where it would provide any benefit.
Jul 20 '05 #9
Neal <ne*****@spamrcn.com> wrote:
On Fri, 30 Jan 2004 01:16:10 +0100, Rijk van Geijtenbeek <ri**@opera.com>
wrote:
Generally, yes. But it is hard to see how using a single-row table will
actually do any harm for usability or accessibility.


It's also hard to see where it would provide any benefit.


Ease.

--
Harlan Messinger
Remove the first dot from my e-mail address.
Veuillez ôter le premier point de mon adresse de courriel.
Jul 20 '05 #10
Neal <ne*****@spamrcn.com> wrote:
On Thu, 29 Jan 2004 14:01:16 -0500, Harlan Messinger
<h.*********@comcast.net> wrote:
http://www.alistapart.com/articles/taminglists/


Granted. The problem was to come up with a way that works *now*. I
haven't
tested it, but how well does this work in current browsers?

I've used this basic technique with great success.

Why did you assume this wouldn't work now?


Actually, because I had been to this page before, but was confusing it
this time with another one I've visited where the techniques weren't
working to well when I tried them out.

--
Harlan Messinger
Remove the first dot from my e-mail address.
Veuillez ôter le premier point de mon adresse de courriel.
Jul 20 '05 #11
Spartanicus <me@privacy.net> wrote:
"Harlan Messinger" <h.*********@comcast.net> wrote:
A table signifies a relationship between the data contained, a list of
links forming a navbar does not mean that they are related, as such
using a table to mark them up is wrong.


Depending on the circumstances, I disagree. One type of web page I work
displays a list of items, on each of which the same operation can be
performed:

Thing 1 Edit Send Delete
Thing 2 Edit Send Delete
Thing 3 Edit Send Delete

where "Edit", "Send" , and "Delete" are all links. Conceptually this is
identical to:

Thing #: Edit Send Delete
-----------------------------------------------------------------------
Thing 1 [button] [button] [button]
Thing 2 [button] [button] [button]
Thing 3 [button] [button] [button]

This is certainly a table, no?


No.


Why would that be? Columns, rows, relationships--I can't think of any
reason why not.

--
Harlan Messinger
Remove the first dot from my e-mail address.
Veuillez ôter le premier point de mon adresse de courriel.
Jul 20 '05 #12
On Thu, 29 Jan 2004 23:05:06 -0500, Harlan Messinger
<hm*******************@comcast.net> wrote:
Neal <ne*****@spamrcn.com> wrote:
On Fri, 30 Jan 2004 01:16:10 +0100, Rijk van Geijtenbeek
<ri**@opera.com>
wrote:
Generally, yes. But it is hard to see how using a single-row table will
actually do any harm for usability or accessibility.


It's also hard to see where it would provide any benefit.


Ease.

But ease for who? Certainly list markup is more meaningful than table
markup for a list of links. I believe meaningful markup generally makes it
easier for the user. User agents which cannot handle tables will just have
a row of text if you use table markup, but using the list will mean it
will display as a list.

To me, ease for the user outweighs ease for the author.
Jul 20 '05 #13
Harlan Messinger <hm*******************@comcast.net> wrote:
Thing #: Edit Send Delete
-----------------------------------------------------------------------
Thing 1 [button] [button] [button]
Thing 2 [button] [button] [button]
Thing 3 [button] [button] [button]

This is certainly a table, no?


No.


Why would that be? Columns, rows, relationships--I can't think of any
reason why not.


Because the relationship needs to exist between the _data_, not a
function or purpose.

Example:
Article Price Colour Quantity

--
Spartanicus
Jul 20 '05 #14
On Fri, 30 Jan 2004 01:16:10 +0100, "Rijk van Geijtenbeek"
<ri**@opera.com> wrote:
On Thu, 29 Jan 2004 14:01:16 -0500, Harlan Messinger
<h.*********@comcast.net> wrote:
"Spartanicus" <me@privacy.net> wrote...
"Harlan Messinger" <h.*********@comcast.net> wrote: This morning I had another idea which I had wanted to add belatedly as
a follow-up, but I'll take this opportunity to do it here. It seems to
me
that an array of buttons, whether horizontal or vertical, might
reasonably be conceived structurally as a one-dimensional table of
elements. A table signifies a relationship between the data contained, a list of
links forming a navbar does not mean that they are related, as such
using a table to mark them up is wrong.


Generally, yes. But it is hard to see how using a single-row table will
actually do any harm for usability or accessibility.


It can harm usability if it prevents the links from wrapping at the edge
of the window (the reader's window being narrower than the author's).

--
Stephen Poley

http://www.xs4all.nl/~sbpoley/webmatters/
Jul 20 '05 #15
On Fri, 30 Jan 2004 00:32:59 -0500, Neal <ne*****@spamrcn.com> wrote:

...
But ease for who? Certainly list markup is more meaningful than table
markup for a list of links. I believe meaningful markup generally makes
it easier for the user. User agents which cannot handle tables will just
have a row of text if you use table markup, but using the list will mean
it will display as a list.
Maybe a row of text is my preferred fallback?
To me, ease for the user outweighs ease for the author.


Sure, but I really doubt that plays a role here. Would the lone Lynx or
Netscape 4 user (or the PDA-user, or... etc.) that gets an unstyled page
really be happier with (sometimes rather long) lists that cause a lot of
vertical scrolling?

I'm not advocating any specific approach [1], but the anti-tabel zealots
sometimes go to extremes... Especially when some of them put dozens of
SPANs and DIVs in their design just to get it to look like ye olde table
design :) IMHO, those superfluous spans are just as bad in theory as a
simple table, and in both cases the practical harm to accessibility is
close to zero.

[1] On my own pages I try to use *only* semanticly useful elements, and
I've been doing that for the last 5 years. But I'm not a commercial
designer, not a very talented one :)

--
Rijk van Geijtenbeek

The Web is a procrastination apparatus:
It can absorb as much time as is required to ensure that you
won't get any real work done. - J.Nielsen

http://www.xs4all.nl/~vangeijt/
Jul 20 '05 #16
On Fri, 30 Jan 2004 00:32:59 -0500, Neal <ne*****@spamrcn.com> wrote:

...
But ease for who? Certainly list markup is more meaningful than table
markup for a list of links. I believe meaningful markup generally makes
it easier for the user. User agents which cannot handle tables will just
have a row of text if you use table markup, but using the list will mean
it will display as a list.
Maybe a row of text is my preferred fallback?
To me, ease for the user outweighs ease for the author.


Sure, but I really doubt that plays a role here. Would the lone Lynx or
Netscape 4 user (or the PDA-user, or... etc.) that gets an unstyled page
really be happier with (sometimes rather long) lists that cause a lot of
vertical scrolling?

I'm not advocating any specific approach [1], but the anti-tabel zealots
sometimes go to extremes... Especially when some of them put dozens of
SPANs and DIVs in their design just to get it to look like ye olde table
design :) IMHO, those superfluous spans are just as bad in theory as a
simple table, and in both cases the practical harm to accessibility is
close to zero.

[1] On my own pages I try to use *only* semanticly useful elements, and
I've been doing that for the last 5 years. But I'm not a commercial
designer, not a very talented one :)

--
Rijk van Geijtenbeek

The Web is a procrastination apparatus:
It can absorb as much time as is required to ensure that you
won't get any real work done. - J.Nielsen

http://www.xs4all.nl/~vangeijt/
Jul 20 '05 #17
On Fri, 30 Jan 2004 13:20:00 +0100, Rijk van Geijtenbeek <ri**@opera.com>
wrote:
On Fri, 30 Jan 2004 00:32:59 -0500, Neal <ne*****@spamrcn.com> wrote:
But ease for who? Certainly list markup is more meaningful than table
markup for a list of links. I believe meaningful markup generally
makes it easier for the user. User agents which cannot handle tables
will just have a row of text if you use table markup, but using the
list will mean it will display as a list.
Maybe a row of text is my preferred fallback?


It's a list by nature. Whatever you wish the user should see, it's still a
list.

Your "fallback" should not be driven by a desire for a particular display.
The whole point of HTML is to give meaningful markup, and allow the user
agent, guided by the user's preferences, your style suggestions, and its
pre-programmed defaults, to render the page independently of you.

If you're trying to force a text browser to display things in a row (or in
any particular way), you are attempting to control rendering with HTML and
that's akin to painting a wall with a screwdriver.
To me, ease for the user outweighs ease for the author.


Sure, but I really doubt that plays a role here. Would the lone Lynx or
Netscape 4 user (or the PDA-user, or... etc.) that gets an unstyled page
really be happier with (sometimes rather long) lists that cause a lot of
vertical scrolling?


Yes. The author can easily accommodate in-page navigation with internal
linking. A space-separated horizontal wrapping sequence of links, some
with one word and some with two, will make for very difficult navigation,
while an actual list will make the links clearer to the user. If one's
navigation list is that long, perhaps there's a need to rethink how it's
structured (perhaps divide the site into some broad categories and only
give detailed links for the current category, and then links to the main
pages of the other categories).
I'm not advocating any specific approach [1], but the anti-tabel zealots
sometimes go to extremes... Especially when some of them put dozens of
SPANs and DIVs in their design just to get it to look like ye olde table
design :) IMHO, those superfluous spans are just as bad in theory as a
simple table, and in both cases the practical harm to accessibility is
close to zero.


Ah, but have you seen a table degrade in a PDA? How about a CSS-styled
page? If I see two otherwise identical designs, one created with tables
and the other with CSS and meaningful markup, through any random browser,
chances are higher that I'm seeing an effective layout with the latter
than the former. It all comes back to the old CSS-is-meaningful-markup
business - by pulling display concerns out of the HTML code entirely, it
is more likely the page can be displayed flatteringly in any user agent.
Jul 20 '05 #18
On Fri, 30 Jan 2004 08:58:53 +0000, Spartanicus <me@privacy.net> wrote:
Harlan Messinger <hm*******************@comcast.net> wrote:
Thing #: Edit Send Delete
-----------------------------------------------------------------------
Thing 1 [button] [button] [button]
Thing 2 [button] [button] [button]
Thing 3 [button] [button] [button]

This is certainly a table, no?

No.
Why would that be? Columns, rows, relationships--I can't think of any
reason why not.


Because the relationship needs to exist between the _data_, not a
function or purpose.

Example:
Article Price Colour Quantity


It seems to me that you're stretching things a little here. Each button
has a relationship with the row and column headers which goes beyond
mere visual appearance. I can't see how a table would be wrong.

--
Stephen Poley

http://www.xs4all.nl/~sbpoley/webmatters/
Jul 20 '05 #19
Neal <ne*****@spamrcn.com> wrote:
On Fri, 30 Jan 2004 13:20:00 +0100, Rijk van Geijtenbeek <ri**@opera.com>
wrote:
On Fri, 30 Jan 2004 00:32:59 -0500, Neal <ne*****@spamrcn.com> wrote:
But ease for who? Certainly list markup is more meaningful than table
markup for a list of links. I believe meaningful markup generally
makes it easier for the user. User agents which cannot handle tables
will just have a row of text if you use table markup, but using the
list will mean it will display as a list.
Maybe a row of text is my preferred fallback?


It's a list by nature. Whatever you wish the user should see, it's still a
list.


No, it's not. Lists are in the eye of the beholder. For example:

The whole point of HTML is to give meaningful markup, and allow the user
agent, guided by the user's preferences, your style suggestions, and its
pre-programmed defaults, to render the page independently of you.


I would have written the above paragraph like this:...

The whole point of HTML is to give meaningful markup,
and allow the user agent, guided by:
- the user's preferences:
- your style suggestions, and:
- its pre-programmed defaults:
to render the page independently of you.

But then, I wouldn't presume to lecture Rijk about the point of HTML
:-)

<heresy class="ugly truth">Lists are a *presentational* device, to
emphasize content by including superfluous line breaks. They are akin
to other emphasis techniques such as boldfacing or italicizing text.
If you're on the "semantic markup" trip, lists have no more place in
HTML than FONT tags.</heresy>

--
Karl Smith.
Jul 20 '05 #20
Stephen Poley <sb******************@xs4all.nl> wrote:
> Thing #: Edit Send Delete
>-----------------------------------------------------------------------
> Thing 1 [button] [button] [button]
> Thing 2 [button] [button] [button]
> Thing 3 [button] [button] [button]
>
>This is certainly a table, no?

No.

Why would that be? Columns, rows, relationships--I can't think of any
reason why not.

Because the relationship needs to exist between the _data_, not a
function or purpose.

Example:
Article Price Colour Quantity


It seems to me that you're stretching things a little here. Each button
has a relationship with the row and column headers which goes beyond
mere visual appearance. I can't see how a table would be wrong.


Edit Send Delete tabular data?

Oh please.

--
Spartanicus
Jul 20 '05 #21
*Spartanicus*:
Stephen Poley <sb******************@xs4all.nl> wrote:
| Thing #: Edit Send Delete
|-----------------------------------------------------------------------
| Thing 1 [button] [button] [button]
| Thing 2 [button] [button] [button]
| Thing 3 [button] [button] [button]
Edit Send Delete tabular data?
Here, yes.
Oh please.


You're welcome, although this is off topic and should be discussed in ciwah
instead, if desired.
F'up2 comp.infosystems.www.authoring.html

--
No sig today, my .sig has gone away
The divider stands forlorn, a symbol of the dawn
No sig today, it seems a common sight
But people reading by don't know the reason why
Jul 20 '05 #22
On 30 Jan 2004 13:00:54 -0800, Karl Smith <go************@kjsmith.com>
wrote:

<heresy class="ugly truth">Lists are a *presentational* device, to
emphasize content by including superfluous line breaks. They are akin
to other emphasis techniques such as boldfacing or italicizing text.
If you're on the "semantic markup" trip, lists have no more place in
HTML than FONT tags.</heresy>


Well, we disagree. I can indeed express a series of phrases in a paragraph
as a list, and that would certainly be a presentational use in a way. But
if I'm listing off items and they are not connectable as a sentence or
whatnot, a list is meaningful. It need not emphasize anything. If I want
to show the names of the players on my sports team, a list does not
provide emphasis, it just gives the names in a list.

If we follow your lead, even h1 and p have displays associated with them,
so we might as well style a bunch of <div>s and <span>s.
Jul 20 '05 #23
Karl Smith wrote:

<heresy class="ugly truth">Lists are a *presentational* device,
Your point has already been made in ciwa* with regard to tables, and
refuted. You're confusing the semantics at the authoring end and the
presentation at the reader's end. Perhaps you should read the recent
tables for layout thread in ciwah.
to emphasize content by including superfluous line breaks.
A list, marked up as such, will be presented in a visual browser
(Lynx, Mozilla, Opera, Safari, IE, etc.) with each list item on its
own line. That seems like a logical choice. How do you consider that
"superfluous?"
The whole point of HTML is to give meaningful markup,
and allow the user agent, guided by:
- the user's preferences:
- your style suggestions, and:
- its pre-programmed defaults:
to render the page independently of you.
Did you mean that the line breaks in this example are superfluous?
Perhaps you meant[1] that the line breaks are inappropriate. I'd
agree. But that's because the text above is a paragraph, not a list,
imho. Not everything is a list in web authoring.

[1] "superfluous" is a strange word. Did you look up the word in a
dictionary? How are line breaks beyond what is necessary?
They are akin to other emphasis techniques such as boldfacing or
italicizing text.
If you use <b> or <i> for emphasis, then stop. Use <em> or <strong>.
If you're complaining that emphasis is often displayed in italics or
bold, then you're just confusing the role of author and ua.
If you're on the "semantic markup" trip, lists
have no more place in HTML than FONT tags.</heresy>


That's not a heresy, it's a fallacious argument.

--
Brian (follow directions in my address to email me)
http://www.tsmchughs.com/

Jul 20 '05 #24
In article Stephen Poley wrote:
Generally, yes. But it is hard to see how using a single-row table will
actually do any harm for usability or accessibility.


It can harm usability if it prevents the links from wrapping at the edge
of the window (the reader's window being narrower than the author's).


Yes. It is much better to use plain text with some meaningless markup,
that play with one row table. Really.

If table is fully ignored, one row table will be shown as one word of
text. That is very bad thing. Itwilllooklikethis, which is confusing, and
surely not usable nor accessible.

That's why it's better to use list for horizontal link lists. Because
they degrade much better.

OTOH, you can use "link1 | link2 | link3" and it will work exactly same
in all browsers. Is there any browser, where that would be worse than
<ul><li>link1<li>link2<li>link3</ul> ? There is no graphical browser, but
maybe aural or braille? I suppose | is not best char for divider, what
would be better?
--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Saapi lähettää meiliä, jos aihe ei liity ryhmään, tai on yksityinen
tjsp., mutta älä lähetä samaa viestiä meilitse ja ryhmään.

Jul 20 '05 #25
On Sat, 31 Jan 2004 21:17:13 +0200, Lauri Raittila
<la***@raittila.cjb.net> wrote:
I suppose | is not best char for divider, what
would be better?


I've seen [link] used from time to time. Though I'm prone to use lists
anyway, so for me it's purely moot.
Jul 20 '05 #26
In article Neal wrote:
On Sat, 31 Jan 2004 21:17:13 +0200, Lauri Raittila
<la***@raittila.cjb.net> wrote:
I suppose | is not best char for divider, what
would be better?
I've seen [link] used from time to time. Though I'm prone to use lists
anyway, so for me it's purely moot.


Sure I have too. Use it myself on other page. As I do lists. Whatever
suits best. What I'm after is if there is better character to use as
divider.

--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Saapi lähettää meiliä, jos aihe ei liity ryhmään, tai on yksityinen
tjsp., mutta älä lähetä samaa viestiä meilitse ja ryhmään.

Jul 20 '05 #27
Lauri Raittila wrote:
In article Neal wrote:
On Sat, 31 Jan 2004 21:17:13 +0200, Lauri Raittila
<la***@raittila.cjb.net> wrote:
I suppose | is not best char for divider, what
would be better?

I've seen [link] used from time to time. Though I'm prone to use lists
anyway, so for me it's purely moot.


Sure I have too. Use it myself on other page. As I do lists. Whatever
suits best. What I'm after is if there is better character to use as
divider.


Alan Flavell has said that this is the one instance where an invisible
1 pixel image is appropriate.[1] But then the same question applies:
what should alt be? I supposed I'd use |

[1] I think I have another, though my use is debatable. As this is
ciwas, I'll stop here.

--
Brian (follow directions in my address to email me)
http://www.tsmchughs.com/

Jul 20 '05 #28
On Sun, 1 Feb 2004, Brian wrote:
Alan Flavell has said that this is the one instance where an invisible
1 pixel image is appropriate.[1]
That's right. I hadn't been aware of the possibility of it getting
suppressed as a webbug, though! I'm still not sure whether that's my
problem or theirs. As long as I link to an image on my own site, I
think I'm entitled to expect them to trust the image as much (or as
little!) as they trust the rest of my pages. If I had my <img
src=...> tag pointing to some third-party site, they'd be entitled to
smell a rat, that's fair enough.
But then the same question applies:
what should alt be? I supposed I'd use |


When I tried IBM HPR, it read-out "BAR" somewhat intrusively, but I
supposed its users are accustomed to that, or have gone to the trouble
of teaching it to say something else. It seemed to me to be a fair
compromise, and worked fine in text browsers too e.g Lynx.

It wasn't nearly as intrusive as what you can get if you put square
brackets around your links ("RIGHT SQUARE BRACKET, LEFT SQUARE
BRACKET").

One possible alternative would be the middot, but I forgot to try that
out during the HPR trial period. (I'm sorry if I give the impression
of being stingy to fork out the $150 or so for a license, but really I
don't have the time to fully explore this hobby of mine while I still
have a day job.)

all the best
Jul 20 '05 #29
On Sun, 1 Feb 2004 15:22:58 +0000, Alan J. Flavell <fl*****@ph.gla.ac.uk>
wrote:

When I tried IBM HPR, it read-out "BAR" somewhat intrusively, but I
supposed its users are accustomed to that, or have gone to the trouble
of teaching it to say something else. It seemed to me to be a fair
compromise, and worked fine in text browsers too e.g Lynx.

It wasn't nearly as intrusive as what you can get if you put square
brackets around your links ("RIGHT SQUARE BRACKET, LEFT SQUARE
BRACKET").


Weel, if it's going to read out whatever it encounters, the "obvious"
solution is to use something it won't read. This is why lists are so good
for this, the divider is essentially the pause before going to the next
list item.

If you use bar, hey, there's worse things to yell out than "bar." But this
treads pretty close to being concerned over how the UA renders the HTML.
Since what we're after is seperating information from other information,
really any dividing characters like () [] , / | \ etc. are arguably
meaningful.
Jul 20 '05 #30
On Sun, 1 Feb 2004, Neal wrote:
Weel, if it's going to read out whatever it encounters,
I _did_ say "somewhat intrusive". It didn't by any means seem wrong
or unusable.
the "obvious" solution is to use something it won't read.
A comma, for example, if we're doing it that way.
This is why lists are so good for this, the divider is essentially
the pause before going to the next list item.
Indeed: the forward-looking approach would be to use an HTML list, and
use CSS to style it as a horizontal row. But then you'd rate to get
complaints about its usability in browsers which didn't honour that
part of the CSS. But at some point, that will indeed become the
preferred solution, I agree.
If you use bar, hey, there's worse things to yell out than "bar."
No argument there. Fact is, some punctuation causes a modulation in
what is spoken; some punctuation gets read out by naming it.
But this treads pretty close to being concerned over how the UA
renders the HTML.


Speaking as someone who puts a first priority on getting the theory
right, I have to say it would be quite wrong to close one's eyes (or
in this case, one's ears) to the practical results that are achieved.
But yes, one ought not to go so far as perverting the underlying
structure for the sake of some incidental effect at the rendering
stage, I agree.

cheers
Jul 20 '05 #31

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

2
by: Adam Siler | last post by:
i want to display a series of inline, fixed-width DIVs that will wrap into columns - a table, basically. i can do it under Internet Explorer, but the same code under Netscape or Opera does not...
1
by: Jeff Thies | last post by:
I have something like this: <span style="width:12ex; text-align: right">field label</span><input type="text" ...> (I suppose it may be better to do that with label. I'm not really sure what...
3
by: Peter Jenkins | last post by:
I have some divs I am using to get a two column layout for a section of a page, like so; <div1> <div2> <div3> blah blah blah blah blah blah blah blah...
0
by: nina | last post by:
Hi all, I've been working on a site that involves content in multiple scrolling DIVs on a page which is loaded inside multiple framesets. the layout is cramped as all hell but I'm not going to...
8
by: Harlan Messinger | last post by:
To produce a side-by-side three-column layout with a uniform, bordered top and bottom , I used the same HTML with two sets of styles. The two versions are at ...
6
by: Nicolai P. Zwar | last post by:
Hi there, everybody. This here is a sample page of what appears to be a Netscape/Mozilla positioning problem. I posted a the problematic code down at the bottom of this message, and you can see...
6
by: Tony T | last post by:
Can anyone help me with this - it may be obvious, but I just can't see it. I'm working with PC and WinME. In IE6, the two divs inside the wrapping div have no space between them, which is how I...
6
by: axlq | last post by:
I've spent most of the day struggling with what I thought would be a trivial problem. I have a hidden element that appears, outside of the normal flow, when the mouse hovers over an inline...
5
by: Awok | last post by:
Hi, i've been stuck trying to get the following code to display correctly in IE in which i've come across many diffrent theories but none which have worked possibly the box model problem. ...
0
by: emmanuelkatto | last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud. Please let me know. Thanks! Emmanuel
0
BarryA
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...
1
by: Sonnysonu | last post by:
This is the data of csv file 1 2 3 1 2 3 1 2 3 1 2 3 2 3 2 3 3 the lengths should be different i have to store the data by column-wise with in the specific length. suppose the i have to...
0
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...
0
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers,...
0
jinu1996
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...
0
tracyyun
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...
0
agi2029
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,...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.