<?xml version="1.0" encoding="utf-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Named versus Numeric Entities</title>
	<atom:link href="http://people.w3.org/~dom/archives/2005/04/named-versus-numeric-entities/feed/" rel="self" type="application/rss+xml" />
	<link>http://people.w3.org/~dom/archives/2005/04/named-versus-numeric-entities/</link>
	<description>W3C has the DOM, and the Dom ; pick the one you prefer.</description>
	<lastBuildDate>Thu, 15 Oct 2009 13:14:54 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.5</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Michael</title>
		<link>http://people.w3.org/~dom/archives/2005/04/named-versus-numeric-entities/comment-page-1/#comment-65091</link>
		<dc:creator>Michael</dc:creator>
		<pubDate>Sun, 05 Oct 2008 03:45:54 +0000</pubDate>
		<guid isPermaLink="false">http://people.w3.org/~dom/archives/2005/04/named-versus-numeric-entities/#comment-65091</guid>
		<description>I usually type in the Unicode character directly, finding it easier to read, but I prefer named entities in a few cases: one is where the character is not sufficiently distinct in it&#039;s rendered form. For example, who can tell the difference between a non-breakable space and an ordinary space or even an en space just by looking at it?

Perhaps someone could write a simple Perl or Javascript to translate between the named and numbered entities to make the XML source easier to read.

XML is not as much of a problem as HTML. With XML, it is much easier to do semantic markup. That means that the user can do much more processing on the page, e.g., to extract information. HTML is mostly about presentation. We need to get beyond the limited notion that web pages are purely visual.

