Re: Positioned Layout proposal

On Mon, Oct 18, 2010 at 4:02 PM, Sylvain Galineau
<sylvaing@microsoft.com> wrote:
>> From: Tab Atkins Jr. [mailto:jackalmage@gmail.com]
>
>
>> Another would be placing annotations in the margins alongside some
>> text - google docs does this.
>
> That's definitely a use-case. The more, the better ! (To a reasonable
> extent, of course...)

Excellent.  ^_^  I'll try and find some more - I designed this mainly
from the 3 use-cases of tooltips, frozen table headers, and the
particular layout I wanted for the newsreader app.


> Any thought about what it means OM-wise ? Today top/left and bottom/right
> coordinates are relative to the same two origins for all elements and a
> fair amount of code can and does takes it for granted to achieve all kinds
> of effects. To take a simple example - not a use-case :) - if two abspos
> elements are siblings within the same containing block you can make one
> overlay the other by making their top/left properties match. With this
> proposal you would also need to make sure they refer to the same origin
> ...or take extra steps.
>
> So while the mechanics are straightforward and simple for the static stylesheet
> author, the extra level of indirection adds potential complexity for script
> developers given the current CSSOM API, especially those who build toolkits/libraries.

I haven't yet given any significant thought to the OM story here.  At
least in the naive case, where code expecting normal abspos is applied
to a page using normal abspos, it will work as expected, because the
'auto' root resolves properly to allow that.

Dealing with different-origin positioning is more interesting.
Parsing isn't hard unless element() or the *most() functions are used.
 Those would both be pretty easy with the Values API, though -
element() use would just return a DOM node I guess, while *most()
would return a function object using whatever API we have for that.

~TJ

Received on Monday, 18 October 2010 23:13:02 UTC