Table with Bullet-Points in Cells

I am creating an HTML table that is 3 columns by 6 rows.

Each cell contains a word.

How can I insert a Bullet Point before each work in my HTML table using CSS?

Thanks,

Debbie

Maybe wrap the word in a <p> and use left padding and a background image, or use p:before.

It depends on your structure but you could also do something like thi.


<!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">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Untitled Document</title>
<style type="text/css">
p {
    display:list-item;
    list-style:disc inside;
    padding:0 0 0 14px;
    margin:0;
}
</style>
</head>
<body>
<table>
    <tr>
        <td><p>test</p></td>
        <td><p>test</p></td>
        <td><p>test</p></td>
        <td><p>test</p></td>
    </tr>
</table>
</body>
</html>


As a single word I would advise AGAINST using P – a single word is NOT a paragraph… Use a span instead. Otherwise, Paul’s answer makes sense…

Though honestly, even though it would take a few extra bytes and a extra handshake, I’d be tempted to use a background-image and apply it to the TD.


td {
  padding-left:24px; /* image width plus any desired padding */
  background:url(images/bullet.png) center left no-repeat;
}

Which also deals with how most browsers don’t use the same size/appearance bullets, and would let you get a little more fancy with their appearance. It would also be cached across pages as opposed to the SPAN or P inside the markup.

Shame we can’t rely on generated content yet – a td:before { content:“·”; } would also be a nice solution.

<p>Bullpoop.</p>

:smiley:

You know we disagree here :slight_smile:

It depends on the context but a single word can be a paragraph. The shortest sentence can be one word.

shortest possible complete sentence is something like “Go!”

A paragraph is defined as one or more sentences expressing a single train of thought so the one word can be a paragraph.

Context being the important part – you already have a semantic tag saying that it’s table data, the extra semantics applied by the paragraph tag is redundant/pointless and possibly damaging to accessibility.

Semantics isn’t just about slapping P around anything that happens to be CDATA.

I know this will come across as pedantic, but I’m even more liberal in my definition of a ‘paragraph’. If you go back to the Greek origins of the word, the ‘graph’ part applies not only to writing but to drawing, painting etc. Para means ‘along side’ or ‘beside’. So I’m happy to wrap an image in <p> tags with no associated text, as it’s still consistent with ‘something drawn or written beside (something else)’. I know that’s not actually the reason why the word ‘paragraph’ came into English, and I’m sure that’s not what people had in mind when they established the <p> element, but it works for me (when I’m trying to justify non-standard uses of that element). :smiley:

What problems might it cause?

Well it often breaks column and row scope in screen readers if you don’t explicitly state them. I’ve had that more than once where using block level containers inside TD often “lose the association” to their parent TH on the row or in relation to TH inside the THEAD. (assuming you are even building the table PROPERLY). It can be fixed by stating either “headers=” on the TD or “scope=” on the associated TH, but why use extra markup if you don’t have to?

But again, with most developers not even knowing that CAPTION, TBODY, THEAD, TFOOT, COLGROUP, COL or TH even exist (much less Mozilla still not even supporting COL properly some [b]thirteen years[/b] after the bugzilla entry was made), much less the concept of the SCOPE, AXIS or HEADERS attributes it’s probably why so many people think that tables are always broken in screen readers-- when in general they’re just not using them right.

See how I feel the need to backhand someone every time I see:


<td colspan="8" class="header" align="center"><b><font size="+2">Table Title</font></b></td>

doing the job of


<caption>Table Title</caption>

AS a rule of thumb I’ve taken to saying that if you end up using numbered heading tags, paragraphs or DIV inside your TD, (or LI) it ceases to be table data (or list items) with VERY rare exceptions

Thanks Jason. Interesting info (the whole post) and duly noted. :slight_smile: AXIS is a new one to me, so I’ll check it out.

How about CHAR, CHAROFF, RULES, and FRAME?

The latter two of those along with “border” surprisingly NOT deprecated on TABLE. The FRAME attribute is often handy for dealing with webkit’s idiotic handling of CAPTION when cellspacing is involved.

No, I wasn’t aware of those either … and something makes me feel kinda glad of that, too. :smiley:

I used “Insert Symbol” in OpenOffice Writer to create square bullets in my text document.

Next I cut and pasted my bulleted words into my IDE and the bullets seemed to carry-over like any other character. So, problem temporarily solved.

Couldn’t you just use some ASCII code or whatever to tell your browser to render a bullet point?

Here is a snippet of my code…


<table id="myTable" cellspacing="15" summary="Some table...">
							<tr>
								<td>&#9642; Friendly</td>
								<td>&#9642; Helpful</td>
								<td>&#9642; Energetic</td>

Debbie

That’s an html solution - not css:)

Use •


<td>&bull; Friendly</td>


Incorrect. None. Infact it might be better since the p is the jump paragraph hotkey. So instead of dealing with the table, they can read the words.

None, other than the table itself.

A screen reader is not smart. It will only guess so much before it says “Heck I don’t know my header, here is my value.” Thus why scope or headers are NEEDED not just bloat code.

