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

Re: [css-display]? Compositing, expensive things, and laziness

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 21 Jun 2013 09:25:45 -0700
Message-ID: <CAAWBYDBt4RBqCgp76aGpWvMAxwM9QMK+GyjA=QSQ07yqWURQ=g@mail.gmail.com>
To: Ali Juma <ajuma@chromium.org>
Cc: "Robert O'Callahan" <robert@ocallahan.org>, www-style list <www-style@w3.org>
On Fri, Jun 21, 2013 at 8:40 AM, Ali Juma <ajuma@chromium.org> wrote:
> On Thu, Jun 20, 2013 at 10:44 PM, Robert O'Callahan <robert@ocallahan.org>
> wrote:
>> Mandatory bikeshed: "display-optionality" is a horrible name :-)
> I agree that it's somewhat awkward-sounding; suggestions for better names
> welcome :-)

Strongly agreed.

>> I would prefer an approach that can't lead to content breaking in the
>> absence of support for this property. Content waiting for the
>> optionalElementRendered event could break. Can this be fixed?
> Thanks for bringing this up, that's a great point. One way to accomplish
> this is to make optional elements start in the rendered state rather than in
> the non-rendered state. Then, implementations that support the property (and
> decide that they would like a particular optional element to be in the
> non-rendered state) can choose to immediately fire an
> optionalElementNonRendered event, giving content the opportunity to set up
> placeholder content. This way, content would only wait for the
> optionalElementRendered event if it got an optionalElementNonRendered event
> in the first place. Importantly, content could not assume that it would get
> an optionalElementNonRendered event, since implementations that support the
> property might still choose to leave the optional element in the rendered
> state (say if the implementation is running on a powerful high-end device
> where optionality doesn't provide a benefit).

Yeah, that sounds pretty good.

Received on Friday, 21 June 2013 16:26:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:31 UTC