Forum Moderators: open
I occasionally encounter "& #149;" (space added here in case it does something funny), which supplies a square bullet character. It's not standard, I remember reading somewhere, and it's conspicuously absent from all the special character tables I've seen. Therefore, though it's never given me any trouble, I've gone to great lengths to avoid it.
I've also encountered, in some source code, what looks to be an ASCII version of this square bullet... a small, square bullet character... and I've also wondered whether this is OK in source code? I figure if the ampersand isn't, this probably shouldn't be either.
If the latter character is OK, though, how do I generate it in a text editor? If not, what's a good way to make a bullet besides a small gif?
[pre]
<ul>
<li>item one</li>
<li>item two</li>
</ul>
[/pre]and then in your CSS you do..
[pre]
ul {
list-style-type: square;
}
[/pre]
▪ (Unicode (hex))
That's actually what is referred to as a Geometric Shape when using my FP interface and inserting various symbols. The FP library has a ton of em'. I'm not too certain how compatible that code is. As you can see, it does not display correctly here at the board.
If the latter character is OK, though, how do I generate it in a text editor? If not, what's a good way to make a bullet besides a small gif?
I don't think it is possible. I've searched all of my resources (which are few) and I cannot locate any standard code that reproduces a sqaure bullet in the sense that you are referring to.
I know exactly what you mean, I've made plenty of those square bullet graphics in my design career. I've been replacing most bullet separators in addresses with a small round bullet (·) or a pipe (¦) if it looks good.
Onya
Woz
Unicode Chart [unicode.org]
Hey Woz, try a search in google for ·, check out the results. I don't think Googlebot understands that one. ;)
>I don't think Googlebot understands that one.
I believe that is because s/he is reading it as raw html as it has not been implemented correctly by the author. It looks OK in browsers as long as it is implemented correctly.
Try a search in google for ☺ , well, you get the idea.
Onya
Woz
I did find this page [pemberley.com] via Google that talked about the character set that includes "&149;" (interesting, btw, to see how to get PR7):
The characters 128-159 are not used in ISO 8859-1 and Unicode, the character sets of HTML. MS-Windows uses a superset of ANSI/ISO 8859-1, known to experts as "Code Page 1252 (CP1252)", a Microsoft-specific character set with additional characters in the 128-159 range (also known as the "C1" range).
There's an accompanying chart that indicates that "ALT-0149" and "•" both produce the "Bullet" character. In the chart, it displays as a small square... but, in my tests, the square is rotated 45-degrees and displays as a diamond or whatever as the font size changes.
I've copied and pasted the bullet in here >> • << and it's showing as a square as I'm looking at it now, but when preview it, it's practically a circle. Reducing my display size doesn't get it back to the square I'm seeing. Not sure what's going on, but it's curious.
Anyway, my question wasn't about bulleted lists... I should have made that clearer... but about generating this character, or something roughly equivalent, in a way that should work across browsers... to work much as I imagine the · was intended to work, sort of like a more attractive hyphen to space out a list of words, or to use as a bullet character but not in a a bulleted list.
Can I assume that • is OK across browsers even though • is not, or is the limitation still whether the character is installed on the viewer's machine?
Also, how is the character generated in ASCII? I tried ALT-149 in my text editor, thinking that might do it, but it doesn't. I've seen it in html code... I've just pasted it in above... so it seems to be part of some character set, but I can't find it in charts and can't generate it.
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
Hmmm, now I know why my pipe (¦) appears as a solid line on various sites that I design and why it appears as it should on those that are not using that charset. I prefer the solid line as opposed to the dashed line.
I have a whole library of symbols (in FrontPage) that I can insert into html. Some generate ascii code and others appear just as they do in normal view. I can only assume it has everything to do with the charset for the document. Would that be correct?
Also, how is the character generated in ASCII?
Guess it depends on what tool you use. In UltraEdit, I can choose to insert about any character, including this one.
Guess it depends on what tool you use.
I'm using NoteTab Pro and haven't been able to find anything on special characters in the documentation.
I can only assume it has everything to do with the charset for the document.
I remembered "charset" and in fact looked for it in the pages I was referencing before I posted my last post, but I didn't see it. What I saw instead, on some pages, were doctypes that I'm guessing might have a lot more to do with things now. I'm using HTML 4.01 Transitional//EN in just about all of what I'm doing. How much have doctypes supplanted charset?
How much have doctypes supplanted charset?
AFAIK, these two specify different things, i.e. the HTML version used (doctype) vs. the character encoding (charset). I use them both.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">..specifies the version of html that the document is written in and..
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">..specifies the character set it is written in.
now I know why my pipe (¦) appears as a solid line on various sites
I usually try to avoid using the vertical bar (aka ¦ ), instead I use a left hand border to separate links instead (this makes a lot more sense since the bar is part of the style, not the content).
my question wasn't about bulleted lists... I should have made that clearer... but about generating this character, or something roughly equivalent, in a way that should work across browsers...
Eh? but bulleted lists ARE the way to generate this character is a cross-browser way. So why try and re-invent the wheel?
I usually try to avoid using the vertical bar (aka ¦ ), instead I use a left hand border to separate links instead (this makes a lot more sense since the bar is part of the style, not the content).
Ooh, that is an interesting concept. Something like this...
a{border-left:1px solid #000;}
How do you get the space between the border and link?
link ¦ link ¦ link
<ul id="linklist">
<li><a href="#">link one</a></li>
<li><a href="#">link two</a></li>
<li><a href="#">link three</a></li>
</ul>
and then..
#linklist li {
display: inline;
border-right: 1px solid #000;
padding: 0 5px 0 6px;
margin: 0;
}
in the CSS. Space between the links and the bar is controlled by the padding.
Eh? but bulleted lists ARE the way to generate this character is a cross-browser way. So why try and re-invent the wheel?
grahamstewart - There are all kinds of lists. I'm hoping this one displays correctly on your machine...
Word1 • Word2 • Word3 • Word4 • Word5
In other words, I want a horizontal inline display, but I didn't have the vocabulary to describe it until I saw your code up above. Looking at your example for a list of links separated by vertical bars, which is pretty ingenious, I suppose it's possible to adapt your example with the square bullet and then make it an inline display.
For vertically displayed bulleted lists, I tend not to like the unordered list tag... it indents the lists in a way that I find unattractive. I usually like to maintain a clean left margin, and <ul> breaks that up. What I've done in those cases is to use little graphic bullets, but that's a super drag... It's something I'd go through for myself, but I'd prefer not to ask a client to do so, particularly where I'm just trying to clean up questionable code I find as simply as possible and not make them do a major redesign.
I'm still wondering whether • is a satisfactory substitute for • -- if it is, it would solve my immediate problem, which is what to tell a client to do about the • character.
Also, what is the little square ASCII character I'm seeing, which I've pasted in up above? Is it valid in HTML?
About doctype and charset, I'm hardly seeing charset used on sites (including this one) that are specifying the doctype, and I'm wondering if there's a reason. That's what made me think the doctype might have subsumed charset. Also, I'm seeing that some sites are specifying UTF encoding, perhaps another level of this, that I don't understand at all.
We've got at least three things going here -- named HTML entities (such as ·), ASCII characters and Unicode.
Low ASCII (entites 1-127) use 7 bits for the character, the eighth bit is used as a parity check. Low ASCII characters are going to be available on all browsers and platforms.
High ASCII (entities 128-255) use all eight bits for the character. High ASCII extends the ASCII set to include accented letters and other stand-alone characters.
But without the parity check, there can be cross-platform surprises. Between entities 128 and 159 there is a "disputed zone" where different platforms have appropriated the numbers differently. And you'll notice that our little baby - 149 - falls right in that range. From 160-255 there is no dispute.
Adding in more chaos, there's the question of the browser's native fonts. I believe that HTML entities are rendered by the browser's natively installed font, and not the declared font-family list. So it's very easy to use a character representation that ends up displaying as the hollow rectangle (unknown character) on some set up or other.
When I view Robert's msg#16 on Opera 7.11 / Win98, the pasted in high ASCII characters render as round bullets. But when I look in the post editing textarea, still in Opera, they now render as square bullets. I'm sure that other members are seeing something different.
I thought I had a solution - use:
<ul style="list-style-type:square"> and
<li style="display:inline>.
But guess what? The square is only displayed when the list item is rendered as a block element and changing it to inline removes the graphic. Sorry, I've got no definitive answer here. Perhaps my comments will help to trigger something for someone else.
Please forgive my ignorance with this follow up, but where is "•" in all this mix? That's the Unicode HTML Code, I understand, and it displays OK even in NS4.03, the oldest browser I have, as well as in IE5.5. Is it safer, or less safe, to use, than "•"? As you say, that may have more to do with the default font than with the browser...
Here's something [truetype.demon.co.uk] I came across on Truetype and Unicode, from which I'll excerpt some highlights...
Unicode Fonts?
There's no definition of what constitutes a Unicode font. However the following fonts contain enough of "Unicode space" to be considered useable in many environments where a single font must work for many languages and symbol systems.Lucida Sans Unicode by Bigelow & Holmes....
Times New Roman, Arial, Courier (4 styles each) and Impact....
Bitstream Cyberbit...
The page goes into the peculiarities of each of the above that I'm chopping off in this excerpt. Not sure what this says about the little square.
In the meantime, since I first posted, I've stumbled across • in two other sites where I've reason to look at the source code.
it displays OK even in NS4.03
In my NN4.8 both of these display as a large ROUND bullet. In my Opera 7.11, both display as a diamond - not a square.
I think this may be more of an OS issue than a browser issue - my machine is Win98 (I don't lightly upgrade my OS once I have a relatively stable installation going!) At least nothing is literally displaying "•"
I remember that Win95 did not offer unicode support in its final release, even though the beta relases did. There must be a nasty bugaboo in there. Unicode characters are 16-bit rather than 8-bit. That must have something to do with it.
In the mean time, I think I've found a good overview page here:
[hclrss.demon.co.uk...]
The HTML 4.0 Specification made a major step towards internationalizing the World Wide Web by adopting the Universal Character Set (as specified in ISO/IEC 10646 Information Technology - Universal Multiple-Octet Coded Character Set (UCS)) as the document character set for HTML. The UCS as specified in ISO/IEC 10646-1:2000 is precisely equivalent to the Unicode Standard 3.0....some character encodings (for example UTF-8) allow any of the characters in the document character set to be included, while others (for example ISO-8859-1 or SHIFT_JIS) only allow for subsets. However, characters that are not allowed for in a character encoding can still be included in an HTML document by using character references.
And for web browser/platform support:
[hclrss.demon.co.uk...]
The two major Web browsers for Windows include support for Unicode TrueType fonts and so can display almost any character that you are likely to find on a Web page. Internet Explorer 6 supports many more scripts than Netscape Navigator 6. Opera 6 and Mozilla also support Unicode.Web browsers for Mac OS 9 are not as good as those for Windows at displaying multilingual pages; they do not include support for Unicode fonts and they can only display characters that are supported by an installed Apple Language Kit.
I should mention here that Macintosh OS X (10.2) offers full unicode support.
So, if you use the HTML Unicode reference, it sounds like you want to ensure UTF-8 as the character encoding. And you may want to check whatever solution you arrive at on an older Mac -- before you recommend anything to a client.
At this point, I know I'll be avoiding the little square bullet for a good while into the future.
There are all kinds of lists.
Yes there are... but they should all be correctly marked up as lists in the HTML (e.g. by using the <ul>/<ol> and <li> tags).
HTML defines the semantics of the page content.. how the content is then displayed is a matter of 'style' which is controlled by CSS.
For vertically displayed bulleted lists, I tend not to like the unordered list tag... it indents the lists in a way that I find unattractive.
Indent is a matter of style.. so you adjust it using CSS..
ul {
list-style-position: inside;
margin-left: 0;
}
Never avoid using HTML tags because of the way they render. Your HTML should always make sense.. its up to your CSS to make it look pretty.
;)
...its up to your CSS to make it look pretty.
Well said. But the browser companies have to ge their act together for it to be all on my back.
Have you ever placed a list on your page when there's a floated div to the left? I just spent a day on a layout where cross-browser there seems to be no current solution. Explorer and Opera measure padding or margin from the outside of the parent div, Moz and Safari measure the same quantities from the border of the floated div. I ended up not using the list tag just so I could get the formatting to look sane cross-browser.
It should have been a 3 minute mark-up job, but it took 2 hours. And that's far from the only cul de sac in CSS-land.
This past week I also resorted to a <center> tag one more time -- all because of cross-browser issues. Just as I resort to images instead of square bullets and so on. The standards theory would be oh so nice, if only...
No one buys from a site because it has standard mark-up. They buy because they can receive the communication and it moves them top respond.
Now I'm not espousing cowboy code, street code, or whatever you want to call it. But it's still true that if you want to write to standards AND look good cross-browser, then you need to make a bunch of trade-offs that shouldn't oughta be.
No one buys from a site because it has standard mark-up.
True - but proper mark-up means better spidering/indexing which means more visits by potential clients.
Current CSS implementations are not perfect - but they are the best we have got - and they are certainly a lot better than messing with extended characters that may or may not render correctly on different browsers.
This past week I also resorted to a <center> tag one more time -- all because of cross-browser issues
Eh? Whats wrong with using auto on margin-left/right?
That should work correctly on modern browsers (works fine on IE6/opera7/NN7). To support older relics just use text-align:center on the parent element.
Or you could even use <div align="center"> in HTML4 Transitional. Even that is more 'correct' than <center>
I resort to images instead of square bullets and so on..
I'd rather have my HTML/CSS correct.
So what if a few ancient or broken browsers accidentally display a round bullet instead of a square? Does that really break your site that much?
