Re: [gcpm] border-parts

On Oct 31, 2008, at 1:39 PM, Tab Atkins Jr. wrote:

> I say that border-style is a statement of appearance only.  When one  
> says "border-style:solid" they're merely saying that, whatever form  
> the border takes, it should look like a solid chunk.  Similar,  
> "border-style:dashed" says it should look broken up into dashes,  
> "border-style:dotted" says it should look dotted, and "border- 
> style:double" says it should look like two borders.  In all of these  
> cases I have an unbroken border, but the appearance changes.

I consider it nonsensical to say that a dashed border is unbroken. Of  
course it is broken; many times.

> Thus, when border-parts comes along, I see absolutely no conflict.   
> In fact, I see opportunity here.

So do I, to specify the length and spacing of the dashes. That will be  
its primary benefit. Its just a question of if you want it to work  
with the existing way to specify dashes (which could work as a  
fallback), or if you are going to have two different ways to say that  
a line is dashed. The only conflict is if you specify a dashed border  
style and then use "border-parts" to create precisely spaced and sized  
dashes, and then style have the gaps from the border style overlaid on  
the dashes from border-parts. Then, instead of allowing "border-style"  
to work even in UAs that don't support "border-parts", you end up with  
an awful mishmash of the two.

> I can do the simple things of specifying all manner of specially- 
> positioned solid lines.

Most of which will be dashes of a sort, or else while be needed much  
more rarely than something than anything that looks like dashes.

> With repeat() and border-style:solid, I can make something that  
> looks like dashes.

But not associated with existing dashes from border-style, because you  
want to also use dots or bevel at the same time, which is a much, much  
rarer use case.

> With the full suite of powers, I can do even more interesting  
> things.  Now I change that to border-style:dotted, and I've got  
> something that was absolutely impossible before.

"Interesting" and previously impossible, but not anywhere as useful as  
applying this new property to existing dashes. And other than not  
being able to combine "dotted", "double", and "bevel" with these new  
dashes, I am not suggesting that we get rid of any other new,  
interesting, and previously impossible features. Loosing the ability  
to create disjointed beveled corners is well worth the gains of being  
able to use this as an adjunct to (instead of a replacement for)  
border-style:dashed.

> Now, your approach has merit.  It offers things all its own.  By  
> making border-style: define the *structure* of the border, we can  
> then use special-purpose properties to manipulate that structure.   
> border-parts would allow control over solid borders.  border-dashes  
> would work with dashed patterns, which repeat infinitely.  You could  
> even go so far as having border-dots to control the dots pattern, or  
> border-inset to control how thickly it looks to be inset.  This  
> creates an overall cleaner and more logical ruleset, but less  
> options; this may be a reasonable tradeoff.

Yes, I think so. What you name the new property tends to make you  
think of it in a certain way. I think if you take this new property  
and call it "dashes" instead of "border-parts", then it is easier to  
see how it already does everything you could want for a way to be more  
exact about what border-style:dashed means. In an earlier post, I  
included an idea to also apply it to dotted lines too. Once you can  
define the length of the dashes, you can make a dotted line out of a  
dashed line, as long as you don't mind square dots. So my idea there  
is that if you have "border-style:dotted" then you could have round  
ends on your line segments. In Adobe Illustrator many years ago, I  
used to make dotted lines by making the line segments about a tenth- 
point long, but with round end-caps whose diameter was equal to the  
border width (several point wide lines showed off the nice (nearly)  
circular dots. The gaps then needed to be more than twice the line  
width in order to show between the rounded end-caps.

Properties to also add more precision to what "offset", "inset", or  
"double" mean would be interesting. I almost never use those because  
they vary so much between browsers, and there are more reliable ways  
to get the same effects. For instance, "offset" and "inset" can be  
more reliably specified by naming the four colors you want for the  
four sides on a solid line. I haven't used "ridge" or "groove" for  
over a decade. But these go beyond the current proposal.

> One thing that leans me toward your proposal is the fact that my own  
> thoughts are complexifying this so much.  We went from "hey, how can  
> I do a solid border that *doesn't* touch the edge" to introducing  
> repeat() patterns, flex units, and possibly multiple levels of flex  
> (current proposal implicitly defines two levels of flex, and my  
> explorations were leading into making this explict, which Zack  
> highlighted more clearly).  While all of this certainly *can* be  
> used, is it at all necessary?  Even with the extra possibilities  
> brought up by combining various border-styles with border-parts and  
> repeat(), there's a lot more that is still impossible.  Is this  
> extra complexity necessary now?  Can it wait until later, when a  
> more general solution can be put together (say, multiple border  
> fragments, each specified separately)?  Would we ultimately be  
> better served by a conceivable general solution in the future, while  
> being adequately served by a deliverable solution in the present?
>
> This is a long-winded way of saying that I think I agree with you.   
> repeat(), while cool, in its current incarnation opens up only a  
> small fraction of the possible patterns.  Increasing its power would  
> greatly complexify the proposal, when this complexity is likely  
> better served by a more general treatment.  Would it be cool to  
> define a dashed border, where the visible portions were actually  
> inset?  Yeah.  But it's not *so* cool that I want to mess this up  
> for the future by overspecifying now.  I think we're better served  
> by simply introducing a flex unit (whether we call it fractions or  
> flex) and leaving it at that.  Manually specified "dashes" are  
> acceptable without stepping on the toes of actual dashed borders  
> (and probably impossible to prevent if you want the flexibility to  
> create the various non-dashed fancy borders that Hakon's examples  
> show).
>
> Of course, this isn't my baby, it's Hakon's.  Hakon, I propose  
> dropping the repeat() keyword.  We need some form of flex unit to  
> achieve the examples you have, but repeat() as-it-is-currently- 
> written is *almost* incompatible with flexes.  At the very least, it  
> renders them irrelevant except for filling in the occasional pixel  
> gap.  In order to make repeat() compatible with flex units, we'd  
> have to introduce a lot more complexity than currently exists (a  
> length argument to repeat(), multiple levels of flex).  I think that  
> right now we are best served by simply having a border-parts with a  
> flex unit, and then coming up with a border-dashes property that can  
> address the issue of repeat blocks more naturally.  This will make  
> the property simpler and more easily implemented, and provide a good  
> structure for a future comprehensive fancy-border treatment.
>
> Thoughts?

For dashed borders, I like most of what is being discussed. I like the  
idea of a border being symmetrical, so that it meets the corners in  
the same way on both ends. I also like the idea of repeating patterns  
of various lengths of dots and dashes. I THINK there is enough in what  
is being discussed to achieve both these goals.




>
>
> ~TJ

Received on Saturday, 1 November 2008 03:55:51 UTC