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

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

From: Ali Juma <ajuma@chromium.org>
Date: Fri, 21 Jun 2013 11:40:18 -0400
Message-ID: <CANLC6v3Cp2MsJ1VZ4UyZSXRB6Vr9DULgOn3UxCCJoSx6S7O4OQ@mail.gmail.com>
To: "Robert O'Callahan" <robert@ocallahan.org>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, www-style list <www-style@w3.org>
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 :-)


> 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).

-Ali
Received on Friday, 21 June 2013 15:40:49 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:12 UTC