- From: Matthew Brealey <thelawnet@yahoo.com>
- Date: Fri, 03 Mar 2000 11:06:28 -0800
- To: www-style@w3.org
- Message-ID: <38C00D34.BCF@yahoo.com>
Tantek Çelik wrote: > Per the HR discussion in general, even though HR itself can be considered a > block for formatting purposes, the point of where the "rule" of the Horizontal > Rule element draws needs to act like an auto-sized contained glyph that > formats more like a horizontally stretched text character rather than a border > (as described by others). E.g. it *does not* draw or get sized under adjacent > floats - it draws in the area that text in a similarly placed box would flow > into. And it is sized (%) and aligned within that flow area as well. I would like to see how you could create HR using a glyph (answer: you can't). Imagine you have 600 pixels of horizontal space. This should result in a 600-pixel-wide horizontal rule with 2 pixels high of coloured line and zero pixels of transparent space. If you set size=10, if it were a glyph, the coloured line would increase in size, and yet it does not; and to make matters stranger, from zero pixels of transparent space we now have 9 (size - 1). This is a very strange glyph if you ask me. Now consider that there is width=5, and size=5. The rendering would be this. +---+ | | | | | | +---+ If we change that to width=600, if it were a glyph the border would increase 120-fold in width, as would the width of the white space, but in fact the border does not increase at all. (Or then again, perhaps it's a magic glyph.) > This behavior is both as implemented by current UAs, and what is more visually > desirable. > > It is an error to attempt to sacrifice the visually desirable rendering to a > set of rules that don't adequately describe it. > > Yes, we don't have what would be necessary in CSS to properly describe the > typical and desirable rendering of <HR>. Some additional concepts are > necessary. Or rather simply devise different float rules or properties to cope with the fact that the rendering is perfect outside of floats, and (IMO perfect with them as well) only problematic withfloats.
Received on Friday, 3 March 2000 06:04:05 UTC