W3C home > Mailing lists > Public > www-style@w3.org > April 2013

RE: [CSS Box Model] Metrics Snapping Proposal

From: François REMY <francois.remy.dev@outlook.com>
Date: Sun, 7 Apr 2013 21:04:13 +0200
Message-ID: <DUB120-W120A168EE788922F44880EA5C40@phx.gbl>
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

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:10 UTC