Re: Proposal for limited :matches pseudoclass

On Sun, Jan 18, 2009 at 12:51 PM, David Woolley
<forums@david-woolley.me.uk> wrote:
> The problems are not in the language design.
It doesn't matter where the problems *are*. What matters is where the
problems can be best solved.
The problem of the example in my last e-mail (not sure if you have
seen it, so I'll add the example here) seems that it would be quite
well solved by CSS. Of course, if you can suggest a place where it can
be solved better, I'd be willing to give it a look.
The example itself was described as a use-case for an hipotetical
"full" (unrestricted) :matches():
form:matches( :invalid)::after {
   color: red;
   content: "Some fields are invalid. Please review your entries
before submiting.";
}
This is just a use-case; I may try to provide more cases if you wish.

> The problems that need to be solved are engineering and and end user usability ones.
I'm not sure what do you mean with that, or how does it relate to the
discussion. I'd appreciate it if you could clarify that statement.

> One needs to have a mechanism that is fast and minimises the need to backtrack or delay rendering,
Ok. Makes sense. But does such a mechanism exist? Can it ever exist? Let's see:
The problem (from the authoring perspective) would be "selecting
something based on its children". As long as it is possible to change
the "something"'s children, some degree of backtracking will be
needed: if the children changes, the selector needs to be re-checked
to see if it matches.
I'll have to admit, the last part of your sentence ("delay rendering")
has opened my eyes: now I see how this interacts horribly with any
kind of progressive rendering. So, now, we have an authoring need for
which any solution carries implementation issues. Then, IMHO, the only
reasonable approach is to find an optimal balance between solving as
many of the authoring needs as possible without sending implementators
into a nightmare.
Putting it simple: although I'm a programmer, I have no idea about
what a CSS engine's code looks like, so there are holes in my
knowledge I'd need to fill before I can suggest anything useful. It
was in order to fill in this holes that I posted the questions on my
previous message to this list. It seems quite clear that Tab's
original proposal (limited to the + and > combinators with a simple
selector) is easily affordable. What I was trying to figure out is how
much could these limitations be raised before it stops being
affordable enough. If you review my email, I hope you'll notice that
I'm not advocating for an unrestricted :matches() (at least not yet);
I am just asking about the issues it would imply, in the hope that
maybe I can figure out some way to fullfill the corresponding
authoring needs without stepping into such issues. That would be,
IMHO, a good point of balance.
If the answers show up that the original restrictions are the maximum
that can be achieved, then I'll shut up and accept the facts. OTOH, if
no answers are given, I can't help it but wonder if more expressive
power could be achieved for the same implementation costs.

> I appreciate that, nowadays, there is a significant lobby for the position
> that CSS should not protect authors against themselves,
Actually, I'm fine with some foolproofing; but I think
suicide-proofing is a pointless sacrifice: pointless because suicide
authors already have a lot of ways to suicide their pages, and a
sacrifice because it would require leaving out stuff that would be
useful for non-suicides. So I'll always advocate for a sane balance on
this aspect.

> but that doesn't change the fact that the lack of this feature is the result
> of factors other than language design.
I don't know what factors do you mean. Could you please clarify?

Greetings,
Eduard Pascual

Received on Sunday, 18 January 2009 22:04:28 UTC