CSS3 borders

I was just about to suggest a load of border properties to allow 
graphical borders when I actually found the CSS3 border module working 
draft. Any reason why isn't this linked to from the roadmap or the 
other modules that refer to it, e.g. box?

I think that the ability to use images or specify radiuses for corners 
and use repeating images on borders will be fantastically useful and 
this is the most exciting feature of CSS3 I've come across. Nice one!

I'd like to suggest the addition of a set of border-*-bevel properties. 
These properties would have exactly the same syntax as the proposed 
border-*-radius properties, but would cut the corner at an angle rather 
than rounding it.

The properties in full:

	border-top-right-bevel
	border-bottom-right-bevel
	border-bottom-left-bevel
	border-top-left-bevel
	border-bevel

I also wonder if it would make more sense to name the properties as 
below:

current					suggested

border-top-right-radius			border-topright-radius
border-bottom-right-radius		border-bottomright-radius
border-bottom-left-radius		border-bottomleft-radius
border-top-left-radius			border-topleft-radius

I suggest this because the dashes in property names usually imply 
hierarchy, but this is not quite the case here, 
border-bottom-right-radius has as much to do with the right hand border 
as it does with the bottom one. Minor point though.

Ben


On Monday, Apr 28, 2003, at 12:59 Europe/London, Coises wrote:

