- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 14 Apr 2004 17:42:24 +0000 (UTC)
- To: Boris Zbarsky <bzbarsky@MIT.EDU>
- Cc: www-style@w3.org
On Wed, 14 Apr 2004, Boris Zbarsky wrote:
>
> Perhaps I did a poor job of describing my issue with the "it's a
> replaced element or not" proposal... my problem is that it violates the
> principle of least surprise for authors. This is a problem that CSS
> suffers from heavily in general -- predicting the rendering of anything
> but the most trivial CSS is pretty much impossibly without studying the
> spec for weeks first.
>
> Again, I can't offer a better alternative. But I disagree with the
> assertion made by Ian earlier in this thread that this is a usability
> win. Anything that exhibits erratic (from an author's point of view)
> behavior is a usability loss.
We have four options:
A. the 'content' property always generates a box that is 'display:
inline-block'; 'display' cannot compute to anything else if 'content'
is set to anything but 'children'.
Pro: Consistent.
Con: Doesn't address a number of critical use cases (you can't make
generated content wrap).
B. the 'content' property never generates a replaced element.
Pro: Consistent.
Con: doesn't address a number of critical use cases (<img> can't be
described using generated content).
C. DWIM: when it looks like 'content' is being used for inline content,
render it inline (as for B), when it looks like 'content' is being
used for replaced content, do that (as for A).
Con: Inconsistent.
Pro: addresses all the use cases.
D. Do something that hasn't yet been suggested.
Since my requirement is to address all the use cases, A and B aren't
acceptable. I don't yet know of a D. That leaves C.
I'm happy to consider solutions that are simpler than C.
But without suggestions, there isn't much I can do.
--
Ian Hickson )\._.,--....,'``. fL
U+1047E /, _.. \ _\ ;`._ ,.
http://index.hixie.ch/ `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 14 April 2004 13:44:21 UTC