From: Sen Hastings <sen@phobosdpl.com>
To: sen@phobosdpl.com
Cc: thomas.petazzoni@bootlin.com, buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCH v1 2/2] support/scripts/pkg-stats: optimize CSS selector usage
Date: Tue, 30 Aug 2022 01:34:07 -0500 [thread overview]
Message-ID: <20220830063407.1671668-1-sen@phobosdpl.com> (raw)
In-Reply-To: <20220808222312.19419-2-sen@phobosdpl.com>
On 8/6/22 16:55, Thomas Petazzoni wrote:
> Hello Sen,
>
> On Fri, 5 Aug 2022 15:01:14 -0500
> Sen Hastings <sen@phobosdpl.com> wrote:
>
>> Having lots of CSS selector declarations adds up, especially at 70k+
>> elements.
>>
>> This reduces the number of CSS selectors printed in the markup
>> to the bare minimum, by using pseudo-classes and tag names as selectors.
>
> Not sure how this works.
See my explination below about magic number 13. :-)
>Is there a significant size benefit?
Absolutely. I actually had a cover letter for v0 of the patchset:
https://lore.kernel.org/buildroot/20220805185821.261049-1-sen@phobosdpl.com/
Just as a quick rundown:
The old pkg-stats,
(https://git.buildroot.net/buildroot/commit/?id=eae86599ca81c943821bac33f424669520a3fa8c)
when given the current package list gives me an html file sitting at about 2.9MB.
example: https://sen-h.github.io/pkg-stats/eae86599ca81c943821bac33f424669520a3fa8c.html
The current pkg-stats gives me a whopping 7MB file.
example: https://sen-h.github.io/pkg-stats/c245575.html
but you can see this whittled down by [PATCH v2 1/2]:
https://sen-h.github.io/pkg-stats/b6f4cbddb14233c3ab3fdfea1e486c14871cfb2a.html
(3.2M)
and then by [PATCH v1 2/2]:
https://sen-h.github.io/pkg-stats/9ad05210dcd9e4fb6b6a45be87c0fbb3e022085b.html
(2.6M)
> Sometimes having a dumb but obvious solution is better than having a
> smart but convoluted solution.
Although I admit nth-child seems exotic, I think it's actually pretty straightforward.
CSS is of course all about cascade and layers of specificity,
and I definitely think the size savings is worth it.
>
>> +div {
>> + text-align: center;
>> + border: solid 1px gray;
>> +}
>> +#results-grid div{
>> + text-align: left;
>> +}
>> +#package-grid div:nth-child(13n+1), #package-grid div:nth-child(13n+13) {
>> + text-align: left;
>> +}
>> +#package-grid div:nth-child(13){
>> + text-align: center;
>
> What is this 13 magic number?
13 is the the number of columns.
Rather than giving every item that needs to be centered a "centered"
class selector, we center all div elements and then selectively
left-align the ones we want.
div { text-align: center;}:
centers all div elements, which includes the cells in the grid.
#package-grid div:nth-child(13n+1):
selects the first element in the grid and then every 13th+1 element
thereafter:
(13*0)+1 = 1, (13*1)+1 = 14, (13*2)+1 = 27 etc...
this effectively targets every cell in the left-most column.
#package-grid div:nth-child(13n+13):
selects the 13th element in the grid and then every 13th element
thereafter:
(13*0)+13 = 13, (13*1)+13 = 26, (13*2)+13 = 39 etc...
this effectively targets every cell in the right-most column.
so our columns go from this:
1 2 3 4-12 13
| label | label | label |...| label |
| data | data | data |...| data |
to this:
1 2 3 4-12 13
|label | label | label |...|label |
|data | data | data |...|data |
Except that traditionally the right-most column label is centered.
(at least that's how it was when I started)
so we use:
#package-grid div:nth-child(13){text-align: center;}
to center *just* the right-most column label (the 13th element)
so now it's:
1 2 3 4-12 13
|label | label | label |...| label |
|data | data | data |...|data |
see: https://developer.mozilla.org/en-US/docs/Web/CSS/:nth-child#examples
>
> Also, unrelated to this, when I look at the currently generated HTML,
> it looks odd. I see things like this:
>
> <div id="upstream_url__package_kodi-audiodecoder-vgmstream_kodi-audiodecoder-vgmstream" class="centered upstream_url data _package_kodi-audiodecoder-vgmstream_kodi-audiodecoder-vgmstream good_url"><a href="https://github.com/xbmc/audiodecoder.vgmstream">Link</a></div>
>
> Why do we have these crazy id values now? why does the class property
> contain a value such as
> _package_kodi-audiodecoder-vgmstream_kodi-audiodecoder-vgmstream?
Good question. It has to do with sortGrid() needing unique class
selectors per row.
see: https://git.buildroot.net/buildroot/commit/?id=786f8b45672ebdd432f6af5b7595d3d16013433b
sortGrid() sorts by virtue of all the elements in a column sharing the
same class (which orginally was also the column label)
and all the elements in a row also sharing the same class
(which originally was also the package name).
The problem (previously) was that some package names were duplicated across rows.
For instance look at these two cells in the package column:
<div id="package_barebox" class="package data barebox">boot/barebox/barebox.mk</div>
<div id="package_barebox" class="package data barebox">boot/barebox/barebox/barebox.mk</div>
these are the beginning cells of two rows and they both share the
*same* class selector "barebox".
Can't have that because we need every row to have a unique class
assigned to it.
Otherwise when we sort this happens:
|label | label | label |...| label |
|class1 | class1 | class1 |...|class1 |
|class1 | class1 | class1 |...|class1 |
becomes:
|label | label | label |...| label |
|class1 | class1 | class1 |...|class1 |class1 | class1 | class1 |...|class1 |
sortGrid pulls all elements by row class selector and gives them
an explicit grid-row assignment.
So now we have 26 elements in a row instead of 13 :p
The fix at the time,was to use the package path but with "_" instead
of "/", so:
boot_barebox_barebox and boot_barebox_barebox_barebox
respectively.
Also class selectors can't start with numbers so we prepend an "_"
to for the sake of packages like 4th and 18xx-ti-utils.
sortGrid (used to) derive the package class selector for the whole row by stripping it out of the id.
sortArr[0] = listing.id.replace(sortLabel+"_", "");
so:
sortArr[0] = "upstream_url__package_kodi-audiodecoder-vgmstream_kodi-audiodecoder-vgmstream".replace("upstream_url_", "")
yielding:
sortArr[0] = "_package_kodi-audiodecoder-vgmstream_kodi-audiodecoder-vgmstream"
PATCH v2 1/2 does away with this and uses programmatically generated
column/row class selectors.
I understand that javascript probably isn't a langauge most people on
the mailing list are familiar with, especially when it comes to the DOM
api.
So this email (and the previous one) are more of "why" and less of a
"how", but if it would be helpful I could do a line-by-line walkthrough
of sortGrid() just to go through how everything works.
Hope that helps.
[note: I originally sent this out on the 2022-08-08,
but not as reply to the previous message,
so it just showed up as a normal submission to the mailing list.
Re-submitting it for the sake of posterity.]
> Thanks!
>
> Thomas
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
next prev parent reply other threads:[~2022-08-30 6:34 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-08 22:23 [Buildroot] [PATCH v2 1/2] support/scripts/pkg-stats: move to procedurally generated row/column clases Sen Hastings
2022-08-08 22:23 ` [Buildroot] [PATCH v1 2/2] support/scripts/pkg-stats: optimize CSS selector usage Sen Hastings
2022-08-30 6:34 ` Sen Hastings [this message]
-- strict thread matches above, loose matches on Subject: below --
2022-08-05 20:01 [Buildroot] [PATCH v2 1/2] support/scripts/pkg-stats: move to procedurally generated row/column clases Sen Hastings
2022-08-05 20:01 ` [Buildroot] [PATCH v1 2/2] support/scripts/pkg-stats: optimize CSS selector usage Sen Hastings
2022-08-06 21:55 ` Thomas Petazzoni via buildroot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220830063407.1671668-1-sen@phobosdpl.com \
--to=sen@phobosdpl.com \
--cc=buildroot@buildroot.org \
--cc=thomas.petazzoni@bootlin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox