Re: [css-lists] feedback

2015-05-15 21:54 GMT+02:00 Tab Atkins Jr. <jackalmage@gmail.com>:

> On Wed, May 13, 2015 at 1:41 AM, Philippe Verdy <verdy_p@wanadoo.fr>
> wrote:
> > The suggested default stylesheet for defining the padding gutter needed
> to
> > display ordered or unnumbered list is currently this:
> >
> > ol:dir(ltr), ul:dir(ltr) {
> >     padding-left: 40px;
> >   }
> > ol:dir(rtl), ul:dir(rtl) {
> >     padding-right: 40px;
> > }
> >
> > This is really bad as it uses a static size that does not work with all
> font
> > sizes (this value is only valid if the document's default font size is
> about
> > 13 pixels, producing a correct "3em" padding. But it will break
> immediately
> > when numbered lists are displayed with much larger fonts (this padding
> will
> > be insufficient, the marker will be partly truncated (on the left-side if
> > the resolved direction of the ul or ol element is LTR) or not displayed
> at
> > all, even if its size (for example a bullet) is a standard character
> > inheriting the current font size of <ul> and <ol> lists.
>
> I agree that it's bad, but it matches what browsers actually do.  This
> has been stable for such a long time that changing it would almost
> certainly break pages.
>
> > Why not definining these default padding values to "3em" ? (letting
> authors
> > increasing it if they need markers not reduced to a single static
> character
> > such as a bullet, for example in numbered lists where "3em" could be
> > insufficient to display "123." in a long numbered list).
>
> If we were to change it, we would make it 2.5em, as the common default
> text size is 16px, and 2.5*16=40.
>

Most pages don't use 16px, but only 13px for their default font size (so 40
px is already 3em). It has the advantages that when using <big> or similar,
the bullets or numbers of list items will not be truncated or invisible (in
my opinion this is a defect of HTML if it still maintains that a static
size of 40px has to be used).

Page designers already know that this 40px size is extremely bad, so they
redefine it immediately in their base stylesheet, most frequently like this

  ol, ul { padding-left: 3em; }

or if they care about multilingual contents with bidirectional texts or
some pages fully in RTL languages:

  ol:dir(ltr), ul:dir(ltr) { padding-left: 3em; }
  ol:dir(rtl), ul:dir(rtl) { padding-right: 3em; }

(Here again, the default size of 16px is almost never used, it is too large
(with the CSS logical pixels at 96dpi), notably on small displays like
smartphones (where the logical CSS pixels at 96 dpi are in fact using
higher resolutions at 1.5dppx, or even higher).

When users don't like the 13px sizes (too small for them), they use the
browser's "zoom in" function to increase the resolution in dppx (this does
not change the logical CSS resolution of 96dpi) to a much more variable
range (even on a Retina Hidpi display on iPhones, whose default resolution
is 2.0ddpx, but the effective physical resolution is in fact higher in more
recent models, they will also use zoomin so it is not uncommon to have
pages rendered at 6 or 10 ddpx, and looking very good even if font sizes
are set at 13px (CSS "logical" pixels at 96 dpi)

----

Note: These logical CSS "pixels" are also named "dips" in some papers that
prefer reserving the name "pixel" for the smallest physical unit of pixels
that can preserve the color gamut; the "physical pixels" may be covering
each other partly, for example on displays on LCD/TFT screen (with software
technics like Cleartype) where they are decomposed in 3 subpixels
(Cleartype assumes that subpixels are aligned horizontally or vertically,
and use only 3 subpixels, it offers some small adjustments when their
relative width are different depending on the color plane (for example the
red subpixels a bit larger than the blue one, which is also a bit larger
than the green one, or when the transfer functions for each color plane is
adjusted by the hardware to take into account a sight modification of the
subpixel geometry, compared to a simple grid with all cells the same size
and subpixels perfectly centered on each cell without any offset, but
Cleartype does not work when there are more hardware colorplanes requiring
very different color masks and color transfer functions) so that they can
overlap by 33% of their width; the same applies when printing for example
with the size of ink bubbles, that also overlap partly with distinct
centers for each color plane, or dynamically depending on the level of
details and the application of more or less complex color masks and pixel
geometries:

Below this limit of these "physical pixels", the color gamut is severelly
altered and cannot be preserved if they don't cover enough physical
chromatic subpixels. But CSS pixels ("dips") have nothing in common with
the physical pixels (CSS only allows controling the color gamut by
"rendering intent", by defining the stdanrd sRGB color gamut, but does not
control how this will be transformed by the display drivers or in internal
frame buffers used by the hardware display board, or by the physical
rendering medium (screen surface, paper+ink) or the hardware device
controler in order to offer the best approximation of the intended color
gamut.