Re: [gcpm] border-parts

On Thu, Oct 30, 2008 at 11:04 AM, Brad Kemper <brkemper.comcast@gmail.com>wrote:

>
> On Oct 30, 2008, at 5:34 AM, Tab Atkins Jr. wrote:
>
> On Wed, Oct 29, 2008 at 11:54 PM, Brad Kemper <brkemper.comcast@gmail.com>wrote:
>>
>> It still looks to me like you are trying to define the dashes in a dashed
>> line, which would be awesome. But it seems kludgey to use a "solid" (not
>> "dashed") border with dashes in it, just for the single use case of wanting
>> a short line segment over a footnote. This is "underloading" what it means
>> to have a dashed line (not solid at all), and overloading "border" if all
>> you really want is a short, horizontal line segment. Has HR been deprecated?
>> It seems to be what you are actually trying to have in your use case; an HR
>> with a width. If there was no CSS, you would probably still want the HR
>> there to provide the semantic meaning of "separator of different kinds of
>> content".
>>
>
> As I pointed out last time Hakon asked for comments, actually switching to
> making this a special kind of dashed border would be much less powerful.  We
> would then be stuck with solid segments, and have no way to change this.
>  What if I wanted a short dotted segment?  The current border-parts proposal
> allows this trivially.
>
>
> That's why I don't think this should be used for generating short line
> segments. Short line segments are not borders, and it seems like what you
> really want is to be able to create short line segments AND have a way to
> specify the dashes and gaps of a dashed border. Me too, but I don't think it
> is the same thing. It would be more useful to have this type of notation to
> specify the dashes or dots in dashed or dotted lines (dotted lines could
> automatically have rounded ends). You are talking about a very powerful
> mechanism that can essentially create defacto dashed lines on all four
> sides, then saying that the reason you want to use it is to create a de
> facto short HR.
>

That's one reasoning.  Another is just fancy borders that can potentially be
stretchy and still look good.  Only *one* of the examples in the document
concerns itself with merely creating a "de facto short HR".


> We should have something else for creating short line segments. Maybe even
> this:
>
> P.note:before { content: "...................................................."; font-size: 8px; }
>
> Or this:
>
> P.note:before { content:leader(dotted); display: block; width: 100px; }
>
> Neither of these offer anywhere *near* the flexibility presented by this
proposal.  The first only allows absolute-width sections.  The second is
more flexible, but ties us to the presentation options allowed by leader.
Both are utilizing text for a non-textual purpose.


>  Or this:
>
> HR { width: 100px; border: 1px dotted black; }
>
> This is only workable if the content isn't specially positioned.  It
wouldn't help with a floating element, frex (unless you wrapped it in a
container <div> and put an <hr> in with it, which is blatant presentational
markup).  It also becomes a presentational element in situations where the
distinction between units is already present in the markup, frex, if you
wanted to give <li>s a fancy border (and I've had exactly that requested of
me).

None of these three proposals address a vertical border, nor *can* they.

border |ˈbôrdər|noun3 a band or strip, esp. a decorative one, around the
> edge of something : put a white border around the picture. *
> *
> *Note that a short line that happens to correspond with a small segment of
> one edge of a boundary would not fit this definition of going "around the
> edge of something". At least, not to me. People talk about "overloading" a
> property, and that seems to be what this is doing, when the primary reason
> for the spec is to just generate a single segment.*
>

By that definition, the border-top property is 'overloading' the concept of
borders.  ^_^  Technical uses of a word often drift from common uses, and
there's nothing wrong with that.  What's more, that's an especially focussed
definition of border, that wouldn't cover many real-world uses of borders on
things.  A more reasonable one that I've just culled off the internet simply
says "boundary; edge; limit".

**
>
> As well, it doesn't seem possible to use stretchy lengths in a dashed
> border, where the border is conceptually an infinite line that wraps around
> the box.  Using fr units in border-parts gives a lot more flexibility.
>
>
> I think that if once you start using stretchy units that each edge becomes
> symmetrical, then that is not so bad. Really, I am not suggesting to change
> that. I would just rename the property "dashes" instead of "border-parts",
> and only have it apply to dashed borders (and maybe to dotted borders too).
> Do not apply to lines specified as solid, because it has the effect of
> making them NOT solid.
>

You're complaining that border-parts is being used mainly to create a 'short
HR', then suggest hacking the dashed border type to handle this.  Does this
seem a little... inconsistent?  A single line doesn't make a dashed border.

You *could* think of this as making a solid border into dashed, but I
wouldn't.  I mean, what about this markup: "border: thin solid black;
border-left: none; border-right: none;".  This is no longer a border around
the box.  It's a dashed line surrounding the box (with very large dashes).
But we wouldn't try to hack actual dashed borders into doing this.

Within a single edge, where the argument makes more sense (but still, keep
in mind the whole box border), there's still no reason to declare that this
is actually using dashes.  As already stated, one use case is just to create
a single line, which certainly isn't dashed.  More importantly, though, when
you declare a border-style, *you're just talking about the border style*.
This is simply the drawn representation of the border line.  Border-parts
simply declares that parts of the border line are invisible.  It doesn't
gain us anything to declare that the visible sections of the border line
must be solid (which is what your suggestion does).  Instead, we can
trivially gain an enormous amount more freedom by making this orthogonal to
border-style, allowing me to use inset, or dotted, or double, or whatever as
the style.  I think it could be attractive to use an inset border just at
the four corners of a box, or a double border on a line floating in the
center of the top and bottom.  Is there any reason to disallow these
possibilities?  Is there a simpler way to express them that doesn't seem (to
you) to be semantically muddled?


> (With that being said, let me say again that I'd like a way to specify
> dashes as well, because that *does* offer me things that border-parts
> cannot.  Say a dashed border where the pieces gradually get long and then
> return to short, with this effect wrapping around the box.)
>
>
> I think this spec could and should be turned into something
> that satisfies the needs you describe for specifying dashes. I think it
> mostly does already.
>

Yeah, it would address a lot, and would enable things that border-parts
cannot.  But border-parts enables things that dashes would not, and
hopefully I've explained them adequately in this email.  These proposals can
coexist and complement each other.

~TJ