lowerbarriers / finished-starter Goto Github PK

Tables appear throughout the codebase. Each table should be wrapped in a div that arrows it to horizontally scroll once the viewport is narrow enough to require it (1024px perhaps).

The _includes/atoms directory has at least 4 components. The documentation is included within each component, with one piece of it being notes on the accessible use of the components.

Acceptance criteria:

1. Changes/improvements to the accessibility notes in the docblocks
2. Citations/links to external sources backing up the notes
3. Notes in valid/pretty markdown

Describe the bug
When I visit the site as a user and run lighthouse tests against any page, the "Best Practices" section shows a warning about a deprecated, prefixed CSS declaration:

::-webkit-details-marker pseudo element selector is deprecated. Please use ::marker instead. See https://chromestatus.com/feature/6730096436051968 for more details.

Request to remove that line, as the standards-compliant declaration is right underneath it, working already.

Along with fixing the warning in Lighthouse, the fix should also marginally improve CSS payload size.

Sites at the domain/subdomain root need not explicitly declare their favicon and apple-touch-icon paths, since browsers and other user agents will automatically make HTTP calls to domain.tld/favicon.ico and domain.tld/apple-touch-icon.png . For sites hosted at a path, though, the domain favicon and apple-touch-icon may not be desired or present.

Acceptance criteria:

• The site's favicon and apple-touch-icon work, even when hosted at a path
• Other things, like the service-worker script, are also assessed to ensure they're included with qualified-enough paths

The content of the site is presently a mix of the Shelby & Brad wedding site, Brad's personal site, and some small amount of starter-kit customizations. Let's make it fully generic, with the content itself being something of a guide for what site-specific content should be inserted in that place and why.

Acceptance criteria:

• Site content no longer mentions Brad or his wedding
• Imagery is present, royalty-free, and generic enough to leave in place

Web monetization is a popular meta tag thing to put on new sites. Let's add it so we can say we support it.

What exactly should the enhancement be?

https://web.dev/content-visibility/

This is a one-liner CSS directive like font-display: swap; that tells the browser to render in a performant way that's not necessarily in line with expected behavior. Let's try it out and see how it changes front-end performance.

What exactly should the enhancement be?

Review the following well-known style guides and component libraries:

• https://getbootstrap.com/docs/4.0/components/forms/
• https://material.io/components/cards/#specs
• https://www.carbondesignsystem.com/components/notification/usage/
• http://codeforamerica.clearleft.com/
• https://www.patternfly.org/v4/design-guidelines/content/voice-and-tone
• http://ux.mailchimp.com/patterns/tables
• https://designsystem.digital.gov/components/button/
• https://github.com/uswds/uswds-site
• https://components.designsystem.digital.gov/
• https://tailwindui.com/components
• https://nostyle.herokuapp.com/components/autocomplete

...and cross-reference against the current finished-starter codebase, creating issues when the other systems have viable components or documentation that mesh with this project philosophically.

Why should this be an enhancement to this project rather than the userspace?

@todo remove this question from the template. This is a monorepo, so we're not going to put junk in the userspace.

What other projects have similar functionality or content? What makes these implementations cool?

That's literally what this ticket is about.

Who benefits from this enhancement?

Developers, end users, other ancillary folks who need components and good docs.

What documentation needs follow from this enhancement?

Whichever documentation is found to be good from those other projects. We might want to ensure credit is given in humans.txt

Is backwards-compatibility a concern?

Shouldn't be. Let's not write a lot of compatibility-breaking code.

Is additional test coverage required?

Eventually. That's a bad answer but I'm okay with it.

Are you willing to try and create the enhancement yourself as a contributor?

Yes, if nobody else jumps on it.

What exactly should the enhancement be?

This is the last feature promised in the readme that doesn't have even a partial implementation yet, making it a pretty high priority.

The idea would be to write BDD-style user stories in the data or includes directory (whichever makes the most sense for this application, probably data) in a format that the testing suite (which can be a big mess of npm dependencies, unlike other features, since testing would only occur on the locals of advanced users or via a pre-configured automated github action) can parse and run.

Ideally, the stories in the data file and the results could be merged and rendered to a documentation page showing the stories as well as pass/fail for their most recent run.

For this issue to be satisfactorily closed, only one or two basic stories need be written. Upon completion of this issue we'll focus on overall coverage.

What exactly should the enhancement be?

Add a component to includes/forms that allows one or more multi-select form options, such as:

• Checkboxes
• Dropdown
• Checkboxes progressively enhancing to a dropdown
• Other

The component should have a prop that lets you pass in a list of key|value pairs as a delimited string, and output to semantic, accessible HTML. Beyond markup, any style and functionality should be progressive enhancement.

What other projects have similar functionality or content? What makes these implementations cool?

This is a pretty standard element for any form.

Is your feature request related to a problem? Please describe.
In order to reduce cumulative layout shift on the page, images should have initial height and width attributes that give the browser paint a heuristic of intrinsic size and aspect ratio.

Describe the solution you'd like
Since Jekyll does not have a feature for image metadata in its pipeline, a script in .scripts/ run prior to a commit could add image metadata to a yml file in _data/ that could then be accessed by includes and other mechanisms that render image markup.

Describe alternatives you've considered
This was the first viable solution that came to mind, and despite simmering on it for a while, it still seems like the only and most viable way to do it.

