W3C home > Mailing lists > Public > public-css-archive@w3.org > February 2017

Re: [csswg-drafts] [css-grid-1] Clarify the reason of limit the rows/cols at grid, and increase it

From: Robert Utasi via GitHub <sysbot+gh@w3.org>
Date: Tue, 07 Feb 2017 18:28:03 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-278095001-1486492082-sysbot+gh@w3.org>
MatsPalmgren, before saying expressions: "wasteful", "junk", "ugly" 
just take a look at these links:

 - http://getbootstrap.com/components/#thumbnails

and see, how the front-end dews trying to kill their websites with 
these scripts:

 - http://masonry.desandro.com/
 - http://isotope.metafizzy.co/
 - http://salvattore.com/

Note that, from Einstein everything is relative :) so we just want 
replace these scripts with some really simple code, which one is 
currently the grid itself. Based on these libraries, the grid way with
 one script-running mechanism, based on load event handler, it is 
reallly ELEGANT and responsive via css, no javascript for 
responsiveness is necessary.

Anyway I suggested at https://github.com/w3c/csswg-drafts/issues/945 
using **float: top left;** instead of grid. That can be the final 
answer for masonry, until that grid is the simplest and fastest way to
 do it.

Just compare the scripts with mine. I know the answer, masonry 
libraries causes intristic processor-usage which is catastrophic on 
slow devices. Mine with grid id better. However the lazy-load always 
overlarge the pages, so it is always a memory issue.

In other way, on phone, for 1 column, no necessary the grid, we can 
disable the grid by **display: block;** and with it the slow decives 
are supported well with a mediaquery. This is elegant also. Not as 
these scripts do currently with full loaded absolute positioning.

That is not a question, who likes masonry and who not. We just need to
 hadle this somehow.

GitHub Notification of comment by hunboy
Please view or discuss this issue at 
 using your GitHub account
Received on Tuesday, 7 February 2017 18:28:10 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:08 UTC