unicode (UTF-8) support is at the point where it can (and should) be nearly universally supported.
Writing … is far preferable to … (or even ...). If you get your character encoding down right, the only entities you have any reason to keep are < and & (nope, not even >). That said, there's many points where you need to make sure it's set correctly.
-1. your files (html, etc.) need to be saved as UTF-8
-2. your html markup needs <meta charset=UTF-8> (but see #3 below)
-3. the http headers sent by your server must also specify the UTF-8 charset (as an example, many web hosts specify ISO-8859-1 by default). If there is a conflict, the browser will almost always choose the charset specified in the http header and ignore what it says in the markup.
-4. if you use a database, it needs to save data in UTF-8
....it must use a UTF-8 collation as well
....your connection to the database needs to specify UTF-8 as well
according to this* episode of shop talk show html5 doesnt require the codes anymore and accepts mostly all of the symbols. it's one of the questions answered towards the end of the show.
to clarify, it's not HTML5 that is "requiring" or "rejecting" those characters. It has to do with what character encoding you use (which Tab Atkins does go on to explain). If your encoding is wrong, you'll still get �s everywhere, regardless of HTML5.
Also, I overlooked in my short list of "acceptable" entities.
hi,
I use this page for symbol reference ever since I can remember http://www.w3schools.com/tags/ref_symbols.asp
one thing bugs me because I never knew what is the difference if to use the symbol and just copy paste it, write the code or the name of that symbol
for example if I want to write "3 dots" (horizontal ellipsis) does it matter ?
It can matter as some text editors don't receive copy and paste exactly as you might think.
In practice, I use the Entity Name (beginning with an ampersand (&) because they are usually descriptive and thus easier to remember.
is easier to remember than
well that makes perfect sense
unicode (UTF-8) support is at the point where it can (and should) be nearly universally supported.
Writing
…is far preferable to…(or even...). If you get your character encoding down right, the only entities you have any reason to keep are<and&(nope, not even>). That said, there's many points where you need to make sure it's set correctly.-1. your files (html, etc.) need to be saved as UTF-8
-2. your html markup needs
<meta charset=UTF-8>(but see #3 below)-3. the http headers sent by your server must also specify the UTF-8 charset (as an example, many web hosts specify ISO-8859-1 by default). If there is a conflict, the browser will almost always choose the charset specified in the http header and ignore what it says in the markup.
-4. if you use a database, it needs to save data in UTF-8 ....it must use a UTF-8 collation as well ....your connection to the database needs to specify UTF-8 as well
fun read
thanks for the article will have a look at it
according to this* episode of shop talk show html5 doesnt require the codes anymore and accepts mostly all of the symbols. it's one of the questions answered towards the end of the show.
*http://shoptalkshow.com/episodes/029-with-tab-atkins/
@dfogge -
to clarify, it's not HTML5 that is "requiring" or "rejecting" those characters. It has to do with what character encoding you use (which Tab Atkins does go on to explain). If your encoding is wrong, you'll still get �s everywhere, regardless of HTML5.
Also, I overlooked
in my short list of "acceptable" entities.yeah dont forget your charset utf-8