Finally, an em dash is usually wider than the letter M. It was named after M, but that should not be taken literally. It is usually as wide as the type size, i.e., in 12 point type an em is 12 points wide, but the type designer can make a little wider or a little narrower, if he finds that that will look better for that font.</description>
		<content:encoded><![CDATA[<p>I usually type in the Unicode character directly, finding it easier to read, but I prefer named entities in a few cases: one is where the character is not sufficiently distinct in it&#8217;s rendered form. For example, who can tell the difference between a non-breakable space and an ordinary space or even an en space just by looking at it?</p>
<p>Perhaps someone could write a simple Perl or Javascript to translate between the named and numbered entities to make the XML source easier to read.</p>
<p>XML is not as much of a problem as HTML. With XML, it is much easier to do semantic markup. That means that the user can do much more processing on the page, e.g., to extract information. HTML is mostly about presentation. We need to get beyond the limited notion that web pages are purely visual.</p>
<p>Finally, an em dash is usually wider than the letter M. It was named after M, but that should not be taken literally. It is usually as wide as the type size, i.e., in 12 point type an em is 12 points wide, but the type designer can make a little wider or a little narrower, if he finds that that will look better for that font.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: BobH</title>
		<link>http://people.w3.org/~dom/archives/2005/04/named-versus-numeric-entities/comment-page-1/#comment-64608</link>
		<dc:creator>BobH</dc:creator>
		<pubDate>Wed, 27 Aug 2008 02:44:39 +0000</pubDate>
		<guid isPermaLink="false">http://people.w3.org/~dom/archives/2005/04/named-versus-numeric-entities/#comment-64608</guid>
		<description>Just a note on your reference to &quot;middle dash.&quot; It&#039;s really &quot;em dash.&quot; An &quot;em space&quot; or &quot;em&quot; comes from old-fashioned typesetting with lead type. An em is a square with each edge the size of the type -- typically 10 points, or 10/72 of an inch for medium-sized text. The unit carries forward into CSS today. An em was used as a standard paragraph indent, and an em dash was supposed to be as wide as an em space. An en space is half the width of an em space, and an en dash is half the width of an em dash -- still wider than a hyphen, which people often mistakenly call a dash. A thin space is still narrower -- one third the width of an em space.</description>
		<content:encoded><![CDATA[<p>Just a note on your reference to &#8220;middle dash.&#8221; It&#8217;s really &#8220;em dash.&#8221; An &#8220;em space&#8221; or &#8220;em&#8221; comes from old-fashioned typesetting with lead type. An em is a square with each edge the size of the type &#8212; typically 10 points, or 10/72 of an inch for medium-sized text. The unit carries forward into CSS today. An em was used as a standard paragraph indent, and an em dash was supposed to be as wide as an em space. An en space is half the width of an em space, and an en dash is half the width of an em dash &#8212; still wider than a hyphen, which people often mistakenly call a dash. A thin space is still narrower &#8212; one third the width of an em space.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Resuna</title>
		<link>http://people.w3.org/~dom/archives/2005/04/named-versus-numeric-entities/comment-page-1/#comment-64245</link>
		<dc:creator>Resuna</dc:creator>
		<pubDate>Tue, 22 Jul 2008 19:42:05 +0000</pubDate>
		<guid isPermaLink="false">http://people.w3.org/~dom/archives/2005/04/named-versus-numeric-entities/#comment-64245</guid>
		<description>To summarize the summary: XML is a problem.</description>
		<content:encoded><![CDATA[<p>To summarize the summary: XML is a problem.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: zed</title>
		<link>http://people.w3.org/~dom/archives/2005/04/named-versus-numeric-entities/comment-page-1/#comment-63110</link>
		<dc:creator>zed</dc:creator>
		<pubDate>Fri, 07 Mar 2008 08:55:59 +0000</pubDate>
		<guid isPermaLink="false">http://people.w3.org/~dom/archives/2005/04/named-versus-numeric-entities/#comment-63110</guid>
		<description>Well, you&#039;ve touched the subject of magic things... Everyone write about XHTML, DOM and such. But noone could help me with this: let&#039;s create true XHTML document in php. Be careful - you cannnot do this without server side script! Did you know? It doesn&#039;t matter how is &quot;content-type&quot; meta set in your HTML header. When browser read this file - it reads it as previously defined content-type. Content-type is really defined via HTTP header send by server. So in php we can generate such header and send it. Like header(&#039;content-type: application/xhtml+xml; charset=utf-8&#039;). Good. Now we can really send XHTML. It MUST be well-formed, or every good browser won&#039;t display it. So... Let&#039;s put an innocent looking &quot;&nbsp;&quot; into our XHTML. And what happened? Why doesn&#039;t it display? Not in Firefox. Not in Opera. W3C validator says the document is well-formed. What&#039;s more, nbsp and other entities ARE really defined in DTD which is pointed in DOCTYPE. What&#039;s more, you can copy and paste DTD URL and check yourself, the named entities ARE REALLY DEFINED THERE. W3C validator sees them. Browsers don&#039;t. The only way I&#039;ve found is... Encode all named entities as numeric entities. Email me if I&#039;m wrong, but I think it&#039;s because of that most browsers DON&#039;T really support XHTML+XML content. Their parsers are BUGGY and cannot make any use of DTD URL in DOCTYPE. Before yesterday - I thought it&#039;s no other way out except quit trying to use XHTML (by serving it without defining proper content-type header). The solution came accidentaly. I&#039;ve imported a DOM node from one HTML file to another. It contained nbsp-entity. And the result file displayed well in Opera with XML header, which, as I thought, was impossible. So i checked the source and found that nbsp-entity was converted to numeric by DOM-tree processing code.</description>
		<content:encoded><![CDATA[<p>Well, you&#8217;ve touched the subject of magic things&#8230; Everyone write about XHTML, DOM and such. But noone could help me with this: let&#8217;s create true XHTML document in php. Be careful &#8211; you cannnot do this without server side script! Did you know? It doesn&#8217;t matter how is &#8220;content-type&#8221; meta set in your HTML header. When browser read this file &#8211; it reads it as previously defined content-type. Content-type is really defined via HTTP header send by server. So in php we can generate such header and send it. Like header(&#8217;content-type: application/xhtml+xml; charset=utf-8&#8242;). Good. Now we can really send XHTML. It MUST be well-formed, or every good browser won&#8217;t display it. So&#8230; Let&#8217;s put an innocent looking &#8220;&amp;nbsp;&#8221; into our XHTML. And what happened? Why doesn&#8217;t it display? Not in Firefox. Not in Opera. W3C validator says the document is well-formed. What&#8217;s more, nbsp and other entities ARE really defined in DTD which is pointed in DOCTYPE. What&#8217;s more, you can copy and paste DTD URL and check yourself, the named entities ARE REALLY DEFINED THERE. W3C validator sees them. Browsers don&#8217;t. The only way I&#8217;ve found is&#8230; Encode all named entities as numeric entities. Email me if I&#8217;m wrong, but I think it&#8217;s because of that most browsers DON&#8217;T really support XHTML+XML content. Their parsers are BUGGY and cannot make any use of DTD URL in DOCTYPE. Before yesterday &#8211; I thought it&#8217;s no other way out except quit trying to use XHTML (by serving it without defining proper content-type header). The solution came accidentaly. I&#8217;ve imported a DOM node from one HTML file to another. It contained nbsp-entity. And the result file displayed well in Opera with XML header, which, as I thought, was impossible. So i checked the source and found that nbsp-entity was converted to numeric by DOM-tree processing code.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jon</title>
		<link>http://people.w3.org/~dom/archives/2005/04/named-versus-numeric-entities/comment-page-1/#comment-4190</link>
		<dc:creator>Jon</dc:creator>
		<pubDate>Fri, 30 Dec 2005 22:31:51 +0000</pubDate>
		<guid isPermaLink="false">http://people.w3.org/~dom/archives/2005/04/named-versus-numeric-entities/#comment-4190</guid>
		<description>That&#039;s not a &quot;middle dash&quot;, it&#039;s an &quot;em dash&quot;, named after the letter M, as it should be the same width as an M in the same font.  There&#039;s also an &quot;en dash&quot;.  See the link for more info.

Also, as far as HTML, I believe browser support for named entities is not as good as for numbered entities, which irritates me.</description>
		<content:encoded><![CDATA[<p>That&#8217;s not a &#8220;middle dash&#8221;, it&#8217;s an &#8220;em dash&#8221;, named after the letter M, as it should be the same width as an M in the same font.  There&#8217;s also an &#8220;en dash&#8221;.  See the link for more info.</p>
<p>Also, as far as HTML, I believe browser support for named entities is not as good as for numbered entities, which irritates me.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: gregR</title>
		<link>http://people.w3.org/~dom/archives/2005/04/named-versus-numeric-entities/comment-page-1/#comment-2748</link>
		<dc:creator>gregR</dc:creator>
		<pubDate>Tue, 26 Apr 2005 15:27:38 +0000</pubDate>
		<guid isPermaLink="false">http://people.w3.org/~dom/archives/2005/04/named-versus-numeric-entities/#comment-2748</guid>
		<description>Excellent ! Thanks for sharing with us your knowledge</description>
		<content:encoded><![CDATA[<p>Excellent ! Thanks for sharing with us your knowledge</p>
]]></content:encoded>
	</item>
</channel>
</rss>
