Re: CSS Referencing

On Thu, Jan 5, 2012 at 4:32 AM, Matthew Wilcox <elvendil@gmail.com> wrote:
> There’s a very interesting and pleasing post over at perfplanet called
> CSS Selector Performance Has Changed! (
> http://calendar.perfplanet.com/2011/css-selector-performance-has-changed-for-the-better/
> ) . It shows how Webkit has been upgraded to have far better selector
> performance because an engineer shared the sentiment that “authors
> should not need to worry about optimizing …. , that should be the job
> of the engine”. (I agree).
>
> What I like even more though is one of the nitty gritty details: the
> Style Sharing optimisation. This allows the browser to figure out that
> one element in the style tree has the same styles as something it has
> already figured out. That’s smart.
>
> And it leads me to a question: Can we not expose the logic behind the
> Style Sharing for authors to leverage?
>
> I have been asking for years to get CSS able to reference a given
> elements properties to apply back to the current element. That seems
> to be more-or-less what Style Sharing is doing, but silently and
> behind the authors control.

Unfortunately, your premise is flawed.  The Style Sharing concept that
Nicole talks about in that article is an invisible optimization that
allows browsers to do less work when they can tell they've already
done the necessary work elsewhere.  Nicole doesn't go into much
detail, and I'm not familiar with exactly what Antti did there, but I
suspect it's just a matter of avoiding the matching and cascading
steps, so it can start directly from an already-done set of specified
styles.  This is different than what you're asking, and since it's
both invisible and under the browser's control, it's only done when
it's safe to do so.

This has nothing to do with an ability to base some styles on the
styles of another element.  It's a different subject, and is actually
a much more complicated thing, and is in many cases very unsafe (in
terms of creating inconsistent sets of constraints that don't have
good unique resolutions).

> Can we not use this as a basis to form
> something like this:
>
> div.thisdiv { height: (div.otherdiv); }
>
> This would be incredibly useful because it means that styling can at
> last become independent of the structure of the mark-up. It’s a way to
> escape the limitation of the cascade.

Those limitations exist for a reason, unfortunately.  They keep the
layout algorithm sane.  Currently, layout algorithms are tuned
carefully to be efficiently resolvable.  If authors have the ability
to add arbitrary constraints to layout, it will often lead to
situations that can't be resolved efficiently, and may require
iterative layout (running layout over and over again until a stable
solution is found).

In the worst case, the constraints may be contradictory.  CSS already
has this possibility in a few cases (for example: "height: 100px;
min-height: 200px; max-height: 50px;" has three different mutual
constraint violations), but we explicitly define how to resolve those
conflicts (in the previous case, the height is set to 200px).  If
authors had the ability to add arbitrary constraints, we have to
define a *generic* conflict resolution algorithm (these exist), which
will be much more complicated and in many cases probably impossible to
understand for anyone not intimately involved in it.

All of this is made more complicated by the fact that all throughout
CSS the CSS-defined constrains are assumed to be valid, so
author-defined constrains would by necessity have to be weaker, and
would probably conflict with CSS-defined constraints in lots of
situations where it's not obvious (see: basically anything involving
table layout).  Even worse, in some cases the actual constraints are
at least somewhat undefined (again, see table layout, particular
regarding row/colspans).


> Imagine this:
>
> div.thisdiv { height: (div.otherdiv); }
> div.otherdiv { height: (div.thisdiv); }
>
> Boom, equal height divs without the need to rely on mark-up structure.
> We could at last link visually related elements even though they are
> not structurally related.

This is actually an example of how constraint systems are difficult to
program against, because it does *not* do what you want.  ^_^  You're
probably imagining that it sets the two divs to be the height of
whichever one is larger.  What it *really* says is that the two divs
can be *any* height from 0 to infinity, as long as they're the same,
and doesn't tell us which value should actually be chosen.  This is an
equation with infinite solutions.

If you can do math against the referenced values, such as with calc(),
it's very easy to instead get into a situation where there are *zero*
solutions.  For example, imagine the declarations above were "height:
calc( (div.otherdiv) * 2 );" and "height: calc( (div.thisdiv) * 2 );".
 I think it's possible, by interacting with some of the CSS-defined
constraints, to get zero-solution cases even without doing math.

These sorts of situations are distressingly easy to get into when
dealing with constraint programming.  That's why we have layout models
- they're pre-built sets of useful constraints without conflicts or
vacuous sets like the above.  As Jon says, Grid Layout allows this
sort of height-matching for elements that are unrelated in the
document - just position them both in the same grid-row and specify
the height of the row to whichever of the auto values is reasonable.
This requires that they also be at the same vertical position in the
document, but I suspect that's a reasonable restriction.

(Also, I assure you that Grid is good times.  It's a successor to
Template Layout, which is the single thing that initially got me
interested in participating in CSS, just so I could do my part in
helping it to succeed.)

That said, Alex Russell from Google is very interested in still
pursuing something like this.  He has yet to convince me it can be
done sanely.  ^_^


> I’d also like to see:
>
> div { position: (h1); top: 10px; left: 10px; }
>
> To be able to position elements absolutely from a different elements
> location. Though, that may be much more of a stretch and outside of
> the scope of what the Webkit internals are doing.

This is a little bit saner, because abspos is a much simpler model.  I
even put together a proposal for exactly this on my blog
<http://www.xanthir.com/blog/b48H0>, though I've yet to convince Arron
(the editor of the Positioning draft) that its full power is
necessary.

~TJ

Received on Thursday, 5 January 2012 22:47:59 UTC