Re: [css-cascade-3] Potentially missing definitions and use case for reincluding "default value"

Mike Sherov
Chief Technologist
SNAP Interactive, Inc. | Ticker: STVI
http://snap-interactive.com | http://ayi.com

On Aug 9, 2013, at 5:41 PM, fantasai <fantasai.lists@inkedblade.net> wrote:

> On 08/09/2013 06:43 AM, Mike Sherov wrote:
>> Apologies for coming in late on this discussion, and I'm not sure if this is covered in other specs, but there are a few
>> definitons that I know of that are not defined in the Working Draft:
>>
>> 1. default value: this is the cascaded value if only the UA stylesheet is considered. The classic example is "display: block"
>> for divs. This may not seem useful, but as a library contributor, jQuery sees authors who will specify a style sheet: "div {
>> display: none; }" and then want to "show()" the div. In order for jQuery to know the display value for "showing" the div is
>> "block", default value is needed (otherwise, jQuery adds an iframe to the page to and appends the div to the page in order to
>> determine that it should be "block").
>
> This situation is actually a bit more complicated than that.
> If the author has set the element to some other display type
> (such as 'flex' or 'inline-block'), then they want to revert
> to that value, not to the UA default style sheet.

Correct. Not that it matters much, but jQuery handles that case fine
already. We're only forced to do the iframe hack when the element has
display of "none".

>
> We're planning to solve this particular problem by splitting
> out 'display: none' into a separate property from the display
> type, so that you can toggle the "noneness" without affecting
> the type. See Tab's draft here:
>  http://dev.w3.org/csswg/css-display/

This is awesome! What can I do to help move this draft along and get
it implemented.

>
>> 2. resolved value: that which is returned by getComputedStyle and is defined in CSSOM currently, but might belong here as well?
>
> Yeah, it's probably worth mentioning this here, too, if only
> informatively.
>
>> Also, I'd like to make another(?) argument for the default keyword.
>>
>> 3. the "default" keyword: I know it was removed in favor of "unset". But if I understand correctly, "color:unset;" is
>> equivalent to following javascript "element.style.color = ' ';". At least selfishly, I would really really love to be able to
>> truly set the "default value" according to the definition I listed above.
>
> Not exactly. 'unset' removes all declarations at all levels of
> the cascade, so it's equivalent (for 'color') to 'inherit'.
>
> To set it to what it would have been if only the UA style sheet
> were present requires performing a cascade of just the UA style
> sheet on the element as well as its ancestors, and then performing
> inheritance. It's a fairly complicated feature. Worth contemplating,
> but, I think, not high enough priority at the moment to work on,
> given its complexity.

Yeah, I suppose at the moment I really only have a use case for
"default value" for "display". My concern here was only isn't that
we're special case fixing the display problem. It might be YAGNI, but
default value, while difficult, provides a general answer and low
level solution to that type of problem.

I suppose I can always raise it with this body should a separate issue arise.

Thanks again!

>
> ~fantasai
>

Received on Saturday, 10 August 2013 15:01:41 UTC