[WIP] Rework the site styles without changing the appearance... #409
Conversation
The "organization" menu was left to remove only on that page.
This was developed in parallel with the recent changes, so the following explanation is only right for the previous "community" page. > Even with bootstrap this was broken. Every "12 span lengths" you have to > open a new row! > > The only difference here is that our flexbox-based equivalent will not > size boxes automatically apppropriately. I have brought back this DOM as the actual fix is more scalable for the long term.
This includes the metrics as defined in the old nixos-site.css mainly.
The font-size was defined on body, while it should have been defined on html for rem to work as expected. This explains why I had to use /16.
Otherwise, in some situations, the contents of the dropdown would be occluded by the page contents.
And allow SVG images to be colourized.
Only non-structural things. Sure, they could be re-done, but at what cost? :)
It's 20, 15 is used sometimes, inconsistently, let's prefer 20.
But still TODO: implementing the hamburglar menu
This ends up closer to the previous ones.
It seems normalize has a bug? it sets *bolder* which doesn't work here on Firefox.
See 530b921 Though the `height` has been reviewed as line-height, with padding.
Also: * Rework the confusing lone </ul> at the end * Re-indent * Drop the organization menu
This belongs in the styles.
This ensures anything relying on it stops relying on it.
Required for it to work just right.
This wasn't an issue before we started using tabs for the opencollective display on the donate page.
The rows should be separated by the gutter by default. Same for any "box" like content.
|
I'm 👎 for this change. The cons you mention are too big of a deal for me, especially since we will have a major rewrite coming our way soon. This will also slow us down from improving and preparing the content for a redesign phase later this year. I consider that majority of the content that we create now will be migrated to new site (not all but most of it). I really don't see a value (at least at this point) to move further with this. On the contrary I only see a risk that gives us very little. I understand it is hard to look at the current page and not jump to fixing CSS. I have done it myself as well. But what is needed now is content, new getting started tutorial, footer, ... Next meeting I hope we will discuss how to move further with a redesign (the process) and that should give us better timeline when redesign is going to happen. Until then I would really like us (especially me) to not change too much in regards with CSS. If I would see this earlier I would raise my concerns earlier to prevent you from spending too much time. I hope I'm not too negative about this, I think this is a rabbit whole that I'm also trying not to fall into everyday. |
|
I don't think you're seeing that I'm front-loading some of the work needed for an upcoming redesign. Unless you intend to make it just another bootstrap site. By working this way, I'm spreading the load and I believe making it actually more manageable to work with the site. I listed those cons to be completely open and honest, but I now see I shouldn't have listed cons there. They are minuscule compared to the benefits. It is fixing actual problems, not imagined problems. Furthermore, this is work that I intended to bring into Hydra, as Hydra has the same issues. Though now I'm not too sure I want to start working on improving Hydra. It feels like it's going to be a hard sell. Let's instead continue at making this a worse mess by doing more inline styles, and tacking more bad hacks. |
This may sound counter-intuitive, but this is something we want.
We are stuck with an older bootstrap version, with all the quirks that it entails. We are also "stuck" in our ways, and it's not the time to re-design the site.
This is why this re-implements the current theme using a mix of fresh CSS, and imported CSS from bootstrap 2 (for purely visual things).
This gives us the ability to actively work on improving the visual presentation of the site, without forcing us to contend with the overbearing bootstrap implementation details.
TODO
Pros
This is something that has been bugging me for years. The "small" size of the bootstrap 2 layout shows the "hamburglar" menu,
stealing the juicy burgershiding the menu items while they perfectly fit in the given width!This is personally aggravating given that my vertical menu, with a 1.5× device pixel ratio ends up being "small". This means that I need to use the harmburglar menu in a situation where it doesn't make sense.
With that said, it's more than an improved menu, we get to control the responsiveness levels
Bootstrap 2 was built on top of
pxunits, and most rules are defined as pixel sizes. A bit worse than that: some rules, like line-height, are defined inpxmeaning that if the font size is adjusted, theline-heightalso has to be adjusted.This is fixed by using font-relative sizes. Either through
emorrem, depending on which makes sense. (Text-dependent sizes are defined asem, while otherwise it's mainlyrem.)Now that we have the layout metrics dependent on the font-size, we can freely tinker with the font-size without breaking the layout (#273). It is yet unknown how we'll tinker with it, but a possibility is for wider and taller windows, we can start scaling the whole site.
This is a "me" thing. I hate how the first thing shown on the website is the right lambdaflake, but the wrong logotype (font).
before:
after:
This is something I personally think. That having the whole styles laid out in distinct LESS css files is a net advantage in maintainability. With LESS, we're also given the ability to implement programmatic solutions to annoying problems. The main advantage, and it's an upcoming change for another PR, is that we can start reworking all the DOM of the pages. We can start dropping all the non-semantic markers, and work on a better maintainable DOM. That better DOM should, in turn, be easier to work with once we begin re-designing in a further future.
With HTTP2 it's less of an issue, but I still am firmly a believer that reducing requests can be beneficial for resources that are omnipresent.
Though, reduced complexity in download size, and more importantly, in parsed CSS is always good. Even if this won't affect 99% of the users, the reduced complexity in the produced CSS size could end up beneficial for less powerful hardware (e.g. an allwinner phone running full-blown firefox).
Using a bad methodology, I manually refresh the homepage, with cache disabled on firefox, I hit ~ 400ms/1.04s on netlify with the new site, while the current site it's more like 800ms/1.4s... Those number are small enough and my methodology flawed enough that it can't exactly be trusted. Though it tends to point towards improvement.
Cons
Even with all the pros, there are some cons.
This is especially unforgiving for developers less familiar with web development. To counter-act this, I intend to make myself available on a regular basis to work on layouting/styles issue for contributions.
I'm not the best one to judge if it's hard to work with, this is my usual approach and I've not had to work with a team before using that kind of implementation. Though I did try to implement this in a structured manner.