Re: [gcpm] border-parts

Brad, we're talking past each other.  Let's start over, for the sanity of
those following the quote pyramids if nothing else.

Fundamentally, we're disagreeing on whether border-style is making a
statement about the *appearance* of the border, or the *form* of the border.

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.

Thus, when border-parts comes along, I see absolutely no conflict.  In fact,
I see opportunity here.  I can do the simple things of specifying all manner
of specially-positioned solid lines.  With repeat() and border-style:solid,
I can make something that looks like dashes.  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.

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.

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?

~TJ