Re: [CSS21] ambiguity parsing 'list-style'

[to list]

On Fri, Dec 19, 2008 at 10:01 AM, L. David Baron <dbaron@dbaron.org> wrote:
>
> http://www.w3.org/TR/CSS21/generate.html#propdef-list-style defines
> the syntax of the 'list-style' shorthand property to be:
> #       [ <'list-style-type'> || <'list-style-position'> ||
> #       <'list-style-image'> ] | inherit
> Since two of the three properties accept the value 'none', this
> definition is ambiguous.  For example, it's not clear whether the
> shorthand declaration:
>  list-style: outside none;
> should be expanded into:
>  list-style-position: outside;
>  list-style-type: none;
>  /* implicit list-style-image: none, the initial value */
> or:
>  list-style-position: outside;
>  list-style-image: none;
>  /* implicit list-style-type: disc, the initial value */
>
> The spec tries to clarify this with the sentence:
>  # A value of 'none' for the 'list-style' property sets both
>  # 'list-style-type' and 'list-style-image' to 'none':
>  #
>  # ul { list-style: none }
>  #
>  # The result is that no list-item marker is displayed.
> but that doesn't make it clear whether this behavior of setting both
> to 'none' occurs only when there aren't values that are clearly one
> or the other, or whether any 'none' always applies to both
> properties and thus makes any values for either of the other cause
> the declaration to be rejected as an error.
>
> The spec should define exactly which values are accepted for the
> 'list-style' shorthand.
>
>
> Some possible ways to resolve this ambiguity:
>
> (1) Say that the value 'none' is not an allowed value of
>    'list-style-image' while parsing the 'list-style' shorthand
>    property.  This means that any value of 'none' is always a value
>    for 'list-style-type', which in turn means that we get the first
>    of the two expansions above (as expected), but also that
>    declarations like:
>      list-style: outside none disc;
>    become invalid CSS.
>
>    This is close to what WebKit does, except that WebKit accepts
>    two occurrences of 'none' in a value.  (It seems that it never
>    accepts 'none' along with another value of 'list-style-type',
>    though.)
>
> (2) Say that when 'none' appears in the value of 'list-style', a
>    single 'none' can set the value for both 'list-style-type' and
>    'list-style-position', but other values for either property are
>    always accepted.  (However, having another value for both would
>    have to be rejected, since that would imply a duplicate value
>    for one of them.  Probably two nones would be accepted.)
>
>    Since the default value of 'list-style-image' is 'none', this is
>    equivalent to saying that when a 'none' could be for either
>    'list-style-image' or 'list-style-type' given all the other
>    values present, it is preferentially allocated to
>    'list-style-type' rather than 'list-style-image'.
>
>    This is what Opera does.
>
> (3) Say that any occurrence of 'none' sets both 'list-style-type'
>    and 'list-style-image', and any other occurrence of a value for
>    either makes the declaration invalid.
>
>    This might be what the spec currently says, but it doesn't seem
>    to match any implementations that I could find.
>
> What Gecko does doesn't make much sense.
>
> (2) seems significantly harder to implement than (1) or (3).
>
> It's not clear to me which values need to be parsed for
> Web-compatibility.
>
> See testcase at:
> http://lists.w3.org/Archives/Public/www-archive/2008Dec/att-0028/list-style.html
> which I haven't yet gotten to work in WinIE7.

I don't like #3.  It forces me to write out my list-style declaration
in two lines when I legitimately want an image and no type.

As an author, I prefer #2.  Both values accept "none", so I should be
able to specify "none" on either while giving an explicit value for
the other.

I would accept #1, however.  It simply requires you to learn that if
you want an image of "none", just don't specify it in the shorthand.
Webkit's behavior seems inconsistent to me personally (I can only say
the image is "none" if I say the type is "none" as well?).

(Really, though, this just makes me wonder why list-style-image exists
at all, when it's truly just a special value for list-style-type -
type and image are mutually exclusive, after all.  It would be
unambiguous to have type accept a url, and this parsing issue wouldn't
arise at all.)

~TJ

Received on Sunday, 21 December 2008 04:07:38 UTC