add line breaks through css?

[Greg N.]

I have a some text that is include (through PHP) in different pages:

<div class=mystuff>item 1</div>
<div class=mystuff>item 2</div>
<div class=mystuff>item 3</div>

On one type of page, these items should appear on separate lines, as if
they were sparated by <br>.

On another type of page, the items should appear side by side, separated
by spaces.

The difference between the two cases should be coded in CSS only. Can
anybody give me a hint on how to do this, if it is possible?

 

[dingbat]

On one type of page, these items should appear on separate lines, as if
they were sparated by <br>.

On another type of page, the items should appear side by side, separated
by spaces.

Investigate display:block; and display:inline;

 

[Spartanicus]

I have a some text that is include (through PHP) in different pages:

<div class=mystuff>item 1</div>
<div class=mystuff>item 2</div>
<div class=mystuff>item 3</div>

Div soup, use the appropriate structural and semantic markup instead.

On one type of page, these items should appear on separate lines, as if
they were sparated by <br>.

On another type of page, the items should appear side by side, separated
by spaces.

The difference between the two cases should be coded in CSS only. Can
anybody give me a hint on how to do this, if it is possible?

Depends on the markup, for a list:

ul li{display:inline} to switch it to inline ("list-item" is the
default).

 

[Jukka K. Korpela]

I have a some text that is include (through PHP) in different pages:

<div class=mystuff>item 1</div>
<div class=mystuff>item 2</div>
<div class=mystuff>item 3</div>

Is it really something that has no logical structure that is describable in
HTML? Not a list, for example? Not paragraphs?

On one type of page, these items should appear on separate lines, as if
they were sparated by <br>.

On another type of page, the items should appear side by side, separated
by spaces.

Well, then change <div> to <span> on that page. Though there is probably
something odd going on here, and you are solving the wrong problem, and we
cannot solve your real problem because you gave no URL.

The difference between the two cases should be coded in CSS only.

No, it shouldn't. See http://css.nu/pointers/CSS-caveats.html

 

[Greg N.]

Though there is probably something odd going on here,
and you are solving the wrong problem, and we
cannot solve your real problem because you gave no URL.

What I was talking about are the navigation segments in

http://hothaus.de/greg-tour-2003/fyrom.htm
and
http://coolhaus.de/iv/03/iv.php?width=716&height=406&alt=Ohrid&h1=Mazedonien&img=img/xl-x2_32.jpg

The problem is solved. I got the answers that I was looking for in the
first two responses to my question.

 

[Jukka K. Korpela]

What I was talking about are the navigation segments in - -
The problem is solved.

Really? So why did you tell _now_ what the real problem was? Especially
when you say:

I got the answers that I was looking for in the
first two responses to my question.

I'm pretty sure you have implemented some wrong answers to wrong problems.
You should have started from using simple and logical HTML markup, instead
of div soup, but you decided to dig yourself deeper.

 

[Safalra]

I'm pretty sure you have implemented some wrong answers to wrong problems.
You should have started from using simple and logical HTML markup, instead
of div soup, but you decided to dig yourself deeper.

Surely "Spartanicus"'s suggestion to use list mark-up is The Right
Thing, given that the navigation is logically a list of links?

 

[Greg N.]

Jukka K. Korpela wrote:

I'm pretty sure you have implemented some wrong answers to wrong problems.
You should have started from using simple and logical HTML markup, instead
of div soup, but you decided to dig yourself deeper.

The solution is not on the web site yet, but I now know what to do about
the problem.

I consider my problem solved.

Except that I'm not always sure what you're talking about ) Do you
disagree with what the first two respondents in this thread suggested? Why?

 

[Jukka K. Korpela]

The solution is not on the web site yet, but I now know what to do
about the problem.

That would be fine, but why are you telling us that without telling what
your solution is and what do you know about handling the problem? You
responded to my message without addressing anything I had written, and you
presented some URLs - with the first one containing a wrong approach in
markup (the way I predicted), so what should we think about this?

I consider my problem solved.

I don't know whether you are referring to the problem in the Subject line
or the problem you described in the body of your first message, but I know
that the CSS code suggested does not solve either of them. But if you
consider your problem solved, maybe it was not either of them.

 

[Greg N.]

That would be fine, but why are you telling us that without telling what
your solution is and what do you know about handling the problem?