Additional context
This has become necessary due to Core Web Vitals. Cumulative Layout Shift is something to optimize for, but image dimensions aren't necessarily a huge win for the effort. But we have to chase 100s in Lighthouse in whichever ways we can.

What exactly should the enhancement be?

Add a component to includes/molecules for displaying a tweet. Ideally, the default state would be a semi-tweet-appearing box containing the tweet contents (perhaps manually entered, perhaps automatically pulled from an API) that asynchronously and progressive enhancedly then renders as an embedded tweet.

The solution can be namespaced as a web component if that provides a benefit, though that is not a strict acceptance requirement.

Is your feature request related to a problem? Please describe.
Lighthouse tests ding the framework for performance under 100% because there's more CLS than allowed by the test suite.

Describe the solution you'd like
I think we need to tighten the content-visibility, asset heuristics, transition properties, and other contributing factors.

Describe alternatives you've considered
One alternative is to be happy with almost-perfect scores.

Additional context
There are other minor diagnostics we could address on this ticket. Not sure how much benefit comes from continually chasing scores over real UX and DX.

What exactly should the enhancement be?

Add support for the next-gen AVIF image format, following the template used for WEBP images.

At the top level of the JavaScript, register a global (or similar) that contains a mapping of classes/selectors to JavaScript partials that should be loaded when that particular class is present in the DOM.

Then, write a partial that gets included in the main bundle that determines if the registered partials have been loaded, and if not, loads them. assets/js/partials/twitter-tweet.js does this for the Twitter embed API JS.

Determine whether the compress layout can be applied to individual partials as well as the main bundle. Similarly, determine if there's a viable way to apply terser to create optimized artifacts. If not to either or both that's okay (it's not an acceptance criteria), but we strive for performance.

Once the registry and the handler script have been added and included, port the following partials (as of this writing) to only load conditionally rather than being in the main bundle:

• docblock.js
• js--copy-above.js
• js--share-to-native.js
• js--youtube.js
• twitter-tweet.js

We'll want to assess whether the youtube and tweet (especially tweet since it chains a third-party script) partials being conditional are too chained for perceived performance.

With any luck this will allow our main JavaScript bundle size to be smaller while not affecting request chaining performance in automated tests. Eventually we can also port the snipcart code to use the same API structure, though that's not explicitly in the scope of this ticket.

What exactly should the enhancement be?

Using something like https://github.com/justinribeiro/lite-youtube but perhaps not using that directly (not invented here, small dependencies are still dependencies), ensure YouTube embeds load quickly, asynchronously, and without tons of overhead or privacy issues.

One available mechanism is the build process. If all YouTube embeds on a particular site were enumerated in a data file before use, they could be listed on a docs page, and the build process could bring in and format the poster image, update the metadata, and so forth.

Determine the feasibility of using the liquid component structure and other benefits of the finished-starter framework from within the Eleventy (11ty) static site generator rather than the current Jekyll setup.

If a port of the functionality and content is possible, use this issue number to create the branch and do the work.

Is your feature request related to a problem? Please describe.

I got a client request (from @MikeSaliba , copied here to provide feedback) to set a forked site to have a coming soon page while the site was being built. This seemed like a pretty common thing, especially when front-loading DNS and other things so that a particular domain has a templated page rather than a customized one.

Describe the solution you'd like

Ideally, a new layout based on default.html but with less nav and other chrome (similar in spirit to a "Landing Page" in email marketing parlance, so maybe this lift can solve two common problems at once) could be added that could be substituted in the home page's front matter could be added. Then, only the page content would need to be tweaked rather than juggling HTML formatting for a static replacement page.

Describe alternatives you've considered

For the client project I used a flat HTML file that isn't processed by Jekyll. This is an ok temporary workaround, but something more durable would be preferable.

Additional context

Coming Soon pages don't tend to allow you to navigate to other site pages, even if those pages are published and available. The default template includes all of the nav and stuff, and doesn't really facilitate that high-focus content.

Describe the bug
Lighthouse logs an error to the console that causes the "Best Practices" section to sporadically report non-100 scores. The issue is related to non-same-origin cache results.

Further reports of this behavior are welcome here.

I have not benchmarked it yet, but it appears the file operations to open and include all the SVG icons directly on the page more than doubles the site's overall build time.

An improved icons documentation page should reduce the Jekyll build time substantially, and should make it just as easy if not easier to find an icon and then copy its liquid embed code. Lazy/indirect SVG loading and JavaScript (conditional?) are valid methods of seeing this improvement in the codebase.

Is your feature request related to a problem? Please describe.
Many starter kits out there can be hosted on GitHub Pages, Vercel, Netlify, etc. CloudFlare Pages is new, and we could get some competitive advantage by mentioning that we've successfully tested it.

Describe the solution you'd like
Just an extra line in the README that mentions the successful test, with a link to a build.

Describe the solution you'd like
By default, the main menu resides within a container that becomes an off-canvas tray on mobile, which can be toggled by a button containing a hamburger icon. This icon and the tray all aesthetically and functionally work with the other buttons and toggles available on the site.

The icon and tray increase page content that appears above the fold on mobile devices, especially the page title hero, which is useful for wayfinding.

What exactly should the enhancement be?

In order to improve the likelihood of products being including in SERPs and the product semantics being useful as microdata, add more schema.org microformatting to product templates.