Re: CSS priorities

On Tue, Jan 21, 2014 at 5:51 AM, Jens O. Meiert <jens@meiert.com> wrote:
>> The comparison there, to be fair is a little misleading.  CSS 1 was, well,
>> not very much - CSS 2 happened REALLY fast. […] I agree with
>> the basic sentiment but let's be sure to keep that part in perspective too.
>
> Fair point, though I think it’s also important to note that complexity
> doesn’t grow linearly here, but exponentially. CSS is not “six times”
> more complex now than ten years ago (despite six times as many
> properties), but, who knows, twenty, or fifty times?

You're right that complexity doesn't grow linearly with added
properties, but neither does it grow exponentially.  Much of CSS is
non-interacting.  For example, I've never had to mess around with
advanced font features, and so haven't used anything from Fonts that
wasn't already present in CSS 2.1.  That entire set of features, while
complex, is also well-segregated from the rest of the language, and
easily ignored as long as you never need it.

The same can be said of many other feature sets.  I don't expect to
need to deal with Writing Modes, or most of the things in Text.

> I think that already led us into a downward spiral. To compensate for
> CSS complexity we appear to add even more to it. “Make this easier,
> and that.”

I've countered this assertion of yours before.  I suppose it depends
on precisely how you're defining complexity.  As I've argued before,
the addition of Grid and Flexbox technically make layout more complex,
as they provide more options, but they also make layout *much
simpler*, because they replace a bunch of complex hacky workarounds
using the previously-existing features.  Give with one hand, take with
the other, and hope the balance ends up positive for the average
author.  I think we're getting this right so far.

Similarly, a simplistic notion of complexity as "number of properties"
would count turning a complex property into a shorthand as a
complexity increase, when it often makes things simpler for authors.
There's technically more knobs to twiddle, but each one is simpler and
better-separated.

Importantly, one of the things you particularly decry is "turning CSS
into a programming language", with Variables as an example.  On the
other hand, Variables/Custom Properties are designed to be the
beachhead for enabling *greater hackability of CSS*, which allows
authors vastly increased ability to extend CSS on their own when they
run into new problems, rather than always requiring us, the CSSWG, to
solve the problems for them.  We *should* have CSS libraries that make
complex things simple.  Preprocessors accomplish this to an extent,
but they can only do so much as server-side compilers.  Custom
Properties allow new abilities impossible to reproduce in a
preprocessor, and the same is true of many other new extension points
I'm trying to add to CSS.  A language without these "generative"
abilities is doomed to always grow, and always grow *too slowly*.

> Apart from that, I do think we need to take concrete steps against
> spec fragmentation. I know Tab and others are *aware* of this, but we
> keep on bumping into it. It might help with feature creep too—what we
> are starting to see is redundancy that *may* just come from
> uncertainty who is doing something where. But I’m beginning to guess
> now.

Nope, if you see a property defined in multiple places (actually
getting multiple definitions, not just extensions), it's usually
because one of the definitions is obsolete.  We're aware of them, but
often forget to come back around and indicate this, partially because
we're in the thick of things and already know which definition to look
at.

One interesting example of this going on right now is the definition
of justify-content and friends, which is defined both in Flexbox and
in Alignment.  Alignment is the preferred home of the property, but
that spec isn't quite ready to be relied on yet (we're working on
it!).  After it's done, I intend to update Flexbox to just point over
at Alignment (and keep the examples), rather than define those
properties itself.

~TJ

Received on Wednesday, 22 January 2014 01:54:12 UTC