I am going to mark up my navigation section as list items. I am going to
style the individual list items as "list-style-type:none" in the first
case, and "display:inline" in the second case.

This does what I asked for in my original post, and what I picked up
from the first two replies. I have tested it, and it works under IE and
FF:

<ul>
<li style="list-style-type: none">blabla
<li style="list-style-type: none">blubb blubb
<li style="list-style-type: none">tatata
</ul>

<ul>
<li style="display:inline">blabla
<li style="display:inline">blubb blubb
<li style="display:inline">tatata

You responded to my message without addressing anything I had written,

Well, I gave you the URLs you asked for.

Then, there was my requirement: The difference between the two cases
should be coded in CSS only.

I did not address your suggestion "Well, then change <div> to <span>"
because that does not meet my requirement.

You also said, "No, it shouldn't. See
http://css.nu/pointers/CSS-caveats.html" I did not address this comment
of yours because it was not a response to my question. We can elaborate
on that if you want.

you presented some URLs - with the first one containing
a wrong approach in markup

care to tell me what's wrong with it?

(the way I predicted), so what should we think about this?

What is it you're actually telling me? I'm puzzled. Honestly.

I don't know whether you are referring to the problem in the Subject line
or the problem you described in the body of your first message, but I know
that the CSS code suggested does not solve either of them.

It does. See above.

 

[Jukka K. Korpela]

I am going to mark up my navigation section as list items. I am going to
style the individual list items as "list-style-type:none" in the first
case, and "display:inline" in the second case.

If that solves your problem, then the problem was neither of those that you
presented. (I can see a problem _created_ by display: inline, since it
makes the links adjacent; whether it is a serious problem depends on the
link texts.)

 

[Greg N.]

If that solves your problem, then the problem was
neither of those that you presented.

What are you talking about? I was looking for ways to present items line
by line, or, by changing the css only, side by side. That's what I
asked for, and that's what does it.

