- From: Brad Kemper <brad.kemper@gmail.com>
- Date: Sat, 6 Apr 2013 13:39:26 -0700
- To: Lea Verou <lea@w3.org>
- Cc: liam@w3.org, "L. David Baron" <dbaron@dbaron.org>, www-style@w3.org
The nice thing about SVG + border-image is that you could have a nearly infinite number of corner shapes as code snippets in a library. The bad thing is they don't interact as well with super-common CSS properties like background, box-shadow, and border. It would be nice if we could just say, "if SVG images are used for border-image, then background, box-shadow, and border get automatically converted to their closest SVG analogs within that image." Thus border-color and border width would change the stroke color and stroke width of the SVG, the entire background would become the fill for the SVG shape, and the box-shadow properties would be used to create a drop shadow filter on the SVG. Then hit testing would work automatically too. Call me a dreamer, but I think that would work great. On Apr 5, 2013, at 12:06 PM, Lea Verou wrote: > Hi Liam, > > I’m not saying border-corner-shape is the ideal solution, personally I find it a bit clumsy in some ways. I’m only saying that there is a large amount of use cases in need of a solution. I think what works best is a combination of common effects and an extension point. For example, CSS filters did this very well: They include functions for the common cases and take a custom SVG filter or a shader as an extension point. What I’m saying is that as much as I love SVG, “Use SVG” is not a solution here. > > We could add keywords to border-image, but what border-corner-shape does is not merely decorate the border. It changes the entire shape of the element, so that borders and box-shadows follow it, backgrounds are clipped according to it, the hit-testing area changes etc. If someone has a better idea about how to be able to do that in CSS, that would be fantastic, but we need a way to do it. Regarding polygons, border-corner-shape could be used to create any polygon up to 8 sides, but I agree it would be better to be able to do it with more elegant syntax that works for any dimensions the border-box might have. > > While I was researching this, I also noticed that it's very common to need polygons with corner rounding as well in their corners. So, perhaps we could have a property that defines the polygon shape the element would have and another for the line join and its rounding or bevel size. However, as you can see, this rabbit hole goes quite deep. Therefore, keeping border-corner-shape, warts and all, might be a better idea. > > Lea Verou > W3C developer relations > http://w3.org/people/all#lea ✿ http://lea.verou.me ✿ @leaverou > > > > > > > On Apr 5, 2013, at 07:08, Liam R E Quin wrote: > >> On Fri, 2013-04-05 at 05:42 +0300, Lea Verou wrote: >>> Here are a few more use cases, provided by the community: >> [...] >> >> Wow, quite a few links. >> >>> Also, here are a few comments from authors: >> >>> The most often example is arrows of any kind. Right now there are a >>> lot of hacks and tricks to make them work, but if you'd need one with >>> gradient, border and box-shadows — it would become really cumbersome >>> to emulate. [...] Another thing are negative border-radiuses near >>> tabs. >> >> Tabs seem to be such a pervasive design paradigm on the Web that one >> could easily argue for HTML-level support. >> >> As for borders - we spent some time in another group trying to find a >> way to make rectangular borders be a special case of general borders - >> e.g. a list of path segments with joins and styles >> >> SVG does not directly meet the use case for liquid layouts (you don't >> want the border scaling and taking up more room as the winder gets >> larger, e.g. the corner radius doesn't increase on a box when you resize >> the window) but could be made to do so. >> >> But even then, people will still want and use more corner shapes. >> >> Negative corner radii might make sense; SVG also has a list of corner >> join methods such as mitre and butt that could be used along with >> negaative radii. The more complex certificate-shapes are things I know >> I'd love to see, but fear we're baking special cases into a spec. Can we >> come up with a way to draw the corners that still as the right >> scaling/growing behaviour, and add fewer of the special cases? >> >> I don't want to stand in the way of something good - but I don't like >> lists of special cases either. Why not a double or quintuple scallop? >> Why not an inset with a specified radius? Or a polygon instead of an >> arc? They're all useful. >> >> I do like the negative radius, and I think the bevel is simply an >> example of line-join style that's already floating around, and I would >> be in favour of the others if I didn't think there was a chance of using >> SVG in a way that didn't make the lines get thicker when the content box >> got bigger. After that, we could pre-define some SVG paths and give them >> names, but users could add their own. >> >> Liam >> >> -- >> Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ >> Pictures from old books: http://fromoldbooks.org/ >> Ankh: irc.sorcery.net irc.gnome.org freenode/#xml >> >> > >
Received on Saturday, 6 April 2013 20:40:02 UTC