- From: Ian Hickson <ian@hixie.ch>
- Date: Mon, 12 Jul 2004 19:53:21 +0000 (UTC)
- To: Staffan Måhlén <staffan.mahlen@comhem.se>
- Cc: www-style@w3.org
On Fri, 9 Jul 2004, [ISO-8859-1] Staffan Måhlén wrote: > > 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. I agree. But it's beter than the alternatives. > In addition, percentage values of the 'left'/'right' values depend on the > containing block width, and this definition will create unintuitive results. On the 'width' property, too. They all get clamped to 0. (We will be updating the spec to clarify this.) > 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? The note is just clarifying that what IE6 does is wrong. It doesn't mean that it is different for inline elements per se. > Perhaps that distinction should be left to the UAs. Then we would get non-interoperable behaviour. That's the opposite of the point of a spec. :-) > 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? For example, overlapping a word with another, or attaching an icon at the end of a span. > 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. This happens already for blocks anyway (e.g. bottom:0 on a descendent of a containing block element whose height is 'auto'.) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 12 July 2004 16:06:36 UTC