RE: [css3-regions] Comments on content-node-layers-003 , regions-modal-dialog-002 , regions-selection-007 , extract-list-items-012 , etc..

Thanks Mihai for the clarifications and fixes.
 
 

> >- Test 10 [regions-modal-dialog-002]:
> >[...]
> First a clarification: the reason why there are tests for regions & HTML
> <dialog> is the fact that the HTML <dialog> also implies some things
> regarding rendering and formatting - the kind of things usually covered by
> CSS (only).
> 
> And while indeed this might not be the best way/place to test these
> things, I couldn't find a better alternative. Do you have any suggestion?
> 
HTML Elements should be explainable by CSS, if possible. 
 
If they are not, their interaction with CSS features looks kinda undefined to me.
 
If the interaction between those elements and CSS features has to be defined/tested, that can be done on both sides (HTML or CSS) and I think it may make sense to do it in whichever spec is the least advanced (to make sure the most advanced spec does not have to wait the other spec).
 
That being said, it seems the tests also pass on browsers that do not support <dialog> so that may not be that of an issue.
 
 
 


> >- Test 20+ [regions-selection-007]:
> >
> >I understand why testing selection is interesting from an implementer
> >point of view but those tests seems really hard to pass from my point of
> >view and I don't see what value they bring to the user. Aren't we making
> >the selection behavior unguessable for the user to serve the sole
> >purpose of pretending the css regions spec doesn't affect the DOM at
> >all?
> >
> >I'm not arguing for a spec change nor the removal of the tests, but I
> >remain dubious about their value.
> 
> Basically, you're right :) We're still trying to figure out what would be
> the proper way & place to test selection in the context of CSS Regions.
> Again, suggestions are welcome.
 
We may have to wait until multiple selections are supported to improve the situation on that front. We could maybe handle them by returning multiple ranges, and return for compatibility purposes a single range, that is hosted in a DocumentFragment and really represent a "symbolic link" of the selected content (aka a virtual dom where elements are proxy to the real ones, but whose navigational properties (nextSibling...) are altered to make it look like we navigate in a continuous DOM).