W3C home > Mailing lists > Public > www-style@w3.org > October 2012

Re: [css4-background][editorial] round missing from the list of acceptable values for border-corner-shape

From: Brad Kemper <brad.kemper@gmail.com>
Date: Fri, 12 Oct 2012 19:02:03 -0700
Message-Id: <4B137223-3021-4F22-A914-FBFD7ABC4BFE@gmail.com>
Cc: "www-style@w3.org" <www-style@w3.org>
To: fantasai <fantasai.lists@inkedblade.net>
On Oct 11, 2012, at 10:58 PM, fantasai <fantasai.lists@inkedblade.net> wrote:

> 
>> It might be nice to have something in the document that says what is new.
> 
> It's... not really in a consumable state at the moment. :) I
> think it needs to be resync'ed against css3-background firstly,
> and I suspect there are issues with the partial-borders feature,
> which was just straight-up copied from GCPM. There's reasons
> there's no FPWD!
> 
> (Fixed the initial value error, tho. Also added an unmaintained
> warning: feel free to comment on stuff, but don't try referencing
> it for implementation work!)

OK. I'll comment to say that I don't find the partial borders thing to be terribly useful. I'll grant you that it is sometimes useful to have a short border (not full width) on the bottom or top of an element, but this seems like overkill for that, and I can hack that effect with a non-blurred negative-spread drop shadow that is y-offset by one or two pixels more than the negative-spread distance. So, doable today in a hacky way, and maybe need a little better way to do it less hackily, without going this far. 

The other thing that it sort of enables is dashed lines. But I would much rather see that as part of border-style, with something like the following:

border-style: dashed([<endcap-style>,]? [mirrored,]? <dash-length>, <space-length>[,<dash-length>, <space-length>]* )

Where 'endcap-style' would be 'none | square | round' (or 'none | square | curved'?), defaulting to none. And where if the lengths were bare numbers then that number would be a multiple of 'border-width'. 

So, ie9's nice 'border-style: dotted' borders, with their nice round dots, might be something like this:

border-style: dashed(round, 0, 3)

The first number is zero, because that is the length of the dash before adding the two semi-circle end caps. That is how Adobe Illustrator measures it, and also (I think) canvas. (Before you comment on that second number, please read on.)

And where 'mirrored' would mean that the border on that side of the box is symmetrical wrt the dashes. That is, layout the dashes and spaces to the halfway point, then reverse them to the end of that side's border. 

The 'mirrored' keyword complicates it somewhat, but allows you to do what the partial-borders feature does. 

Some questions to answer if we proceed with this:

1. Do we also need a 'round' keyword that works similarly to border-image's round' keyword, to add or subtract spacing between dashes, as necessary to get them all spaced evenly? If so, we need a different word for round endcaps. Or is the space rounding just automatic? And should this rounding ever cause dashes to overlap when the author did not use a negative number? 

2. When there is a border-radius of 1px or more (suppose much more), then the distance on the inside of that curve is less than the distance on the outside of that curve. So where is the dash length measured? Along the inside of the border, or the outside, or the middle, or the middle rounded to the nearest px, or what? I can see reasons to chose any of those, but I'm not sure it's worth another keyword switch. The partial borders thing in the editors draft would eventually need to deal with that too. I'm not sure how canvas handles that, or if canvas's way is relevant to us. 

3. Even if we don't include endcaps in dash length, what about in the space length? Should the space be measured endcap to endcap, or dash end to dash end. I prefer the latter, so that if animating the dashes, you could switch endcaps without changing dash position. Also, you wouldn't need to allow negative numbers for space lengths in order to get endcaps to overlap a little. But it might be slightly less intuitive for some, as in my 'dotted' equivalent above. 

4. Assuming the dashes start in the upper left corner, and proceed around the entire element, except when 'mirrored' is used. Does this create problems? Can we pick a definition where the dashes start if the upper left corner is a curve (similar to deciding where a bevel join would be).

5. If endcaps are semi-circles or semi-squares that are fitted flat against the ends of the dash segments, there will be some curves that have part of some endcaps sticking outside of the normal border-box shape. Is that acceptable, or how do we prevent that? Would they be clipped?

Anyway, those are some of my thoughts about dashed lines, some of which would also apply to other ways of segmenting borders. 

I would also like to see 5x5 and 5x3 tiles for border-image, instead of just 3x3. 

I wanted to start working on a spec for all that, but I have just been too busy. 
Received on Saturday, 13 October 2012 02:02:39 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:01 GMT