W3C home > Mailing lists > Public > www-style@w3.org > July 2004

Re: [CSS21] Previous comments?

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
Message-ID: <Pine.LNX.4.58.0407121939170.32183@dhalsim.dreamhost.com>

On Fri, 9 Jul 2004, [ISO-8859-1] Staffan Mhln 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

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:14 UTC