- From: Ali Juma <ajuma@chromium.org>
- Date: Fri, 21 Jun 2013 11:40:18 -0400
- To: "Robert O'Callahan" <robert@ocallahan.org>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, www-style list <www-style@w3.org>
Received on Friday, 21 June 2013 15:40:49 UTC
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