(I can see a problem _created_ by display: inline,
since it makes the links adjacent;

No it does not. For me. Under IE and FF.

 

[Safalra]

No it does not. For me. Under IE and FF.

Unfortunately many badly implemented user-agents whose programmers were
unfamiliar with the concept of 'usability' decided not to render
whitespace between consecutive links, making them appear as one long
link to the poor user.

 

[Greg N.]

Unfortunately many badly implemented user-agents ...
decided not to render whitespace between consecutive links,
making them appear as one long link to the poor user.

Ok. Interesting. I have put spaces (&nbsp between my links.
That means I'm safe in this regard, no?

 

[Safalra]

Unfortunately many badly implemented user-agents [snip]
decided not to render whitespace between consecutive links,
making them appear as one long link to the poor user.

Ok. Interesting. I have put spaces (&nbsp between my links.
That means I'm safe in this regard, no?

Alas, no. Take a look at the Web Content Accessibility Guidelines:

http://www.w3.org/TR/WCAG10-TECHS/#tech-divide-links

Specifically: "Until user agents (including assistive technologies)
render adjacent links distinctly, include non-link, printable
characters (surrounded by spaces) between adjacent links."

In other words, the characters must be printable. The standard is to
put a 'pipe' (the | character) between the links, and you've probably
noticed this on many websites (take a look at the top of
http://www.w3.org/ itself for example).

 

[Adrienne]

Alas, no. Take a look at the Web Content Accessibility Guidelines:

http://www.w3.org/TR/WCAG10-TECHS/#tech-divide-links

In other words, the characters must be printable. The standard is to
put a 'pipe' (the | character) between the links, and you've probably
noticed this on many websites (take a look at the top of
http://www.w3.org/ itself for example).

<facetious>And that sounds good too </facetious>
Activities vertical bar Technical Reports vertical bar Site Index ...

If it's a list of links, mark it up as a list, use CSS to style it.

 

[Greg N.]

Take a look at the Web Content Accessibility Guidelines:

http://www.w3.org/TR/WCAG10-TECHS/#tech-divide-links

Specifically: "Until user agents (including assistive technologies)
render adjacent links distinctly, include non-link, printable
characters (surrounded by spaces) between adjacent links."

In other words, the characters must be printable. The standard is to
put a 'pipe' (the | character) between the links, and you've probably
noticed this on many websites (take a look at the top of
http://www.w3.org/ itself for example).

I have now implemented what my initial intention was, namely, to use the
same list markup but different CSS to display my navigation section in
either block format:
http://hothaus.de/greg-tour-2003/fyrom.htm
or in inline format:
http://coolhaus.de/iv/03/iv.php?width=716&height=406&alt=Ohrid&h1=Mazedonien&img=img/xl-x2_32.jpg

Now, I have read the atricle about the adjacent links problem, but I am
still wondering if I really should take the trouble to deal with it.
For one, it would mean to depart from my current page layout. Also, I
really have no good judgement how serious (in terms of number of users
affected) the problem really is.

The problem does *not* appear on IE, FF, and Opera, anyway.

I am using a hover effect on my links that allows to distinguish
individual links even if a defective UA strings them together.

I suspect that users of such defective UAs know about the problem and
don't get confused, especially when aided by a hover effect.

The Accessibility Guidelines document says that tis is a low priority
issue, which "may" (not "should") be addressed.

I have a much more serious accessability problem anyways: This is kind
of a photo album application, and due to the amount of image data (up to
half a megabyte per page) it is not really well accessible for people on
slow connections. I guess I'm losing a sizable percentage of potential
visitors due to this fact anyway.

This may sound like heresy to an acessability missionary, but I'm
wondering, given all these facts, if a minor defect in some rare UAs
deserves that amount of pampering.

Question:

Do you know which UAs have the problem, so I can have a look at my logs
and try to find out what the magnitude of the problem is?

Thanks,
Greg

 

[Safalra]

[about problems with adjacent links]

[snip]
I have a much more serious accessability problem anyways: This is kind
of a photo album application, and due to the amount of image data (up to
half a megabyte per page) it is not really well accessible for people on
slow connections. I guess I'm losing a sizable percentage of potential
visitors due to this fact anyway.

This may sound like heresy to an acessability missionary, but I'm
wondering, given all these facts, if a minor defect in some rare UAs
deserves that amount of pampering.

Obviously major issues should be dealt with before minor issues. I was
just being fussy...

Do you know which UAs have the problem, so I can have a look at my logs
and try to find out what the magnitude of the problem is?

As far as I know it's mainly the text-based user-agents like Lynx and
Links. For most websites they only form a tiny percentage of the visits
(on my site, for example, they form only ~0.01% of the hits judging by
user-agent strings).

 

[kchayka]

I have now implemented what my initial intention was, namely, to use the
same list markup but different CSS

Now, I have read the atricle about the adjacent links problem, but I am
still wondering if I really should take the trouble to deal with it.

IMO, you have already dealt with "the adjacent links problem" by using
list markup. The list marker can provide the non-link, printable
character, even if you hide it via CSS. Using good, semantic markup is
better for creating accessible pages than adding kludges like
superfluous content just to satisfy some old, maybe obsolete, guideline.

Note that the W3C mentions "Until user agents [do such-and-such]..." and
that those guidelines are more than 6 years old. User agents have come a
long way since then, especially those in the assitive technology (AT)
category.

Do you know which UAs have the problem, so I can have a look at my logs
and try to find out what the magnitude of the problem is?

Even if 50% of your visitors use some sort of AT, you may find no record
of it in your logs. The most-used screen readers use IE as a rendering
engine, and just identify themselves as IE.

 

[Jukka K. Korpela]

IMO, you have already dealt with "the adjacent links problem" by using
list markup. The list marker can provide the non-link, printable
character, even if you hide it via CSS.

It can, but does it?

I suppose you are thinking of a speech browsers that interprets the HTML
source and ignores any CSS (or applies aural features in CSS, in the remote
future). In such a case, list markup is sufficient.

But it is common to use speech browsers that work "upon" graphic browsers,
reading aloud what appears on screen (by checking what characters the I/O
routines send onto screen). They are completely ignorant of the HTML markup
as such; they only "see" the document as formatted with CSS.

Note that the W3C mentions "Until user agents [do such-and-such]..."
and that those guidelines are more than 6 years old. User agents have
come a long way since then, especially those in the assitive technology
(AT) category.

Unfortunately, the progress has been slow.

But there's more. Think about seeing, on a graphic browser, links like

foo bar zap zip zap zup ump

Are there seven links, or less? Maybe "foo bar" is one link? If links are
underlined, breaks in underlining may give a hint. Too subtle?

There are various approaches to such problems, and you might ultimately
decide to ignore some of the problems. But separating adjacent links is
still an issue, and will always be.