W3C home > Mailing lists > Public > www-style@w3.org > March 2016

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

From: Francois Remy <francois.remy.dev@outlook.com>
Date: Wed, 2 Mar 2016 14:02:10 -0800
Message-ID: <DUB408-EAS4131870625A1E5581CC123BA5BC0@phx.gbl>
To: "'Alan Stearns'" <stearns@adobe.com>, <www-style@w3.org>
If we are ready to bikeshed this, I think "step" might be better than "factor".


> -----Original Message-----
> From: Alan Stearns [mailto:stearns@adobe.com]
> Sent: Wednesday, March 2, 2016 1:30 PM
> To: www-style@w3.org
> 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

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:01 UTC