- From: Mike Sherov <mike.sherov@gmail.com>
- Date: Fri, 6 Sep 2013 19:41:00 -0400
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: "www-style@w3.org" <www-style@w3.org>
- Message-ID: <CAD1Dv_LkdTLOWFte7sByskRYcG4+QZJQkbgi_XrQT4LkvZJLvQ@mail.gmail.com>
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