- From: François REMY <francois.remy.dev@outlook.com>
- Date: Sun, 7 Apr 2013 21:04:13 +0200
- To: Si Robertson <retromodular@gmail.com>, "www-style@w3.org" <www-style@w3.org>
Hi, sorry for the delay I've kept this mail flagged for quite some time but didn't find enough time to write a response to it before today (more inline). > Hello, > > This is my first post to this mailing list so hopefully I am doing > things correctly here. Yes, the CSSWG is one of those relatively open spaces where it's possible to give ideas and feedback very easily and conveniently, and this mailing list is a good starting point, usually. > In a nutshell, I am proposing what is essentially a metrics based CSS > rule that forces the width and/or height of a DOM element to "snap" to > a multiple of a specified value. Here is an example of what the markup > could look like ... > > element { > snap-width: 100px; > } > > The math required to calculate the snapped value (the width in this > case) is simple ... > > element_width = snap_width_value * ceil( element_measured_width / > snap_width_value ) I think this idea has been discussed here before, though I couldn't find any thread linked to it. It's possible that it was off-list or that it was just part of a more important discussion. The problem with this proposal is that the width calculation is quite dependent of the layout module you're using (ie: we don't compute the width of an inline-block element and of an flex-item element the same way) so it's probably not so easy to have the snap-width properly properly supported in all of them. What do you do, for example, in the case of a flexbox where it's impossible to respect both the size constraints and the snap-width constraints? Those things have to be defined, which is why it's not as trivial as specifying a mathematical formula. > I guess you could think of this behaviour as snapping the size of a DOM > element to a grid, and grids are something that are sorely missing from > CSS right now. You should have a look at Microsoft's CSS Grid specification, that's probably solving some of your uses-cases already, though it doesn't support native auto-row-spanning as far as I know (but I could be wrong on this, because I didn't follow the latest drafts changes). If you have a specific use case in mind, it's probably worth throwing it out, some people might redirect you to the most straightforward solution to your problem, or the WG may discover a hole we may want to cover in a future revisions of the specs. Best regards, François
Received on Sunday, 7 April 2013 19:04:41 UTC