Re: [css3-regions][css3-gcpm] Thoughts on Plan A and Plan B

On 2/15/12 8:15 AM, "Sylvain Galineau" <sylvaing@microsoft.com> wrote:

> While I understand the pushback against a solution that requires scripting to
> instantiate region elements, I find solutions that implicitly drop dynamic
> styling and event handling on the floor to be at least equally problematic. If
> a ŒCSS-centricı solution means I wonıt be able to attach events to regions to
> update their style on the fly as web authors routinely do across any regular
> app then I donıt think I want it either.  However they are created, DOM
> elements can be styled dynamically in response to events e.g. Œwhen the user
> double-taps this type of region, itıll grow and Iıll resize/reflow all those
> othersı, or Œwhen the user pinch zooms Iıll adjust the text sizeı (The
> Economist does the latter on the iPad, for instance), or ŒThese regions flow
> content from a bunch of sources; when the user taps one an icon bar appears
> with icons to favorite, tweet, saveŠı. Focusing on solving the static content
> layout scenario is natural but the solution shouldnıt drop interactivity on
> the floor or assume itıll be fixed later. Layout and interaction are not
> mutually exclusive on the web.
>  
> Auto-generation of anonymous blocks addressed through pseudo-elements is fine
> by me as long as there also is a proposal to allow everyone from authors to
> jQuery to attach events to these magic non-DOM things so that their style can
> be updated on the fly. This canıt be done with todayıs pseudo-elements.

I very strongly agree on this point. Any pagination solution should have a
way of addressing pages and auto-generated boxes via script. And outside of
pagination, if we end up extending pseudo-elements to allow for general
wrapper elements there should be a way of attaching events to those
wrappers. I've added a note to this effect on the additional pseudo-elements
wiki ideas page.

Thanks,

Alan

Received on Wednesday, 15 February 2012 16:45:30 UTC