W3C home > Mailing lists > Public > www-style@w3.org > November 1999

Clip & shaped borders + error/ambiguity in spec

From: Matthew Brealey <thelawnet@yahoo.com>
Date: Mon, 1 Nov 1999 08:11:01 -0800 (PST)
Message-ID: <19991101161101.22713.rocketmail@web903.mail.yahoo.com>
To: www-style <www-style@w3.org>
There is definitely a need for more shapes. However,
rather than defining clip: hexagon/triangle or
whatever, it seems that the logical solution is to
define clip: polygon{Xa, Ya, Xb, Yb, Xc, Yc ...},
where Xa is the the distance to the right from the top
left padding edge of the element to point a and Ya is
the distance down from the top left padding edge.

This would define a polygon ABC (i.e., a polygon where
point A is connected by as straight line to B, B is
connected by a straight line to C and C back to A).

This syntax allows any polygon to be described.

It is clearly preferable from a author point of view
to  defining hundreds of shapes each of which would
probably not allow truly flexbility.

Its only drawback is potentially difficult
implementation.

There does not seem to be any alternative satisfactory
syntax.

Having dealt with polygons, it remains only to deal
with ovals.

It is clearly a simple enough matter to define it as
clip: oval(the same syntax as rect), which would draw
the largest non-rotated oval that can be circumscribed
within the rectangle described.

However, this fails to deal with rotated ovals.

Thus a rotation could be added to the oval syntax.

However, there are certain difficulties with this,
chiefly that a rotated oval could go outside the
clipping region, and although this is predictable, it
is stil unsatisfactory.

Instead, consider that any oval can be defined by the
coordinates of its four 'corners' (to see this, draw
an oval on a piece of paper), and thus if we specify
these, then every oval is uniquely describable.

Thus clip: oval(Xtop, Ytop, Xbottom, Ybottom, Xleft,
Yleft, Xright, Yright).

This is good, but it places certain demands on the
author relating to the fact that having described the
top and bottom 'corners', it is clear that the left
corner (equally, so must the right - i.e., the LR is
perpendicular to TB with a point of intersection at
the centre of the oval) must be equidistant from both
the top and bottom corners of the oval, otherwise the
oval is not uniquely described.

Therefore there are two options: firstly ignore
invalid ovals (the easiest option for UAs), secondly
specify that if the left and right corners (or the top
and bottom corners, depending on the spec) are not
equidistant from top and bottom, then they are fixed
so that they are (the obvious choice seems to be a
line of equal length, by necessity, perpendicular to
the line that we do accept).

The code below rejects invalid ovals:

[Where Xc is the X-coord of the centre, Xt of the top
'corner', Xb of the bottom, etc.)

Xc = .5(Xt + Xb);
Yc = .5(Yt + Yb);
If(sqrt((Xl-Xt)^2+(Yl-Yt)^2) -
sqrt((Xl-Xb)^2+(Yl-Yb)^2)) == 0)
leftIsEquidistantfromtopandbottom;
If(sqrt((Xl-Xc)^2+(Yl-Yc)^2) -
sqrt((Xc-Xr)^2+(Yc-Yr)^2)) == 0)
leftandrightareequidistanttocentre;
if (leftisequidistanfromtop and bottom &&
leftandrightareequidistanttocentre) DrawOvalFunction;
/* 
Otherwise do nothing. 
Note that if the two conditions are true, so is
RightIsEquidistant, so we don't need to test for this.
*/

An alternative syntax is possible avoiding the
potential for invalid ovals: oval(CentreX, CentreY,
TopcornerX, TopcornerY, LeftcornerX, LeftcornerY)

Here the coordinates of the bottom and right corner
are implied by the position of top and left corners
respectively (i.e., since the line between the left
corner and right goes through the centre, and the
distance between the left corner and the centre; and
the right corner and the centre is equal).

This seems more satisfactory.

-----
Which leads me neatly onto one of the other things I
really want to see, viz. shaped borders.

There are three possible ways of doing this:

1. Via a border-shape property.

The initial difficulty here is that it seems to
complicate the box model unduly.

However, this difficulty is entirely avoided if you
draw the largest shape that can be drawn within the
element box.

2. Via an outline-shape property. This entirely avoids
any problems with complication of the box model.

3. Clip-border, clip-border-color, etc. This, IMO, is
the best of all the options. This would take all the
valid values for border but would allow shaped
borders.

The main advantage of this is that it allows the
shapes I have proposed for clip to be reused, and also
avoids complication of the box model. The main thing
of note is the position of the border - would it go
inside the clipping region or around it?

Post scripts:

1. The CSS spec seems to have overlooked: DIV {height:
Ypx; width: Xpx; clip: rect(T, L, B, R)}, where Y - B
> T or where X-R > L. E.g., DIV {height: 100px; clip:
rect(60px, 0px, 50px, 0px)}. 

The CSS spec strongly implies (though it doesn't
actually explicitly state) that rect(top, left,
bottom, right) refers to the offset of those sides of
the rectangle from those sides of the element.

If this is the case, how can the bottom edge be above
the top (as in the example above)? 

If it is not the case, a clarification of the spec
would be appreciated.

2. % would be defined for the clip shapes I propose
(relating to height and width). It beats me why they
are not defined at the moment.

=====

__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com
Received on Monday, 1 November 1999 11:01:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:01 GMT