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

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.

Thus neither solution is complete today imo; one gets full scriptability by virtue of using DOM elements but that in turn creates an awkward dependency on scripting to set up those elements. The other solution eliminates the script dependency by, well, eliminating scripting as if all we cared about was flipping back and forth through static content. If I were an author presented with these options I think it'd feel like sitting between two chairs. And I'm not sure I'd go for the elegant CSS-centric option at the moment...