RE: [css-snap-size] Use 'factor' as the term?

If we are ready to bikeshed this, I think "step" might be better than "factor".

> -----Original Message-----
> From: Alan Stearns []
> Sent: Wednesday, March 2, 2016 1:30 PM
> To:
> Subject: [css-snap-size] Use 'factor' as the term?
> Koji,
> I mentioned this in IRC, then kept thinking about it for a bit. Here’s some
> more feedback to mull over:
> The feature as described in the draft is a way to constrain lengths to a
> multiple. I think ‘factor’ or ‘mod’ is a better term for this. Those terms let me
> know that the value given is going to modify some other value. I’m guessing
> that ‘factor’ is a bit better for those with less math/programming knowledge.
> The draft currently lets you do this for line box heights and available inline
> size. But the properties refer to ‘height’ and ‘width’ so it’s not very clear that
> it’s not the element’s height and width being modified. So instead of ‘snap-
> height’ I suggest the property be named ‘line-height-factor’.
> This does two things - first it makes it very clear that it’s line-height being
> modified. Second, we can treat it as a longhand of ‘line-height’. So if I set
> ‘line-height’ it clears the ‘line-height-factor’ value - I don’t have to hunt down
> the new property to find out why my line-heights aren’t what I specified. We
> could at some point in the future make ‘line-height-factor’ settable in the
> ‘line-height’ shorthand, if that proves useful.
> Then (and I’m less sure about this) your current ‘snap-width’ could change to
> ‘line-width-factor’. Again, this makes it more clear that what you’re setting
> affects available inline sizing. In this case there isn’t a property that directly
> sets available inline size, but one could be added as a shorthand for that and
> ‘line-width-factor’ in the future if it’s needed.
> I think there are other lengths where it might prove useful to add factors -
> block width and height being the primary case I have in mind. By making *-
> factor properties longhands and adding line-* to the current pair, we open
> the door for adding factors to other length properties in the future. This
> would clear my objection to the current draft - as long as we don’t cut off
> block size factoring, I’m OK with not defining it right now.
> Thanks,
> Alan

Received on Wednesday, 2 March 2016 22:02:44 UTC