Re: [CSS21] Previous comments?

On 8 Jul 2004 at 14:35, Ian Hickson wrote:

> > Absolute positioning versus inlines
> > http://lists.w3.org/Archives/Public/www-style/2004Mar/0178.html
> 
> There isn't anything about a negative containing block that causes a
> problem as far as I can tell. The specification is implementable, and
> makes more sense in typical use cases than the implementations we looked
> at. (Typical use cases for this would only have one of 'left' or 'right'
> set, not both. When both are set, if the width is indeed negative, then
> one of the two will simply be ignored, since the content will be
> over-constrained.) Since there doesn't appear to be interoperability, it
> is up to UAs to fix their rendering to match the spec.
> 

Thanks for the reply.

Regarding negative containing block widths i find that concept unintuitive, 
and i think it fits poorly with the way 'width' cannot have a negative value.
In addition, percentage values of the 'left'/'right' values depend on the 
containing block width, and this definition will create unintuitive results.

When looking at that defintion now i also wonder whether they should have
been percentage versus 'width' + 'padding-left' + 'padding-right' (and
the equivalent for height) to allow:
<div style="position: relative; width: 50%; padding: 10px; background-color: #eee">
  Container
  <div style="position: absolute; left: 100%">&lt;-- Padding edge</div>
</div>
(At least two major browsers seem to deviate from the current wording, but 
correctly so in my opinion). 

I'm also wondering about the distinction:
"whose containing block is based on a block-level element," in the
notes. Is the idea that the margin/padding/border does not occur at
line-breaks and thus padding edge is not interesting for inlines? What about
single-line inlines if so? Perhaps that distinction should be left to the UAs.

The above might be minor details since the use cases seems uncommon, 
but suggests to me that there is a problem in the model. What are the use
cases you were referring to?


In addition to the above details, i think that you should consider
Boris comment about how this feature upsets the flow of a document.
To fully solve this feature i think an UA may need to traverse a document
tree as a sort of meta tree since the children of a node cannot be flowed
until the parents have been finalised, and this could (in theory) happen in a 
nested manner. Creating a specialised document processing model just to have
a particular (currently unsupported) way of calculating widths for elements
positioned versus inlines seems like a potential major issue to me. 

 /Staffan