evermade / swiss Goto Github PK
View Code? Open in Web Editor NEWThe previous bestest WordPress theme.
Home Page: https://www.evermade.fi
License: Other
The previous bestest WordPress theme.
Home Page: https://www.evermade.fi
License: Other
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.
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?
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.
Our clients should have more options to add variance to blog posts and WYSIWYG content in general.
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.
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
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.
All of our sites should be navigatable without any mouse, touch or cursor device.
No current position on the page is shown when navigating with Tab key.
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:
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.
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/
There are currently nine normal files that have executable bits even though they are not required by any means.
Files that don't need to be executed must not have x
bits set via chmod
.
Following files that don't need to be executed have x
bits set via chmod
:
Remove incorrect executable bits.
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.
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.
Scheme only colors links in paragraphs and text in lists, paragraphs and <span>
s.
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.
Remove element specific selectors from _scheme-html.scss.
Section block should not have margin-top
added to it in the ACF blocks field, if it's the first block in order.
margin-top
gets added even if Section is first.
Add a not
clause to the selector to avoid the hidden acf clone fields.
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.
In a relatively fresh project the Sass compiling can take over 7 seconds.
Comment out the Font Awesome imports and see how it affects the compiling time.
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.
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.
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?
Should we have the block specific styles per block (in their own repos) or in theme?
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.
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.
Tried to add a simple fallback archive views to a project with a full tag list in the sidebar.
Change to get_tags()
function. Will require some changes to the markup as well.
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.
Including the wysiwyg-html mixin would add styling to regular WYSIWYG editor's output elements and leave it at that.
wysiwyg-html mixin includes basic WYSIWYG styles, and also sets element position to relative.
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.
Remove position:relative from the wysiwyg-html mixin, and provide it in other ways if necessary.
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.
Swiss would provide some way to define a logo image that would be used in the default nav(s) and footer.
Changing the logo needs a developer to collaborate with a designer.
Just a proposal to set basic ::after
clearfix into its own mixin.
Clearfixes should be standardized and reused.
Clearfixes are rewritten in every place where they are needed.
I was confused when I learned that there currently is no clearfix mixin.
Refer to the PR following.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.