Re: [css3-values] Physical length units

None of which mitigates the fact that physical measures are wrong in CSS.

I know this isn't fixable whilst keeping backward compatibility. I
also think it's a pretty crazy position to be in.

Oh to be able to declare a version of CSS to author against. We'd be
able to fix these inconsistencies.



On 19 February 2012 15:54, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 2/19/12 9:30 AM, Matthew Wilcox wrote:
>>
>> The fact that cm etc don't result in those units is what is super
>> confusing. Why in the world would any author expect 1cm to *not* be
>> 1cm, and know to use 1trucm instead?
>
>
> They may not.  But they expect 12pt to be 16px, not actually 12pt.  They
> expect this because that's what every single word processor they used did
> and what most browsers did.

And how many people, in the wild, are using pt for screen CSS at the moment?
Serious question by the way. I'd have imagined very few (I've never
come across it).

>
> Furthermore, authors tend to code by copy and paste as well as
> guess-and-check.  This is good because it allows someone with minimal HTML
> or CSS knowledge to create web pages, but bad because it means that when
> someone writes "12pt" chances are they didn't _mean_ anything; they just
> wrote something that worked.
>
> OK, so your options are then as follows:
>
> 1)  Make 12pt actually be 1/6 of a physical inch.  This has been tried, and
> it breaks pages.

I imagine it does. But that's still the right thing to do. The problem
is CSS's inability to use specified versions. "fixing this breaks
current sites" is getting a pretty annoying thing to keep reading. So,
fix CSS to behave better? These things are only going to stack up the
longer we use CSS.

>
> 2)  Make 12pt actually be 16px but make other "physical" units not match pt.
>  So 1in would not be 72pt.  This also breaks some pages, actually, and is
> ... somewhat surprising to authors.  They get surprised when they write CSS
> and things don't match up, in particular.  There are variants of this where
> maybe you make 12pt be 16px and 1in be 72pt but leave 1cm as a physical cm,
> of course.
>
> 3)  Make 12pt be 16px and change all other physical units to match. This is
> also somewhat surprising, but only to someone who pulls out an actual ruler
> and measures.  As long as you don't do that, things are self-consistent.
>
> Note that all this was discussed to death; I'm just summarizing so you don't
> have to find it in the archives.
>
> In any case, the working group discussed this at length and settled on
> option 3.  All UAs now implement it interoperably.  Are you seriously
> suggesting changing things again?  If so, to which of #1 and #2?
>
>
>> If the vendor-prefix 'thing' has
>> taught us anything it is that the vast majority of authors do not read
>> specs - those people go on gut reaction and logical extrapolation.
>
>
> It's "gut reaction", "guess and check", "copy-paste", and "logical
> extrapolation", in that order.  The "logical extrapolation" part is pretty
> rare....
>
>> CSS units are broken, a deep understanding of technical considerations
>> should not be required in order to achieve a 1cm line when you've
>> specified a line to be 1cm.
>
>
> The vast majority of people using units are not trying to achieve 1cm lines.
>  They're trying to size boxes to match fonts and the like.  And they've been
> taught for literally decades that fonts are sized in pt. And they want to
> size their boxes in px.  And they _know_, again due to decades of
> experience, that 12pt == 16px.
>
>> Please can we re-focus on sane semantics and remember that the
>> internal implementation difficulties are our problem to fix?
>
>
> The issue here is deployed content and sane semantics, not internal issues
> of any sort.  See above.
>
> -Boris

Received on Sunday, 19 February 2012 17:03:59 UTC