Re: [css-values-4] inherit(<integer>)

On Jul 10, 2013, at 06:33, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Tue, Jul 9, 2013 at 5:34 PM, Lea Verou <lea@w3.org> wrote:
> I understand your use-cases, but I'm afraid of this exact solution.  I
> believe it will encourage brittle practices, where adding an extra
> wrapper into your html will break a lot of styling that was depending
> on inheriting from something exactly N levels up.  I think we can
> probably address your use-cases in a more targetted manner.
Doesn’t that apply to the inherit keyword as well, in a more limited fashion?

> This sounds quite useful, but could be addressed in a more limited
> manner, such as by adding an additional keyword that means "inherit
> from the parent element" on pseudo-elements, and just "inherit" on
> normal elements.
The benefit of this is that inherit is already known, so inherit() is easier to understand as an extension to it. A completely new keyword is more cognitive overhead for authors and I'm not sure this use case alone merits it.

> Can you expand on this?  I'm not sure what you mean here.  I think
> perhaps you're saying that the outside world doesn't know the
> component exists (and so can't set variables for it), but the inside
> wants to use values inherited into the component
Yes, precisely. 

> (but which might be
> blocked by some wrapper inside the component)?
Keep in mind that unlike inherit, this is also very useful for inherited properties as well, so the exact level might not even matter, as long as you can override a certain ancestor. 

> If this is the case, I think this can be addressed more directly by
> allowing custom properties to be set to the inherited values of other
> properties.  This has been requested for some time, and I plan to
> explore something like it in Variables 2.
That would be amazing indeed and I proposed something similar a while ago IIRC (not with variables). But what about cyclical references?

> Hm, interesting.  Why would you be putting something visible inside of
> something doing a11y-text-hiding?
You might want to show an icon or a pseudo-element or an abbreviation instead of the full text.

> If this is legit, I think it would actually be clearer to address it
> in an inverted manner - put something on the parent that says that you
> ignore its value for inheritance, and instead propagate its parent's
> value.  That way *anything* below it gets the grandparent value.
I’m not sure I follow, some example syntax would help.

> Nope, this doesn't work, and is a good example of why I think this
> particular idea is too fragile.  ^_^  You're assuming that the <ul>s
> are directly nested inside of each other with parent-child
> relationships, but that's not *ever* true for valid HTML - there's
> always *at least* an <li> between one <ul> and the next, and sometimes
> more.  Even if you changed it to inherit(7), it would fail as soon as
> you did something like wrap a <div> around one of the inner <ul>s.
Yes, yes, I realized this immediately after I sent my original email :( but for some reason, it looks like it was posted after your email. Odd.

> Finally, this definitely doesn't work for other toggle() use-cases,
> like the italic/normal switching.  In general, this is just not
> actually useful for replacing toggle() in any but the most constrained
> cases.
Yes, in the way I proposed it that’s true. I also thought of Barry’s idea (inheritance from the closest ancestor that matches a certain compound selector) but it intuitively sounds difficult to implement. If it isn’t though, that would be perfect and it would address several toggle() use cases.

Received on Wednesday, 10 July 2013 10:07:26 UTC