We will need a some kind of solution for defining focal point for images. Something like this:
https://designshack.net/articles/mobile/focal-point-intelligent-cropping-of-responsive-images/

WordPress nowadays automatically creates the dns-prefetch tags based on what scrips and styles have been enqueued. Remove the manual ones we have in header.php.

As this repo is part of a larger entity ie the project, the build tools are not included here, so lets add a section to the readme to help this for now. We could even include a simple Webpack config to handle the CSS and JS.

Page sharing icons classes need to be changed from fa to fab to support Font Awesome 5. Only applies to the social media platform icons, email icon should be left as it is.

Expected Behavior

The blog sidebar Tags widget should show all non-empty tags available on the site. You can receive a list of them by using the get_tags() function.

Current Behavior

Currently it uses the get_the_tag_list() function which only shows the tags of the first post in the current loop. From the Codex:

Generates a HTML string of the tags associated with the current post.

Steps to Reproduce

1. Add different tags to various posts
2. Go to any archive feed sidebar
3. It shows only tags from the first post in the current view

Context (Environment)

Tried to add a simple fallback archive views to a project with a full tag list in the sidebar.

Possible Solution

Change to get_tags() function. Will require some changes to the markup as well.

Just a proposal to set basic ::after clearfix into its own mixin.

Expected Behavior

Clearfixes should be standardized and reused.

Current Behavior

Clearfixes are rewritten in every place where they are needed.

Context (Environment)

I was confused when I learned that there currently is no clearfix mixin.

Possible Solution

Refer to the PR following.

Should we have the block specific styles per block (in their own repos) or in theme?

I have created a wee proposal Codepen to open a discussion on this as its an ever growing issue that we should make consistent and robust.

https://codepen.io/onefastsnail/pen/RLYLKM

Disclaimer: Ignore the naming 👎

Thoughts?

Designers and other good folk tend to occasionally prototype sites with just the bare Swiss site and basic blocks, but changing the logo to a client logo currently requires collaboration with a developer.

Expected Behavior

Swiss would provide some way to define a logo image that would be used in the default nav(s) and footer.

Current Behavior

Changing the logo needs a developer to collaborate with a designer.

Currently in our base styles (_base.scss) there is a global property outline: none; that disables all outlines on every element and pseudo-element. And yet we are not providing any alternatives to it.

I suggest that as a first step we remove that property and by doing that improve accessibility of our future sites a lot. The outline styles can of course be styled per-project basis, but that is often forgotten if no outline is visible in the first place.

Expected Behavior

All of our sites should be navigatable without any mouse, touch or cursor device.

Current Behavior

No current position on the page is shown when navigating with Tab key.

Steps to Reproduce

1. Go to any site with outlines disabled.
2. Press Tab key as many times as you like.

Context (Environment)

It's widely considered as a Bad Thing™ to disable outlines without providing an alternative. They can be styled or removed, but on every meaningful link or interactive element, there should be clear sign of the currently focused element.

Refer for example to:

• The A11Y Project: Never remove CSS outlines
• a { outline: none; } DON'T DO IT!

There are currently nine normal files that have executable bits even though they are not required by any means.

Expected Behavior

Files that don't need to be executed must not have x bits set via chmod.

Current Behavior

Following files that don't need to be executed have x bits set via chmod:

• acf-json/group_54ddebcd1dfe7.json
• acf-json/group_5527a7de81584.json
• acf-json/group_58f9cbd4a16b3.json
• acf-json/index.php
• assets/js/main.js
• assets/js/plugins.js
• index.php
• page-basic.php
• single.php

Possible Solution

Remove incorrect executable bits.

Expected Behavior

The Sass compiling should be fast enough that you don't have to wait for your changes. Max. wait time of 2-3 seconds would be good, less the better.

Current Behavior

In a relatively fresh project the Sass compiling can take over 7 seconds.

Steps to Reproduce

Comment out the Font Awesome imports and see how it affects the compiling time.

Context (Environment)

Sass compiling in a reasonably fresh Swiss install takes a very long time (over 7 seconds). The main culprit seems to be the Font Awesome 5 library.

Possible Solution

Use CDN instead, see if there's a way to use the Sass variables still, or do we need to remove the font-icon mixin again.

In the current state text colors of the schemes are only applied on p, ul, li and span elements. This causes elements not included here not to inherit the right coloring.

Expected behavior

When the scheme is applied to an element using scheme-html derivatives such as scheme-html-default, the text and link coloring should be set equally for all elements, including but not limited to plain <div>s, tables, description lists, figures and preformatted texts.

Current behavior

Scheme only colors links in paragraphs and text in lists, paragraphs and <span>s.

Context (Environment)

Scheming should work anywhere. It shouldn't matter what elements you are using in your actual code. By specifying text colors in more general level, we also ease debugging of our components' coloring. Also text-color related features as for example currentColor work more reliably.

Possible solution

Remove element specific selectors from _scheme-html.scss.

Currently the wysiwyg-html mixin violates the principle of least surprise by setting the position-property to 'relative', even though the name of the mixin suggests that it would only provide base styling for WordPress (or equivalent) WYSIWYG editor styles.

This can lead to unnecessary debugging and/or requires one to explicitly reset styles that you're setting with wysiwyg-html(), if relative positoning is not what you are after.

Expected Behavior

Including the wysiwyg-html mixin would add styling to regular WYSIWYG editor's output elements and leave it at that.

Current Behavior

wysiwyg-html mixin includes basic WYSIWYG styles, and also sets element position to relative.

Steps to Reproduce

1. @include wysiwyg-html();

Context (Environment)

When reading swiss-based SCSS, it is not immediately obvious that the wysiwyg-html mixin would change the position of an element, as the name only suggests that it would only affect WYSIWYG element styles.

Possible Solution

Remove position:relative from the wysiwyg-html mixin, and provide it in other ways if necessary.

Expected Behavior

Section block should not have margin-top added to it in the ACF blocks field, if it's the first block in order.

Current Behavior

margin-top gets added even if Section is first.

Steps to Reproduce

1. Add a section block as the first block
2. Enjoy :)

Possible Solution

Add a not clause to the selector to avoid the hidden acf clone fields.

Even though our blocks are now defined in PHP, we are still using JSON in Swiss for the other ACF field groups (website options and default post blocks). I kiiiinda would enjoy if I could stop worrying about the JSON files completely, and just have one way to define all ACF field groups (through PHP, that is).

While using JSON rarely causes headaches anymore, there are still times every now and again when you have to do some thinking due to them (and I'd rather not do that if I can have a system that makes it redundant instead).

Note that I didn't list the "Block development" field group JSON above, as I believe that it's a handy default for using the GUI to build out fields and field groups initially, and I would not want to drop that just because.

Are there any specific reasons why we wouldn't do this? Do people agree or disagree with such an approach in general?

Expected Behavior

Our clients should have more options to add variance to blog posts and WYSIWYG content in general.

Current Behavior

Currently clients are unable to use the different lead text styles without going into the code editor. They should be able to easily add the text-lg class to paragraphs to create lead texts.

Possible Solution

One approach is to always style lower priority headings to work as a lead text, but that is a bit difficult for clients to remember how to use.

I would add at least one "Lead text" format style to the TinyMCE format dropdown, that creates a <p> tag with the text-lg class.

https://gist.github.com/psorensen/ab45d9408be658b6f90dfeabf1c9f4e6