After proudly coloring my liststyle bullet without any image url or span tags, via:
ul{ list-style: none; padding:0; margin:0; }
li{ padding-left: 1em; text-in
You ca try this:
ul { list-style: none;}
li { position: relative;}
li:before {
position: absolute;
top: 8px;
margin: 8px 0 0 -12px;
vertical-align: middle;
display: inline-block;
width: 4px;
height: 4px;
background: #ccc;
content: "";
}
It worked for me, thanks to this post.
Never faced this problem before (not worked much on email, I avoid it like the plague) but you could try declaring the bullet with the unicode code point (different notation for CSS than for HTML): content: '\2022'
. (you need to use the hex number, not the 8226 decimal one)
Then, in case you use something that picks up those characters and HTML-encodes them into entities (which won't work for CSS strings), I guess it will ignore that.
You shouldn't use LIs in email. They are unpredictable across email clients. Instead you have to code each bullet point like this:
<table width="100%" cellspacing="0" border="0" cellpadding="0">
<tr>
<td align="left" valign="top" width="10" style="font-family:Arial, Helvetica, Sans-Serif; font-size:12px;">•</td>
<td align="left" valign="top" style="font-family:Arial, Helvetica, Sans-Serif; font-size:12px;">This is the first bullet point</td>
</tr>
<tr>
<td align="left" valign="top" width="10" style="font-family:Arial, Helvetica, Sans-Serif; font-size:12px;">•</td>
<td align="left" valign="top" style="font-family:Arial, Helvetica, Sans-Serif; font-size:12px;">This is the second bullet point</td>
</tr>
</table>
This will ensure that your bullets work in every email client.
This website could be helpful,
http://character-code.com
here you can copy it and put directly on css html
You are facing a double-encoding issue.
■
and •
are absolutely equivalent to each other. Both refer to the Unicode character 'BULLET' (U+2022) and can exist side-by-side in HTML source code.
However, if that source-code is HTML-encoded again at some point, it will contain ■
and &#8226;
. The former is rendered unchanged, the latter will come out as "•" on the screen.
This is correct behavior under these circumstances. You need to find the point where the superfluous second HTML-encoding occurs and get rid of it.
Lea's converter is no longer available. I just used this converter
Steps:
Dec code points
Unicode U+hex notation
(eg U+2022)content: '\2022'
ps. I have no connection with the web site.