Re: [gcpm][grid] border-parts

On Thu, Oct 30, 2008 at 8:24 AM, Håkon Wium Lie <> wrote:

> Also sprach Tab Atkins Jr.:
>  > > [1]
>  > I like it.  The repeat() function is powerful and works as I would
> expect.
>  >
>  > In examples XXXV and XXXVI, it's not clear to me *why* there's a
> remaining
>  > border on one and not the other.  The boxes appear to be the same width.
>  A
>  > note on XXXVI specifying that it has a slightly wider box than XXXV
> would be
>  > helpful.
> The boxes are, in fact, slightly different in size and this is why
> there is a remaining border in one of them. I've added some text in
> the examples to explain this.

The new text works well, thanks.

>  > I'm vaguely dissatisfied with the name 'fraction' as the stretchy unit.
>  It
>  > doesn't seem to convey "this will fill available space" to me - it
> sounds
>  > like an alternate name for a percentage, and something I should be
>  > specifying with a ratio.  But this is obviously a minor issue (though if
> it
>  > can be changed both here and in the Grid module, I'd be happy).
> What would you call it instead? One flex, two flexes? And yes, this
> would have to be discussed in the context of grids; I've just imported
> the 'fr' unit from there. [grid] added to subject line.

If I had a choice, yeah, I'd go with flexes as the unit, abbreviated fl.
This squares with similar proposals, along with many thematically similar
things where a length or area that takes up available room (possibly sharing
this with other take-up-available lengths) is called "flexible", such as in
the Flexible Box proposal, flexible row/column heights in the Template
module, etc.

 > I'd like an example with multiple fractions of various types.  Right now
> all
>  > the examples with fr use it in the simplest way possible, and I think it
>  > won't be clear just how powerful this is if there isn't something
> decent.
>  >  Maybe a border-parts-top:3fr 10px 2fr 10px 1fr 10px 10px 10px 10px 10px
> 1fr
>  > 10px 2fr 10px 3fr.
> Good point. I've added a (slightly simpler) example.

Looks great.

>  > % should definitely key off of pure element width, for simplicity with
> other
>  > uses of the same.
>  >
>  > I have vague thoughts swirling in my head about complexifying repeat().
>  >  Right now it's a fraction with infinite value - it eats *all* available
>  > space that it can, and only after it's done do the fractions have a
> chance
>  > to grab some width.  What if you could optionally specify a width in fr,
> and
>  > it would be laid out accordingly?  I ask because the example I suggested
>  > above originally had the central "10px 10px" bit in a repeat, until I
>  > remembered that it would squish the fr parts down to nearly nothing.
>  For
>  > some reason in my head the repeat() section was going to end up
> something
>  > like 6fr in width.  I'm not sure if this is strictly necessary, though.
> I see your point -- the fractions don't combine optimally with the
> repeat function. Fixing this seems complex, and perhaps not worth it.

Yeah, I'm not sure if it's worth it either.  In my case, I was trying to
create something that appeared to shrink from large bars on the outside to a
normal dashed line in the middle.  However, manually specifying a couple of
center dashes covers that adequately, so meh.  I say no need for it yet -
this can always be extended in the future with another argument to repeat().

>  > What happens if you specify fr units within a repeat() expression?
> That would work as long as there are lenghts/percentages there as ell.
> The resulting border parts would be very short -- especially in long
> borders.
> If the repeat pattern consist of only on fractions, there would be
> infinetely many of them. I've added text to make this illegal.

Are you sure that works?  Say I specify border-parts: repeat(1fr 20px).  How
many times can this repeat?  It seems that the answer is anything from 1 to
the total width/20 (if you allow the fr to shrink to nothing), with no way
to choose one number as correct.  If an fr unit appears outside of the
repeat this could possibly resolve to a definite answer (since the fr has to
stabilize on a single value within the expression), but calculating this
would be very complex, and still has a decent chance of resolving to
multiple possible answers.


Received on Thursday, 30 October 2008 16:02:06 UTC