-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement redesign of portfolio example #5765
Conversation
Still missing mobile menu interactions
Thank you Yan 💜 Co-authored-by: Yan Thomas <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is looking amazing! Had a few small copy comments, recognizing this is all placeholder content.
I also think using Content Collections would be ideal here since we're excited about it and people will be looking for examples of it 👍🏻
Co-Authored-By: Nate Moore <[email protected]>
This is looking great! Followed up with Chris offline to dig into the background images and perf testing, notes below
|
Changes
This is a more fully featured example than some of our more basic starters, so closer to a real “theme”. I think that was the general idea with this, so hopefully that’s OK. The starter does not include any dependencies apart from
astro
but does add some custom components including an<Icon>
that contains the icons Mark suggested from the Phosphor icon set.Try it on StackBlitz →
Questions
The original design used Public Sans for body text. I’ve stuck with this for now, but is there an argument for dropping Public in favour of a system font? Public is a fairly similar sans to the default sans-serif bundled on most devices and we’re already loading Rubik as a custom font for headings.
Should this be our first full example that uses Content Collections? This example already includes a type for frontmatter and suffers from the style bleed issue when globbing projects for the homepage/work index, so could make sense to set those up a schema?
There is some complexity getting all the background gradient images to work nicely, including multiple resolutions per background and some custom lazy loading for below the fold backgrounds. Is this too much complexity for a theme like this? Maybe there’s some alternative design approach that is lighter and we use background images just for the page headers.
To-do
astro check
errors in CI — will clean those upLight mode
Dark mode
Testing
Docs
We don’t generally document much for these, so guess we stick to that pattern? The screenshot on astro.new will need updating.