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

On Wed, Jul 10, 2013 at 3:07 AM, Lea Verou <lea@w3.org> wrote:
> 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?

Yes, in a much more limited fashion.  Relying on just the level
directly above you is much more reliable than relying on something N
levels above you.  It can still produce brittle code, but not as
badly, and "inherit" isn't used too much anyway.

>> 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.

I was thinking of something close to "inherit", like "inherit-element".

>> 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?

No danger there, because you're only pulling in *inherited* values,
from the level above you.

>> 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.

Right, but wouldn't you just do that by just wrapping the hidden text
in a <span> that applies the hiding styles?

>> 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.

Ignoring the terrible naming, something like "color: blue
!pass-inheritance-through;".  If the parent was set to color:red, and
the child received its value from inheritance, it would get red rather
than blue.

>> 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.

Nope, inheritance from an ancestor with a particular selector doesn't
address toggle() well either.  It's somewhat less fragile for the <ul>
list-style case, though there are still several problems: it doesn't
deal well with any other elements that apply the same basic bulleted
list-styles and might be inserted partway down in the chain; and it's
easy to forget that you actually want to inherit from the <li>, not
the <ul>.  For more general cases like the italics toggle, though,
it's completely worthless.

~TJ

Received on Wednesday, 10 July 2013 17:14:29 UTC