[WIP] 2020 re-design for the website #506
Conversation
This ensures anything relying on it stops relying on it.
This belongs in the styles.
This way we can hide it under narrow conditions; after all it *is* a redundant option...
The previous history for site-styles was quite cahotic. As this is an entirely new part of the site, I feel it is proper to lose its initial implementation history, considering *it had no real meaning*.
Re-do and review the JS partsQuite simply, take nothing for granted, as it was built with bootstrap's JS in mind, and not only that, but an older jQuery! The plan is to
The latter part is weird, but basically I don't want to see any In addition, all behaviour should prefer working through CSS class name changes, rather than modifying DOM properties, where possible. And, building from that last sentence, all behaviour has to gracefully degrade for JavaScript-less usage. I'm thinking about text browser uses, and content blockers. The main idea (to be done) is to rely on either |
In addition to removing the now unused pager block. The added blocks collect the HTML used within them, which will in turn be inserted at the proper location. This mostly serves my need for everything to be tidy, but it also serves the need for everything to be *correct*.
|
Hi, the "new strategy" for the "big angles" section could have a performance impact which has not been validated or tested yet. Though this is just a gut feeling, I don't have any proof that it could cause performance issues. I'm not positive on how to properly test it for performance, but I guess that if scroll is fine on an "underpowered" mobile device it should be fine. |
…page Background image in the hero section was causing some stuttering on mobile devices when scrolling. The limitatino with SVG on mobile devices is clearly not with the size, since the L shape of the search section works just fine, but with the number of lines in the SVG.
* add Features title * bump up all the header elements (h2->h1, h3->h2) * use 2 column view when on md screens or bigger
|
On my iPhone 5 (iOS 10.3.4), there's just NaN for the countdown. This is a very outdated device and OS though, I can't even update anymore :)
|
* default values (will be less "flickering") * hiding counter on older devices
|
@infinisil the above commit should "fix" the counter. well I hide it in the case |
|
@infinisil while the device's OS is outdated and you should probably figure out an update for your own good, this is going to be quite useful to know if the site is completely broken or if features degrades nicely on a less-compliant browser. If you can have a look around and compare with a narrow / zoomed-in browser window and gauge whether things are okay or totally wrong, it would be helpful. |
|
Two problems with text wrapping I noticed:
And on the governance page, only the RFC Process text doesn't fill the whole width of the page:
(same on both firefox and safari, they probably use the same web engine after all) Other than that, I'm not noticing anything problematic PS: I'm eagerly awaiting my Librem 5 still, so that's why I've been holding out with an 8 year old phone :D |
Ugh, there's a lot of repetition, but it basically is the same as the other one, except that at -sm- the columns are not laid next to each-other.
|
Thanks for testing! And good catches, here's a 🍪... But wait, there's more, those are not "old iOS" specific issues! Good catch on the governance page: a bug with the way columns spanning more than one column-width were handled. Basically they were still limited in width even if it was not needed at that width. As for the features page, the issue was the fresh The existing columnar layout implementation handled that case. Though it did not handle the desire to serve the columns in a linear fashion at |
|
Awesome, can confirm that fixed it! |
Note that the year is not an invitation to make this a yearly event!
How we'll proceed:
feature/2020-redesignbranchThis way we have this as the golden "next" website, it should be in a passable-to-ready state at any point, hopefully. At the moment this is opened, many pages are not fine, but depending on how we focus our energies either we can make them work fine first, or continue with the design of the components.
Note that criticism about the design in the sub-PRs will be broadly disregarded (but noted), to make the development go. Otherwise we'll stay stuck for long times in the implementation. Anyway most, if not all, of the suggestions can be bundled up at the end and fixed up at the end rather trivially; the implementation strives to stay flexible.
Broad strokes TODO
I'll try to expand on those broad strokes later.
Misc tasks:
Specific TODO