Platform Pages and Redesigned Nav / Footer

[ghost]

Description

Adds new Platform Landing Page.
Adds new Platform Security Analytics page with Platform Category template.
Adds new design for site navigation header.
Adds new design for site footer.

Check List

• Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the BSD-3-Clause License.

[AMoo-Miki]

Do to the huge number of files changed, let's make sure we have a few of FEE folks review this before merging.

[dtaivpp]

Edit: Tested with the mobile view option in firefox.

1. For the Community Voices page on mobile there are 3 nested elements that scroll independently which can be challenging to activate on mobile.

2. For the OpenSearchCon hero banners we need to have some way to ensure we don't upload wide images. Maybe we need a mechanism for swapping these images depending on the layout.

3. Download on OpenSearch and Checkout on GitHub overflow past the website boundaries on mobile.

4. Nav bars flow behind main content window on mobile:

5. Are we supposed to be able to search on mobile view?

6. Testimonials page seems to have broken images on the testimonials.

7. Some page titles overflow in unexpected ways.

[AMoo-Miki]

There are 10 uses of object-fit: fill in

• _sass/_redesign-platform.scss
• _sass/_redesign-platform.scss
• _sass/_redesign-platform.scss

which will result in distorted and unpleasant rendering. object-fit: cover will be better.

That said, I am not a fan of the position: absolute and the fixed height and width (dictated by a fixed aspect ratio). If we have images than contain information, cover might chop off important stuff. The best strategy would be to remove the aspect ratio, removed the fixed height, let the rendering be dictated by the width, and add a transition for the heights, if needed.

[ghost]

I agree. We need a specification for how images behave responsively. Whether to maintain aspect ratio with rules about how to position, and what to fill in the space, or to crop. I have reached out for design guidance on this. The really high touch graphics look great at or near their source geometry, but across variable viewports things get dodgy.

[AMoo-Miki]

One delegate should handle all of these; adding too many event listeners could slow the page on certain platforms.

[ghost]

Agreed. The event listener is one static function reference, and there are only 4 buttons, and I have hardcoded the submenu heights for the custom CSS property to be applied as --expanded-height. I did this quick and dirty to get it done, however I have this resolution prioritized as a fast follow; along with a runtime determination of the height. This is for being able to do a smooth height transition.

[AMoo-Miki]

Can we just move this to an external svg and load it as an image?

[ghost]

That's interesting. I'm not sure what the most optimal approach would be. The idea here is that we have a Figma pattern library with named icons, and the icons.html include file can be used to pull in those icons where they're needed. Would the SVG data being external improve performance, either at build time or at runtime?

[AMoo-Miki]

Using the icons.html this way practically inlines the source of the SVG, making the pages heavier. If they were external assets, they would be cached for subsequent uses.

[nateynateynate]

LEEEEEEEROYYYYYY JEEEEENKEEEEEINS