>
> [Sun, 27 Apr 2003 18:57:59 -0700 (PDT)] Ian Hickson:
>> So far, though, nobody has suggested any way of expressing the 
>> "simple"
>> constraints that Coises gave in his e-mail. The truth is that these 
>> are
>> actually incredibly complicated, both to specify and implement
>
> Indeed... which, in a way, is one of my points.  One of the things a 
> good
> computer language does is map what is elementary in "design space"
> to straightforward expressions in "language space."  The design and
> implementation of a language that does that may not be simple at all.
>
> Why are "object-oriented" languages (like C++, ECMAScript or Visual 
> Basic)
> an improvement on "structured programming" languages (like Algol or 
> PL/1)?
> They allow us to express the ideas behind our programs in terms that 
> are
> more akin to the ideas themselves.  They also tend to lead us to 
> formulate
> our ideas in more robust terms than do structured languages.
>
> Following, I'll try to make some preliminary stabs at how the problems
> I suggested might be made manageable by a web page formatting language.
> These are not well-researched, and doubtless contain many flaws...
> this is just a jumping-off point.
>
>
> || 1. If the centered title at the beginning of this page will fit on 
> one
> || line, it should be shown on one line; if it requires two lines, the 
> break
> || between lines should be such that the two parts are approximately 
> equal
> || in horizontal measure.
>
> There are two approaches to this, depending on the degree of control
> desired.
>
> The simple approach --- taking the problem statement literally --- 
> would
> be to have a rule such as:
>
>      H1 {!minimize: height, width}
>
> indicating that, after initially laying out the block, the width 
> should be
> minimized without changing the height, or any other CSS-2 properties 
> that
> are implicitly or explicitly specified.  (Height is minimized by the
> standard layout algorithm; it is mentioned explicitly since it would
> usually *not* be specified, either implicitly or explicitly --- "auto"
> really doesn't count as a specification in this sense, as it 
> effectively
> indicates the absence of a specification.  Great care would be needed
> to assure such details would result in behavior that is both consistent
> and useful.)
>
> In practice, the problem is likely to be more complex.  Usually there 
> are
> "good" and "bad" places to break a short sequence of words, like a 
> title
> or a heading --- as a page designer, I'd like to be able to specify 
> what
> sets of breaks are preferred.  For example, suppose I have this title:
>
>     The care and feeding of foo-bar and its place in a non-bar world
>
> to be placed at the top of a page.  I don't know if it will fit on one
> line.  I know I don't want to see this:
>
>     The care and feeding of foo-bar and its place in a
>                       non-bar world
>
> (which hopefully everyone can see is just plain ugly).  If I had to 
> have
> two lines, I'd probably want:
>
>      The care and feeding of foo-bar
>     and its place in a non-bar world
>
> but if I needed three lines, I'd probably want:
>
>        The care and feeding
>      of foo-bar and its place
>         in a non-bar world
>
> (and certainly not some travesty like:
>
>       The care and feeding of foo-
>      bar and its place in a non-bar
>                  world
>
> which, again, is just ugly).
>
> Now, were I working in a WYSIWYG medium, this would be easy: I'd just
> /look/ at the result and add "hard returns" if I didn't like it.  That
> won't work on the web, though: because what I see isn't what my viewers
> will see.  I have to step back a level and write my design logic --- 
> not
> my conclusions under a particular environment --- into the page.
>
> The answer to this problem, it seems to me, must be the ability to 
> specify
> different levels of "comfort" for line breaks.  I know that even when
> writing plain text prose like this, I frequently add hard returns just
> to avoid bad line breaks --- as in this text, in which my mail program
> would have separated "to" from "avoid": that would have made the 
> sentence
> subtly harder to read.  At present, we have only three options:
>      <BR> --- always break
>      &nbsp; --- never break
>      space --- optional break
>
> Suppose I could write something like this:
>
>      <H1>
>      The care and feeding
>      <*BR PRIO=2>
>      of foo-bar
>      <BR PRIO=1>
>      and its place
>      <*BR PRIO=2>
>      in a non-bar world
>      </H1>
>
> to say that I'd prefer no break; but if a break is needed, between
> "foo-bar" and "and" is the best place to put it; and if more than one
> break is needed, the "PRIO=2" places should be tried first?  That would
> let me express the same logic I'd use to format a WYSIWYG page in an
> environment where IDKWYWG ("I don't know what you will get").
>
> (Yes, I know that's not CSS.  I'm not convinced the answer to all 
> problems
> of web page design lies in CSS.  I do think it *must* lie in HTML+CSS 
> that
> degrades gracefully under older browsers, or else it's no answer at 
> all.
> The code above is meant to degrade to a forced break into two lines ---
> hoping that will cover most cases reasonably well under browsers that
> don't support the contemplated syntax.)
>
>
> || 2. The section headings on this page should be distinctly larger 
> than the
> || paragraph text that follows them, but visibly smaller than the main 
> page
> || heading.  They should all be the same size.  Within those 
> constraints, the
> || section heading size should be chosen so that as many of the 
> headings as
> || possible fit on a single line.
>
> Taking the statement of the problem literally, the last condition
> could be replaced by the statement that the font size should be
> as small as possible to satisfy the prior constraints (it doesn't say
> that's what's wanted, but it doesn't say it isn't, either):
>
> H2 {!range font-size: P.text:font-size++, H1:font-size--}
> H2 {!minimize: font-size}
>
> If we take the problem statement to mean that the section heading size
> should be (perceptually, not mathematically) about midway between
> the text size and the main page heading size, but yet should "give" a 
> bit
> to try to squeeze all the sections headings onto one line each, things
> definitely get more complicated.
>
> (I think I'll pass on that one for the moment... but I do think it
> represents a reasonable bit of design logic.)
>
>
> || 3. I have a graphic to be set left, with a couple paragraphs of 
> text set
> || to the right.  There is a caption for the graphic.  If the caption 
> will
> || fit at the right --- beneath the other text and not extending below 
> the
> || bottom of the graphic --- it should be set right and aligned with 
> the
> || bottom of the graphic; if it will not fit, it should be set /below/ 
> the
> || graphic.  In no case should it be to the right yet extend below the
> || graphic, nor should it wrap with some of the caption to the right 
> of the
> || graphic and some of the caption below it.
>
> There are several ideas I have to introduce here.  First is that it 
> would
> be helpful to be able to specify that some blocks should never be 
> wrapped
> around images, floats, etc.  This is not the same as "clear" --- it's 
> okay
> if they fit beside something else: they just should never be wrapped
> around something else.  They need to be in a solid rectangular block.
>
> I certainly could have missed it, but I don't think any CSS2 property
> or CSS3 module allows me to specify that.
>
> Alas, there is a second, trickier element to this problem: if the 
> caption
> is placed beneath the picture, it should be no wider than the picture; 
> but
> if it's placed to the right of the picture, it should use the available
> space (which could be more or less than the width of the picture).
>
> I can think of two ways to solve this... but I must say, I hope someone
> comes up with something better than either of them, because I really
> don't like either of my own ideas.
>
> One option would be to use a TABLE for the layout, but have a way
> to specify that an element in one <TD> could be moved to another <TD>
> under certain conditions.  For example:
>
> <TABLE>
>    <TR>
>       <TD><IMG ...></TD>
>       <TD>
>          <DIV>The main text beside the image.</DIV>
>          <DIV NOFITROW="move: #captionunder">The caption</DIV>
>       </TD>
>    </TR>
>    <TR><TD ID="captionunder"></TD><TD></TD></TR>
> </TABLE>
>
> to indicate that the row containing "The caption" cannot be enlarged to
> contain that element: if it's not already big enough, the caption must 
> be
> moved to become the first (in this case, only) element in the cell that
> has "captionunder" as its ID.
>
> The other solution would be a kind of conditional HTML:
>
> <IF COND="#caption:content-bottom <= #image.content-bottom">
>    <IMG ... ID="image" ALIGN=LEFT>
>    <DIV>The main text beside the image.</DIV>
>    <DIV ID="caption" VALIGN=BOTTOM>The caption</DIV>
> <!--ELSE
>    <TABLE>
>       <TR>
>          <TD><IMG ...></TD>
>          <TD>The main text beside the image.</DIV>
>       </TR>
>       <TR>
>          <TD>The caption</TD>
>          <TD></TD>
>       </TR>
>    </TABLE>
> ENDIF-->
>
> (Of course, VALIGN=BOTTOM doesn't work on DIV, but I trust we all see
> that's not the major issue here.  I hate both of these solutions.
> Something better is needed, but it's not to be found in my head just 
> now.)
>
>
> || 4. I have three classes of text to set on my web page:
> ||      a. Running Text in Paragraphs: this should be of a size that 
> is the
> ||         best compromise between being large enough that the user 
> can read
> ||         it easily, and small enough to keep from making the user 
> page down
> ||         more than necessary.
> ||      b. Section Titles: these should be clearly distinguishable 
> from the
> ||         running text, but not so large as to be jarring.  They 
> should be
> ||         convenient guides for the skimming reader to find the parts 
> of the
> ||         text that are most interesting.
> ||      c. Legal and Technical Notices: these should be as small and
> ||         unobtrusive as possible without being illegible.
> || What "font-size" should I specify for each class?
>
> The problem here is that no useful meanings are assigned to the 
> font-size
> keywords.  What the heck does "medium" mean (other than "larger than 
> small
> and smaller than large")?  If the user has a preferred size for running
> text (text in paragraphs that goes on at some length), I want to know 
> what
> to specify to get that size.  (And I want it to adjust to the font ---
> some fonts look huge at, say, 12pt, while script fonts may be barely
> legible at the same size.  The font-size-adjust property apparently 
> tries
> to get at that, but in practice I can't see how to use it.  Most 
> often, I
> care about the subjective appearance of text, not the actual metrics.  
> How
> do I say, "Show this in the user's preferred script font at a size that
> matches the surrounding text in appearance"?)
>
> What I'd like to see here is a set of font-size keywords that have
> normative meanings related to their use in page design.  For example:
>
>      running-text:  the user's preferred size for text in paragraphs
>                     (recommended where ease of reading should be 
> maximized
>                     balancing the size of text with the required space)
>
>      fine-print:    the smallest size in which the font remains legible
>                     (recommended for legal notices, etc., which are
>                     normally not read by anyone but need to be present)
>
>      small-text:    a size recognizably smaller than running-text but
>                     still easily legible (recommended for captions,
>                     quoted material, footnotes, etc.)
>
>      key-text:      the user's preferred size for text that should be
>                     maximally legible in short phrases, where space is 
> not
>                     generally a consideration (recommended for quotes 
> from
>                     a following paragraph, "teasers," section headings,
>                     etc.)
>
>      headline:      the largest font-size the user would generally 
> prefer
>                     to see (recommended for <H1> elements)
>
> If one needed <H1>-<H4> elements plus key quotes, a definition 
> something
> like this:
>
>      H1     {font-size: headline}
>      H2     {font-size: percept(2/3,key-text,headline)}
>      H3     {font-size: percept(1/3,key-text,headline)}
>      H4     {font-size: key-text; font-weight: bold}
>      P.quot {font-size: key-text; font-style: italic}
>      P.text {font-size: running-text}
>
> might do the trick.  (The "percept(m/n,x,y)" notation is meant to 
> indicate
> some way of saying "a value which has the perceptual effect of being 
> about
> m parts in n from x towards y.  The above distributes the font sizes 
> for
> the four heading types between the headline size and the key-text size 
> so
> as to appear to be an even gradation to the viewer.)
>
> The standard would /not/ define the numeric relationships between these
> sizes: it would be up to the user agent to support definition of these 
> by
> the user, and to supply reasonable defaults where the user has not made
> individual selections.  The values might be different for different 
> fonts.
> What the standard /would/ indicate is how they should normally be 
> used, so
> that users can set values for each and expect that properly-authored 
> pages
> will use the sizes they find most comfortable.
>
> (In practice it might be desirable to have a level of qualification
> that would let the author be sure that the H1 and H4 sizes chosen are
> far enough apart to make the intermediate levels distinguishable, and
> possibly to scale down the H2 and H3 sizes if the headline size is too
> much larger than the key-text size.  Once again, I'm going to pass
> on constructing an illustration of that at the moment.)
> -- 
> Randall Joseph Fellmy aka Randy@Coises.com
>
>

(q)	Ben Godfrey?
(a)	Web Developer and Designer
	See http://aftnn.org/ for details

Received on Monday, 28 April 2003 13:11:33 UTC