Re: [css-hierarchies] Why require the & character?

02.09.2013, 23:38, "Tab Atkins Jr." <jackalmage@gmail.com>:
> On Mon, Sep 2, 2013 at 8:15 AM, Brad Kemper <brad.kemper@gmail.com> wrote:
>
>> šSlightly off topic:
>> šHierarchies has not received a lot of review yet, but my view so far is that writing "&" so many times makes it more likely that it will be accidentally left off. I can see why you'd want it when modifying the outer selector with a class, pseudo-class, attribute selector, etc., but why is it needed for embedded rules that could have continued the outer rule with a space character?
>
> Because the grammar is ambiguous without it - you can't tell apart
> some types of selectors from properties without arbitrary lookahead.
>
> That said, I'm not actually happy with what Hiearchies currently
> specifies, which is part of why I haven't been pushing on it lately.
> I think we either need to bite the bullet and do an @nest rule inside
> of the style rule which then contains plain selectors (with &
> optionally used to indicate the parent selector), or figure out a
> "good enough" parsing compromise that lets us tell selectors and
> properties apart within a small, bounded number of tokens at the
> parser level, at the cost of sometimes misinterpreting
> previously-valid CSS.
>
> Example of the problem: If you see "foo:bar baz qux ...", that could
> either be a property named "foo" with a value of "bar baz qux ...", or
> a selector starting with a type selector of "foo" and a pseudoclass of
> ":bar", plus more selectors following. šYou can't tell either way for
> sure until you hit a ";" or "}" character (it was a property) or a "{"
> character (it was a selector).
>
> ~TJ

Lookahead parsing is not a problem for preprocessors, but if this will be undesired for CSS itself, we could wrap nested rules in an _anonymous_ block, without a preceding at-rule:

    .lorem {
        color: #ccc;

        {
            /* Nested rules here */
            .ipsum {
                color: #000;
            }
        }
    }

This would probably be unambiguous enough for parsing while still saving web developers from repeating anything like `&` before _each_ nested rule.

Thanks.

Received on Monday, 2 September 2013 21:43:12 UTC