[thelist] A pixel is not a pixel

[Peter-Paul Koch]

> >Of course, if all browsers choose to go over to the real W3C standards in 
>every particular, the de-facto standard will change. If that is the case, 
>we'll all have to change our CSS tricks with it. But I won't do it before 
>this actually happens.
>
>I feel a little like Baron Xeno as I type this but....before all browsers 
>can choose to follow the W3C standards, some browsers must choose to do so. 
>And before some, one must choose. And that's where we are now, with Opera 
>choosing to follow the standard.

Although you're right that some browser must start following the standards, 
there are two distinct ways of implementing the standards:

1) Adding something new (like CSS2 or the W3C DOM) to your browser. This is 
fine (great, in fact) and it happens all the time.
2) Revising something already present in the browsers because the current 
implementation does not exactly follow the standards. This, I think, cannot 
be done and will not be done.

Browser vendors cannot afford to change the way how anything works once it 
has been implemented, because it would mean that web pages using the old 
definitions wouldn't work (properly) any more in the newest browser. Result: 
end users get annoyed and download another browser, which is bad for 
business. So in essence, now that px has been implemented in a certain way, 
it will never be changed any more.

This is the Principle of Browser Conservatism and it's a very poweful 
principle. Seen from this perspective, the Op5Mac treatment of px in CSS is, 
for all practical purposes, a bug.

>What happens next is open to speculation, but I'd be in favor of revising 
>the standard, personally. What I've been saying on this thread is that I 
>think Opera got the standard right, but that the standard was wrong to say 
>what it does.

Yes, I agree. What should happen is that W3C defines a new CSS unit which 
does what you've described. Once that is done, browsers can implement it as 
a *new* standard, which is no problem at all.

>I think you lost me there. The idea is that 10px type (and anything else 
>specified in pixels, for that matter) will render as if the monitor were 
>set to 90ppi. You can choose any resolution for your monitor you wish; the 
>larger the ppi you set, the more detailed will be the edges of the letters, 
>etc. But the letter will remain the same height. Example: a monitor which 
>delivers 180ppi will have 4x (2x high and 2x wide) as many pixels in a 10px 
>letter as a monitor at 90ppi.

So if you change your monitor resolution you do not change the number of 
pixels but the ppi? This will cause tons of confusion, but it does make a 
certain amount of sense (as long as the old pixel units remain visible 
somewhere in the controls, people expect them to be there.)

>Adjusting font size by overruling the style will still be supported. The 
>idea was simply to treat monitors and printers the same way, as the trend 
>is for monitors to soon have the resultion that printers have enjoyed for 
>years. Yes, it's complicated. Yes, there were other ways to do it, which 
>weren't as prone to confusion. But the W3C chose this one, so for the 
>moment we're stuck with it.

We can always choose to ignore this particular bit of the standard, and I 
think this will happen. Sometimes W3C delivers something unworkable, and 
this seems to be one of those cases.

Anyway, let them change the name and people will start to appreciate it, as 
you said.

>There's a lot to recommend the theory behind it; I just wish they'd used a 
>different name for it than "pixel," as that's where most of the heartburn 
>is coming from.
>
>Were I king (a statement sure to cause an instant insurrection) I would 
>have reserved "pixel" for an absolute hardware measurement, and insisted 
>that it treat printers exactly same way it treats monitors: 1 pixel = 1 dot 
>on the printer, and used point (or made up a new term, like the Frohicke, 
>to avoid confusion) as the measurement that scaled to compensate for the 
>resolution of the output device, whether monitor or printer, and any 
>browser that failed to do both would be classed as "non-compliant." As a 
>workaround for lying OS's, the current W3C recommendation of selecting the 
>default font base unit (96ppi/72ppi) would then be applied across the 
>board. I'd even suggest a variable user-controlled base unit: that way a 
>user could reduce/enlarge the entire page proportionally, as an 
>accesibility feature.

Unfortunately typography is not my main strength, so I cannot really answer 
to this, but I still have the feeling that the standard is trying to change 
the way we've always treated monitors. As I said before, adding something 
new is easy, but changing something that has been in use for years is much 
more difficult, if not impossible.

ppk

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.