<?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: Decision or Bug?</title>
	<atom:link href="http://simplebits.com/notebook/2008/03/25/ie8-2/feed/" rel="self" type="application/rss+xml" />
	<link>http://simplebits.com/notebook/2008/03/25/ie8-2/</link>
	<description>Handcrafted pixels &#38; text from Salem, Massachusetts.</description>
	<lastBuildDate>Tue, 08 Dec 2009 23:15:49 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1.2</generator>
	<item>
		<title>By: Jaryl Sim</title>
		<link>http://simplebits.com/notebook/2008/03/25/ie8-2/#comment-11328</link>
		<dc:creator>Jaryl Sim</dc:creator>
		<pubDate>Wed, 16 Apr 2008 18:09:15 +0000</pubDate>
		<guid isPermaLink="false">http://www.simplebits.com/wp/notebook/2008/03/25/ie8-2/#comment-11328</guid>
		<description>The answer can be found here: http://www.joelonsoftware.com/items/2008/03/17.html
It&#039;s a pretty long read, but it explains why they make such decisions. It&#039;s all business, folks =) Microsoft will be damned if they followed the spec, damned if they don&#039;t.
</description>
		<content:encoded><![CDATA[<p>The answer can be found here: <a href="http://www.joelonsoftware.com/items/2008/03/17.html" rel="nofollow">http://www.joelonsoftware.com/items/2008/03/17.html</a><br />
It&#8217;s a pretty long read, but it explains why they make such decisions. It&#8217;s all business, folks =) Microsoft will be damned if they followed the spec, damned if they don&#8217;t.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Pete Rossetti</title>
		<link>http://simplebits.com/notebook/2008/03/25/ie8-2/#comment-11327</link>
		<dc:creator>Pete Rossetti</dc:creator>
		<pubDate>Thu, 10 Apr 2008 00:53:18 +0000</pubDate>
		<guid isPermaLink="false">http://www.simplebits.com/wp/notebook/2008/03/25/ie8-2/#comment-11327</guid>
		<description>I agree a bug - but I remember you saying in you Bulletproof book to set  the font size to small globally then set font size as needed using %&#039;s.
You almost gave the impression that it was not a good idea to use px, for accessibility reasons.
But I guess if browsers didn&#039;t behave erratically we needn&#039;t address the issue of how we size fonts anymore?
</description>
		<content:encoded><![CDATA[<p>I agree a bug &#8211; but I remember you saying in you Bulletproof book to set  the font size to small globally then set font size as needed using %&#8217;s.<br />
You almost gave the impression that it was not a good idea to use px, for accessibility reasons.<br />
But I guess if browsers didn&#8217;t behave erratically we needn&#8217;t address the issue of how we size fonts anymore?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: jeff</title>
		<link>http://simplebits.com/notebook/2008/03/25/ie8-2/#comment-11326</link>
		<dc:creator>jeff</dc:creator>
		<pubDate>Mon, 07 Apr 2008 06:27:22 +0000</pubDate>
		<guid isPermaLink="false">http://www.simplebits.com/wp/notebook/2008/03/25/ie8-2/#comment-11326</guid>
		<description>It makes no sense. You talk about accessibility? The visually impaired people can read just fine with zooming features that come with operating systems. They prefer the zooming feature over making the fonts bigger than other elements because it makes the web design look more consistent and remember, they are pretty capable of reading or listening with proper tools.
It&#039;s amazing that the deaf is still the most ignored - audios... videos are popular but captioning and transcriptions are scarce and there are NO tools that allow the deaf to read what they are saying. I am deaf myself and it&#039;s irritating to read comments like that as if the blind is helpless and cannot access your website. They CAN as long as you use proper html/css. If you&#039;re designing visually, don&#039;t expect the blind to be wow&#039;d. They probably won&#039;t. They&#039;re more focused on content than visual presentation. Just be sure they get the content they need.
So, I believe that the font should not be allowed to resize if other elements remain the same sizewise. I like IE7&#039;s Zooming feature - which basically zooms ALL elements, not just text. Of course, that was Opera&#039;s first.
</description>
		<content:encoded><![CDATA[<p>It makes no sense. You talk about accessibility? The visually impaired people can read just fine with zooming features that come with operating systems. They prefer the zooming feature over making the fonts bigger than other elements because it makes the web design look more consistent and remember, they are pretty capable of reading or listening with proper tools.<br />
It&#8217;s amazing that the deaf is still the most ignored &#8211; audios&#8230; videos are popular but captioning and transcriptions are scarce and there are NO tools that allow the deaf to read what they are saying. I am deaf myself and it&#8217;s irritating to read comments like that as if the blind is helpless and cannot access your website. They CAN as long as you use proper html/css. If you&#8217;re designing visually, don&#8217;t expect the blind to be wow&#8217;d. They probably won&#8217;t. They&#8217;re more focused on content than visual presentation. Just be sure they get the content they need.<br />
So, I believe that the font should not be allowed to resize if other elements remain the same sizewise. I like IE7&#8242;s Zooming feature &#8211; which basically zooms ALL elements, not just text. Of course, that was Opera&#8217;s first.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Andrew Vit</title>
		<link>http://simplebits.com/notebook/2008/03/25/ie8-2/#comment-11325</link>
		<dc:creator>Andrew Vit</dc:creator>
		<pubDate>Thu, 03 Apr 2008 02:16:25 +0000</pubDate>
		<guid isPermaLink="false">http://www.simplebits.com/wp/notebook/2008/03/25/ie8-2/#comment-11325</guid>
		<description>@Matt Wilcox
Not sure if we&#039;re really on topic anymore, but it&#039;s an interesting discussion anyway: I&#039;m not arguing your points on the meaning of physical measurement units, but I don&#039;t think you get what I mean to say... I didn&#039;t mean that one should hold up a ruler and expect to get 72 pixels an inch on their monitor. It&#039;s the intended size that matters, and it&#039;s always going to be relative to the device.
Of course we have smaller pixels on smaller devices. We expect the content to be rendered smaller there: a visual (imagined) &quot;inch&quot; on your iPhone is smaller so you can fit a reasonable page on the screen.
Of course we want higher resolution, even on larger devices. And yes, we&#039;ll have to adjust for that, but with your 128ppi monitor for example, you currently expect everything to be smaller as it is with all UI elements. Things like res-independent UI (Mac is edging closer to it) and browser page zoom (IE has it) will factor in to take care of this.
Practically speaking, though...
There&#039;s an internal discrepancy in CSS... when we say &quot;px&quot; we mean fundamentally different things whether we&#039;re addressing text or boxes. They behave differently, and this creates a problem when you need to have relative scaling between elements.
There&#039;s no unit in CSS that behaves as I described above. Instead of adding and subtracting relative percentages from parent elements, it would sure be nice to have an absolute unit like &quot;px&quot;, but which also scales consistently with all page elements and text.
I suggested &quot;pt&quot; could fit the bill. Take this measurement to mean what you will, but to me its essential size on screen is the period in body copy text. Today, that practically means one pixel. It may change eventually, but at least it should be internally consistent unlike CSS&#039;s &quot;sometimes scalable&quot; px spec.
</description>
		<content:encoded><![CDATA[<p>@Matt Wilcox<br />
Not sure if we&#8217;re really on topic anymore, but it&#8217;s an interesting discussion anyway: I&#8217;m not arguing your points on the meaning of physical measurement units, but I don&#8217;t think you get what I mean to say&#8230; I didn&#8217;t mean that one should hold up a ruler and expect to get 72 pixels an inch on their monitor. It&#8217;s the intended size that matters, and it&#8217;s always going to be relative to the device.<br />
Of course we have smaller pixels on smaller devices. We expect the content to be rendered smaller there: a visual (imagined) &#8220;inch&#8221; on your iPhone is smaller so you can fit a reasonable page on the screen.<br />
Of course we want higher resolution, even on larger devices. And yes, we&#8217;ll have to adjust for that, but with your 128ppi monitor for example, you currently expect everything to be smaller as it is with all UI elements. Things like res-independent UI (Mac is edging closer to it) and browser page zoom (IE has it) will factor in to take care of this.<br />
Practically speaking, though&#8230;<br />
There&#8217;s an internal discrepancy in CSS&#8230; when we say &#8220;px&#8221; we mean fundamentally different things whether we&#8217;re addressing text or boxes. They behave differently, and this creates a problem when you need to have relative scaling between elements.<br />
There&#8217;s no unit in CSS that behaves as I described above. Instead of adding and subtracting relative percentages from parent elements, it would sure be nice to have an absolute unit like &#8220;px&#8221;, but which also scales consistently with all page elements and text.<br />
I suggested &#8220;pt&#8221; could fit the bill. Take this measurement to mean what you will, but to me its essential size on screen is the period in body copy text. Today, that practically means one pixel. It may change eventually, but at least it should be internally consistent unlike CSS&#8217;s &#8220;sometimes scalable&#8221; px spec.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Matt Wilcox</title>
		<link>http://simplebits.com/notebook/2008/03/25/ie8-2/#comment-11324</link>
		<dc:creator>Matt Wilcox</dc:creator>
		<pubDate>Wed, 02 Apr 2008 12:52:34 +0000</pubDate>
		<guid isPermaLink="false">http://www.simplebits.com/wp/notebook/2008/03/25/ie8-2/#comment-11324</guid>
		<description>@Andrew Vit
&quot;monitor resolution is near enough to 72 points&quot; - say that to my laptop or my iPod. Not even close. Pixel density on screens varies massively, look at an iPhone for example. As such, this is exactly why the whole thread is revolving around &#039;pixel&#039; (physical) vs pixel &#039;virtual&#039; (as in the spec). The physical pixel is getting less and less reliable as monitor densities get higher and higher (a 15&quot; screen at 1920x1200 is at 128px/inch!).
Thinking of pt as mapping to an actual screen size just doesn&#039;t work. You may specify 12pt (.16 inch if my math is good, which it might not be) but it&#039;ll come out smaller on most screen these days.
So, even thinking of pt:px, it still wouldn&#039;t be consistent. What we need is a device that can report it&#039;s pixel density, calculate a virtual pixel that fits our expected 72dpi, and render to that auto-scaled. That&#039;s the only way we&#039;ll ever get px to map accurately to pt.
</description>
		<content:encoded><![CDATA[<p>@Andrew Vit<br />
&#8220;monitor resolution is near enough to 72 points&#8221; &#8211; say that to my laptop or my iPod. Not even close. Pixel density on screens varies massively, look at an iPhone for example. As such, this is exactly why the whole thread is revolving around &#8216;pixel&#8217; (physical) vs pixel &#8216;virtual&#8217; (as in the spec). The physical pixel is getting less and less reliable as monitor densities get higher and higher (a 15&#8243; screen at 1920&#215;1200 is at 128px/inch!).<br />
Thinking of pt as mapping to an actual screen size just doesn&#8217;t work. You may specify 12pt (.16 inch if my math is good, which it might not be) but it&#8217;ll come out smaller on most screen these days.<br />
So, even thinking of pt:px, it still wouldn&#8217;t be consistent. What we need is a device that can report it&#8217;s pixel density, calculate a virtual pixel that fits our expected 72dpi, and render to that auto-scaled. That&#8217;s the only way we&#8217;ll ever get px to map accurately to pt.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Kyle Bradshaw</title>
		<link>http://simplebits.com/notebook/2008/03/25/ie8-2/#comment-11323</link>
		<dc:creator>Kyle Bradshaw</dc:creator>
		<pubDate>Tue, 01 Apr 2008 14:53:43 +0000</pubDate>
		<guid isPermaLink="false">http://www.simplebits.com/wp/notebook/2008/03/25/ie8-2/#comment-11323</guid>
		<description>Time to grab the IE8 Beta - I haven&#039;t gotten the chance to look at it yet. Is this going to be another conditional comment or did they finally produce something I won&#039;t have to worry about ? (As much)
</description>
		<content:encoded><![CDATA[<p>Time to grab the IE8 Beta &#8211; I haven&#8217;t gotten the chance to look at it yet. Is this going to be another conditional comment or did they finally produce something I won&#8217;t have to worry about ? (As much)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dubai Web Design, Development</title>
		<link>http://simplebits.com/notebook/2008/03/25/ie8-2/#comment-11322</link>
		<dc:creator>Dubai Web Design, Development</dc:creator>
		<pubDate>Tue, 01 Apr 2008 05:56:47 +0000</pubDate>
		<guid isPermaLink="false">http://www.simplebits.com/wp/notebook/2008/03/25/ie8-2/#comment-11322</guid>
		<description>Excellent Information. We as web designing also facing same problem. Thanks for nice posting. I also Agreed to Maltax he is right.
</description>
		<content:encoded><![CDATA[<p>Excellent Information. We as web designing also facing same problem. Thanks for nice posting. I also Agreed to Maltax he is right.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Andrew Vit</title>
		<link>http://simplebits.com/notebook/2008/03/25/ie8-2/#comment-11321</link>
		<dc:creator>Andrew Vit</dc:creator>
		<pubDate>Sun, 30 Mar 2008 05:31:33 +0000</pubDate>
		<guid isPermaLink="false">http://www.simplebits.com/wp/notebook/2008/03/25/ie8-2/#comment-11321</guid>
		<description>@Matt Wilcox
Actually, a typographer&#039;s point is 72.27 to the inch. Thankfully, PostScript rounded it off... ;-)
Real-world points roughly translate to on-screen pixels because monitor resolution is near enough to 72 points. This could be a useful baseline if only it were standardized. *sigh*
In practice, the trouble of course is that OS&#039;s translate the size of a point differently. Mac has historically used 72ppi monitors, so it translates 1:1 by design. Windows considers monitor resolution as 96ppi, so a Windows point is actually 1.333 pixels.
What we actually lack in CSS (let me count the ways) is one single measurement system that&#039;s:
1. not affected by the containing element (so, scratch em, ex, %),
2. scalable equally for both type and element dimensions (so, scratch px),
3. and consistent between platforms.
If it weren&#039;t for that last item, &quot;pt&quot; could be a very useful unit, for both screen and print.
Because &quot;px&quot; is scalable for fonts but not for boxes, then it&#039;s meaningless as a unit of size. Why shouldn&#039;t it treat both the same? I&#039;m not an IE fan, but I actually prefer their interpretation of the spec: to keep the units internally consistent.
The rest should be up to the designer to use the units correctly, and if only pt:px were treated as 1:1 at &quot;normal&quot; size, across platforms, all this would be moot.
</description>
		<content:encoded><![CDATA[<p>@Matt Wilcox<br />
Actually, a typographer&#8217;s point is 72.27 to the inch. Thankfully, PostScript rounded it off&#8230; ;-)<br />
Real-world points roughly translate to on-screen pixels because monitor resolution is near enough to 72 points. This could be a useful baseline if only it were standardized. *sigh*<br />
In practice, the trouble of course is that OS&#8217;s translate the size of a point differently. Mac has historically used 72ppi monitors, so it translates 1:1 by design. Windows considers monitor resolution as 96ppi, so a Windows point is actually 1.333 pixels.<br />
What we actually lack in CSS (let me count the ways) is one single measurement system that&#8217;s:<br />
1. not affected by the containing element (so, scratch em, ex, %),<br />
2. scalable equally for both type and element dimensions (so, scratch px),<br />
3. and consistent between platforms.<br />
If it weren&#8217;t for that last item, &#8220;pt&#8221; could be a very useful unit, for both screen and print.<br />
Because &#8220;px&#8221; is scalable for fonts but not for boxes, then it&#8217;s meaningless as a unit of size. Why shouldn&#8217;t it treat both the same? I&#8217;m not an IE fan, but I actually prefer their interpretation of the spec: to keep the units internally consistent.<br />
The rest should be up to the designer to use the units correctly, and if only pt:px were treated as 1:1 at &#8220;normal&#8221; size, across platforms, all this would be moot.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Matt Wilcox</title>
		<link>http://simplebits.com/notebook/2008/03/25/ie8-2/#comment-11320</link>
		<dc:creator>Matt Wilcox</dc:creator>
		<pubDate>Sat, 29 Mar 2008 17:07:12 +0000</pubDate>
		<guid isPermaLink="false">http://www.simplebits.com/wp/notebook/2008/03/25/ie8-2/#comment-11320</guid>
		<description>@Andrew Vit
pt is a physical measure equivalent to 1/72 of an inch. It is for print, not screen.
</description>
		<content:encoded><![CDATA[<p>@Andrew Vit<br />
pt is a physical measure equivalent to 1/72 of an inch. It is for print, not screen.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: shopping cart</title>
		<link>http://simplebits.com/notebook/2008/03/25/ie8-2/#comment-11319</link>
		<dc:creator>shopping cart</dc:creator>
		<pubDate>Sat, 29 Mar 2008 13:04:06 +0000</pubDate>
		<guid isPermaLink="false">http://www.simplebits.com/wp/notebook/2008/03/25/ie8-2/#comment-11319</guid>
		<description>Agreed to Maltax. He is right.
</description>
		<content:encoded><![CDATA[<p>Agreed to Maltax. He is right.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