They ARE smart enough to realize a TH inside THEAD should have scope=col and that TH inside TBODY should have scope=row by default… which makes perfect sense. Unfortunately that breaks if you put block level containers inside the TD… necessitating the extra elements.

Just part of why I’d prefer an inline-level element that adds no extra semantic meaning to the content – as applying the wrong semantics can be worse than having none at all.

You know, thinking on this, I probably would go with:


td:before {
  content:"\\2022";
}

Doesn’t work in IE7 or earlier – oh well. Oh, and that’s unicode, for utf-8 you’d want to swap 2022 for E280A2 I think…

Off Topic:

I just love how :before actually puts it INSIDE the element… that makes sense.

Normally I dislike the mere idea of generated content, but those bullets are presentational in nature so…

Sorry Jason, still incorrect. You need to provide proof. All the stuff I am seeing does not say what are saying. If I understand you correctly, you are saying


<table> 
<tr>
 <th>heading</th>

is the same as


<table>
<tr>
  <th scope='col'></th>

Looking at the spec, it says a value must be given, and there is no default value. So that would lead me to say it may be announced as a header, but not to what, which is the opposite what you said. I would say some screen readers might be able to grab the header by force (hotkeys), but would not rely on that method.

Maybe read Tables with JAWS and MAGic and [url=http://www.freedomscientific.com/Training/Surfs-up/Table_Reading_Commands.htm]Table Reading Commands for JAWS and [url=http://www.eramp.com/david/tablesample2.htm]Table examples

No Ryan, I’m saying that:


<table>
  <thead>
  	<tr>
  		<td></td>
  		<th>column 1</th>
  		<th>column 2</th>
  	</tr>
  </thead><tbody>
  	<tr>
  		<th>row 1</th>
  		<td>data 1</td>
  		<td>data 2</td>
  	</tr>
  </tbody>
</table>

Is generally treated the same as


<table>
	<tr>
		<td></td>
		<th scope="col">column 1</th>
		<th scope="col">column 2</th>
	</tr><tr>
		<th scope="row">row 1</th>
		<td>data 1</td>
		<td>data 2</td>
	</tr>
</table>

by screen readers like Jaws, webbIE, etc… Which last time I checked did work. It makes sense for them to be treated that way since pretty much THEAD is going to be the headings for the body area – that’s what THEAD and TBODY are FOR. The associations are retained. Simply adding a DIV inside that row TH breaks the association. If I remember right Jaws also broke TBODY ones if you had more than one TH… makes sense since it makes no sense for multiple TH per row! I think it also doesn’t form that association if you don’t have a THEAD and explicit TBODY. (the assumed automatic one most browsers don’t usually even bother making in their DOM)

THEAD and TBODY, check 'em out. NOT what they are actually for by the spec, but it is how they are often treated. (while TFOOT languishes as pointless in most cases)

<THEAD> has no implicit value as you suggest. All Thead does is if you put headers in, and your table hits a page break, the headers are reprinted.

“This division enables user agents to support scrolling of table bodies independently of the table head and foot. When long tables are printed, the table head and foot information may be repeated on each page that contains table data.” Tables in HTML documents
Therefore scope is not applied by default. A DIV breaks association because THEAD, TBODY and TFOOT are basically a div (as quoted above). :slight_smile:

If I remember right Jaws also broke TBODY ones if you had more than one TH… makes sense since it makes no sense for multiple TH per row!)

… uhm multi-level/layer tables.

THEAD and TBODY, check 'em out. NOT what they are actually for by the spec, but it is how they are often treated

Guessing you are seeing this because thead,body and foot are rarely used and when they are it is usually incorrectly. So screen reader manufacturers script it so it reads correctly. Screen readers have to fix code more than people think to make it read correctly.
Take a minute and think, if thead really did what you are thinking I bet money various people would say use thead to solve the issue(s), versus scope or headers/id. Seeing that nobody doesn’t should show that thead is just for layout.

That’s actually what I’ve been SAYING. I’m not saying that’s what it does by the spec – I’m saying it makes sense and it’s how some UA’s handle it.

Though I don’t know if I’d call it “fixing code” so much as behaving to the original intent of HTML. Remember, the reason HTML is so vague on appearance of tags (in fact you’ll be hard pressed to even find it say “must” look a certain way for ANY tag) is that the entire original point of HTML is for saying what things ARE – then letting the user agent best figure out how to handle presenting that to the user.

It was only during the browser wars with the endless extra crap that came to be known as HTML 3.2 (and is now being revived with the HTML 5 idiocy) that we got away from that concept – the point of HTML 4 STRICT and CSS2 being to drive us back to that original point making separation of presentation from content a reality. A really nice reality.

But like anything else, it goes in cycles. By the time of HTML 6 (or whatever they’ll call it by then with the "let’s get rid of versioning lunacy) we’ll probably see 90% of the new tags in 5 dropped as redundant just as they were for 4 Strict when everyone realizes how malfing mind-blowingly STUPID HTML 5 really is… or as I’m starting to call it, HTML 3.25.