Re: [gcpm] border-parts

On Oct 30, 2008, at 10:36 AM, Tab Atkins Jr. wrote:

>
>
> 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.

What you call "fancy borders" are really what I would call "dashed  
borders". And I agree that with a powerful syntax for specifying the  
dashes and gaps, combined with a flexible unit of measure, that they  
can be "stretchy and still look good". It is still dashes and gaps  
that we are talking about. I just don't think we need two separate and  
different ways to say that a border can be dashed. It is better if the  
new proposal is used to enhance the existing dashes. Especially if you  
consider progressive enhancement. I think I would want to at least  
specify a "dashed" border-style in UAs that did not yet support  
"border-parts". But if I specified both, and if "border-parts" did not  
override "border-style", then I clearly would not get the desired look  
in a more capable UA.


> Only *one* of the examples in the document concerns itself with  
> merely creating a "de facto short HR".

Exactly my point. The document describes a way to create dashes, and  
you are also trying to overload it to create something altogether  
different: a single line segment to precede a paragraph.


> 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.

Of course not. Because the proposal describes ways of creating dashed  
lines, where the author has control over the lengths of dashes and  
gaps. The code I show above is to address your separate need of  
wanting a short divider line before your note.

> 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.

A leader _is_ presentational, with no textual meaning, but it still  
uses text elements. The dots in a leader come from the font, but they  
are not pronounceable, and are not punctuation. They are there to  
guide your eye, in visual media (or to guide your fingers in tactile  
media, I suppose). It is no more/less textual/presentation when you  
use it to divide content (as above) than when you use it to connect  
content (as originally conceived).

> 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).

Or you could just use the HR inside of your existing block-level  
element. Or you could float it too.

> 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).

A fancy dashed border? Or a short line segment?

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

Assuming we are still talking about your short line segment to DIVide  
content, then you could use a floated zero-width DIV instead of an HR  
then. But if by "fancy border" you mean "a border with a series of  
dashes and gaps", then yes, I do believe this proposal would work well  
to specify the dashes in a line with "border-style: dashed".


> border |ˈbôrdər|
> noun
> 3 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".

At least border-top defines one of the border's boundary edges. A  
single short segment of the edge does not.


>> 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.

No, I am not. You misrepresent what I am saying. Where do I suggest  
hacking the dashed border type? In fact I am saying the exact  
opposite. I'm saying that what is being called "border-parts" should  
be used to define the dashes in a dashed line, and that creating a  
single, short, dotted line segment above an element is a separate  
problem that should not be lumped together with this great way of  
defining dashes.

This "border-parts" property looks, acts, and quacks like a property  
to define dashes, with a lot of control over spacing and length of  
dashes. Your biggest issue is that you you want to create a single  
segment using a single dash in a dashed line, and you also want to  
make it dotted. Using a de facto dashed-line-defining property to  
create a single short (not-really-dashed) segment is a hack. But  
because you can't create a border style that is both dashed and dotted  
at the same time, you can't do it, as long as this dash-defining  
property works in the manner that would be most natural, i.e. to  
define more presicely what "border-style: dashed" already does.


> 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.

Neither would I, as there is already suitable syntax for that. But you  
are suggesting something similar when you suggest creating a single  
segment by using a property that, in fact, does define dashed lines  
(and that is primarily what it does). The fact that the property is  
not very compatible with the existing property for defining dashes  
seems to matter less to you than your desire to use these new dashes  
and the old dots at the same time, to create something that no longer  
looks like a dashed line.

> 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.

Exactly. Yet the property that evolved is one that is primarily about  
creating dashed lines (without any regard for existing dashed lines).  
I would say make it ALL about that, fix it so it works better in  
conjunction with border-style, and use something else for that very  
separate use case you mention, if using this new dashed line proposal  
prevented you from getting the dotted segment you are looking for.

> 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).

Do you seriously want to use the existing dashed style together with  
these new kind of dashed lines? "border-style:dashed" and "border- 
style:dotted" already define a line in which "parts of the border line  
are invisible". If "the visible sections of the border line" are not  
solid, then they contain areas that are not visible. Not visible part  
of the line = gaps between dashes or dots.

> 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.

Yes, I understand that you want to be able to use dashes and other  
styles at the same time.

> 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?

I think the fact that we can control the lengths of the dashes and  
gaps of a dashed line is the most important part of the proposal. The  
fact that it does not work well with the existing way of creating  
dashes is a flaw, and I think it is a bigger flaw than the purely  
hypothetical use case of creating beveled, unconnected corners.

> Is there a simpler way to express them that doesn't seem (to you) to  
> be semantically muddled?

No, Ijust don't think that is as important or useful as the parts of  
this proposal that allow you to create precise gaps and dashes in a  
(de facto) dashed line.

>> (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.

I think it would be very odd to have two different properties that did  
almost the exact same thing. This beast has every you would need to  
create precision in a dashed line (aside from integration with  
existing dashed styles), and you are trying to overload the concept  
with additional features that don't belong, in a way that hurts that  
welcome ability. If we changed the name from "border-parts" to  
"dashes" and make it only apply to border-style:dashed and border- 
style-dotted, and it would be ideal then for that purpose. Then, if  
having a short dotted line segment or disconnected beveled corner is  
also important, find another way to do that or create another property  
(or another value to an existing property).


>
> ~TJ