- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Fri, 21 Jun 2013 09:25:45 -0700
- 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. ~TJ
Received on Friday, 21 June 2013 16:26:32 UTC