[css-lists] feedback

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.

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).

----

Also is there a way to have this padding computed according to the maximum
display width of all markers in the same list (the most direct ul or ol
parent element containing the list item for which markers will be
displayed), plus the marker relative position from the list-item border
box, plus an additional offset?

In that case, the default padding would be computed using the suggested
offset of 1.25em and the suggested relative position of the marker set also
to 1.25em (assuming that the marker's width is about 0.5em (for example
when it is just a bullet with usual builtin fonts used for default markers
like bullets, square, circle...), this also gives a total of 3em of total
padding in these fonts.

So we would write something like:

ol:dir(ltr), ul:dir(ltr) {
    padding-left: size( ::marker::position::computed-width(px) * 2
                        + max(foreach($(>li),
::counterbox::computed-width(px)),
                        px );
  }
ol:dir(rtl), ul:dir(rtl) {
    padding-right: size( ::marker::position::computed-width(px) * 2
                         + max(foreach($(>li),
::counterbox::computed-width(px)),
                         px );
}
(Such computing first requires computing all the counter values (for all
list items that have a visible box) by first resolving their counter id,
their internal numeric value, the counter styles (including converted
numbers in decimal, roman, alphabets, plus their static text such as
punctuation), in order to determine their string value, then resolve their
effective font in order to get their individual display width; if the
marker is an image, we just use the effective width of the image.

----

But because markers may be styled differently, their size could use
different measurement units, so we need to specify a conversion unit when
retrieving their width, so that the the list of widths will use the same
unit (otherwise max() would have no real meaning, unless it can process
size measurements in compatible and convertible units, in which case it
will convert all widths to the measurement unit of the first item in the
list to compute the maximum size; in such a a case the unit parameters (px)
may be dropped above, and we don't need a constructor such as "size(number,
px)" to convert a numeric value to a valid size type:

ol:dir(ltr), ul:dir(ltr) {
    padding-left: ( (::marker::position::computed-width) * 2
                    + max(foreach($(>li), ::counterbox::computed-width)
                  );
  }
ol:dir(rtl), ul:dir(rtl) {
    padding-right: ( (::marker::position::computed-width) * 2
                    + max(foreach($(>li), ::counterbox::computed-width)
                  );
  }}

Note that this syntax also assumes that basic arithmeric also works by
converting implicitly the size-type operands to the unit of the first
operand, and then return the computed value in that type. But browsers
could also convert all these to an internal measurement unit (such as
device-specific physical pixels) to avoid rounding problems in the
arithmetic above ("*2", and "+")

The syntax above also supposes that it is possible to perform DOM queries
by specifying CSS selectors with "$()" above, using a syntax similar to
jQuery, in order to enumerate "li" child elements of "ol" or "ul" elements.
The "$()" means actually the same in this example as querying direct
children of the currently styled element, with a filter (the filter here is
">li").

It also assumes that there's an API in CSS to query CSS properties of
DOM-selected elements (such as "::marker", "::computed-width"). This API
computing starts by expressions between parentheses here.