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

Re: [cssom][css-display][css-cascade] revisiting "default display"

From: Mike Sherov <mike.sherov@gmail.com>
Date: Fri, 6 Sep 2013 19:41:00 -0400
Message-ID: <CAD1Dv_LkdTLOWFte7sByskRYcG4+QZJQkbgi_XrQT4LkvZJLvQ@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: "www-style@w3.org" <www-style@w3.org>
On Fri, Sep 6, 2013 at 3:08 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Fri, Sep 6, 2013 at 2:36 AM, Mike Sherov <mike.sherov@gmail.com> wrote:
> > 2. A bit more insidiously, a javascript library wants to "show" a div
> that
> > is already "hidden" through an element selector in the author style
> sheet:
> > div {display:none;}. Can Display Level 3 address this? The current spec
> > says:
> >
> > The computed value of box is the specified value, unlessdisplay-outside
> has
> > the value none, in which case the computed value of box is none as well.
> >
> > I believe this prevents a JS library like jQuery from overcoming authors
> who
> > use element selectors to define display:none. This may not seem like a
> big
> > use case, but happens often enough. We're left with the situation where
> > Display 3 still needs a mechanism by which an element can be reverted to
> its
> > "default display". Now, we can add a value to display-outside like
> default
> > that accomplishes this, but now its starting to sound very familiar to
> the
> > generic "default" keyword that was just dropped from cascade level 3.
> >
> > To be clear, currently a javascript library must append an iframe to the
> > page to get at the "default value" of display for the div. CSSOM had at
> one
> > point defined an interface created by dbaron called
> > getDefaultComputedStyle() to essentially emulate the iframe hack. In
> > conjunction, Cascading 3 at one point had a "default value" to define
> what
> > value gDCS returns.
> >
> > I know I raised this issue and subsequently acquiesced when Cascading
> Level
> > 3 was still LC, but I find myself still needing a solution to this
> problem
> > not yet covered by any spec.
> *Nothing* can address this problem.

Why doesn't my proposed solution address the problem?

> Getting the initial value *kinda*
> helps *today*,

I'm not talking about "initial value",

> because most people still use either display:block or
> display:inline for everything, but that's it.  As flexbox and grid
> become more popular, elements will commonly be intended to use those
> displays, and then the "default value" is worthless.

I don't think so. I'm talking about "default value" which is different than
"intended" value. I'm not sure why you think any author would expect
calling .show() on a hidden div to result in grid or flexbox? Authors
expect calling .show() on a div results in display:block. I know because
they reported bugs on this when it doesn't do this right.

> I'm curious why jQuery uses an iframe hack.

So we don't have to keep a large list of elements. It's smaller, code wise,
to do the hack and is future proof as you mention.

> Is it just to be
> future-proof?  Just keeping around an array of default-block element
> names should be sufficient if you're not trying to be robust against
> future element additions (and if it's exposed, authors can just add to
> it in that case until jQuery updates).

Requiring developers to have to add their element to a large array? It's
easier for them to fix the "div {display:none;}" declaration than to have
to manipulate an array (which presupposes they are serving their own copy
of jQuery). It's also easier for them to just do .css('display', 'block').
But your suggestion presupposes they are aware of the issue. I'm trying to
make it something that devs don't ever have to even think about. jQuery
already provides them a solution so they don't have to think about this
problem. I'm just asking for the spec to provide this functionality in a
declared API.

> The only way to actually let an element be hidden by default and then
> show with the correct display type is for authors to use "box: none;"
> in the first place, rather than "display:none".

I agree. Unfortunately, I'm a library developer, not an end author. I'm not
saying we shouldn't have box:none either, though. I agree we need it as
well, specifically for the use case of .hide(). It allows the library to
just apply "box:none;" and remove it on .show().

> "display:none" is
> just a pernicious legacy mistake.

Calling "display:none" "legacy" is about 5-10 years too early.
window.getDefaultComputedStyle() is a backwards compatible solution that
works today in Firefox and doesn't require any intervention from the author.

> So I still don't think it's worthwhile to add back default values.  It
> simply doesn't help this use-case sufficiently to be worthwhile imo.

But it does. I believe I've shown how it does, and how it sufficiently
addresses the problem. You haven't shown me how it doesn't solve the
problem, except mentioning that some people may expect a default to flexbox
or grid. I don't believe that's a good counterargument, but perhaps I've
missed something.

BTW, if you need another use case for this, it also solves the problem for
when someone tries to accidentally call .show() on an element that has
default "display:none", like a <input type=hidden>. You may think that's
non-sensical, but all an author has to do is $('form').children().show(),
and you're accidentally showing hidden inputs.

> ~TJ

Mike Sherov
Chief Technologist
SNAP Interactive, Inc. | Ticker: STVI
http://snap-interactive.com | http://ayi.com
Received on Friday, 6 September 2013 23:41:48 UTC

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