W3C home > Mailing lists > Public > www-style@w3.org > August 2013

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

From: Mike Sherov <mike.sherov@gmail.com>
Date: Mon, 12 Aug 2013 13:58:27 -0400
Message-ID: <CAD1Dv_LdZYMqQVOHupGW4xK0B6-rD8vcCFuL-rtaHXxWpwq1Vg@mail.gmail.com>
To: Simon Pieters <simonp@opera.com>
Cc: fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>
On Mon, Aug 12, 2013 at 4:35 AM, Simon Pieters <simonp@opera.com> wrote:

> On Sat, 10 Aug 2013 17:01:10 +0200, Mike Sherov <mike.sherov@gmail.com>
> wrote:
>  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/<http://dev.w3.org/csswg/css-display/>
>> This is awesome! What can I do to help move this draft along and get
>> it implemented.
>  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.
> So we added defaultStyle to CSSOM because of the above-mentioned iframe
> hack in jQuery.
> http://lists.w3.org/Archives/**Public/www-style/2013Apr/0568.**html<http://lists.w3.org/Archives/Public/www-style/2013Apr/0568.html>
> If toggling 'display' is the only use case, and 'box:none' addresses that
> use case better than .defaultStyle, should we drop .defaultStyle from CSSOM?

I was surprised that "default value" wasn't already documented somewhere (I
thought it was), and I think it should be a documented value type, and I
love .defaultStyle, .initialStyle, .*style because I think it provides
appropriately low-level access. That's just me though :-).

If I had my way, I'd keep both: box:none AND .defaultStyle.

> --
> Simon Pieters
> Opera Software

Mike Sherov
Chief Technologist
SNAP Interactive, Inc. | Ticker: STVI
http://snap-interactive.com | http://ayi.com
Received on Monday, 12 August 2013 17:59:15 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:30 UTC