Its not as rigid as software design patterns, and I think that's by design.
I'll try to share some tips - hopefully this is the kinda thing you're after - i recognize some of it might not be on topic.
* use html partials to reduce complexity
* think about cachability and rendering needs - sometimes a simple display feature can have huge ramifications on code required and complexity
* semantic markup is optional, but definetly helps break up a sea of divs, and is good for people who use screen readers
* decouple your HTML from your CSS - if something is to be blue or big, it should be from the CSS, not because it has a "big" or 'blue" class. (see: csszengarden.com)
* scss & co are really useful, but be careful to not go overboard.
* don't assume what fonts your users have - linux, mac, win all differ. if unsure, check all 3 platforms rendering
* load JS at the bottom of the page to prevent render blocking (vs. in the head)
* always test browser size reflow & zoom rendering
* always test css,html, js validations
* test design in grayscale/color blindness simulations
* be aware of browser compatibility and vendor prefixing needs - its not cookie cutter.
* flexbox is new on the block, but it's dreamy to work with and is great for layout (shoutout to flexboxin5.com for helping me)
* code comments, such as those that highlight return values, or why something is X, are hugely helpful
* check for unused CSS - there are a number of scripts/browser extensions/sites that can tell you what CSS is never used, and help you remove it.
* same for JS - make sure you still need / use it all
* html/css is rarely (for me) polished at first pass. Iteration is instrumental at arriving to clean, maintainable code.
>semantic markup is optional, but definetly helps break up a sea of divs, and is good for people who use screen readers
Amen for the "optional" part.
Designers who don't really understand programming, reusability etc had this fad in the mid-2000s were they made "semanticness" some kind of holy grail, as if an html pages were meant to be data abstraction/interchange formats.
I definitely fell victim to this - I would still aim to be as semantic to the data as possible but don't lose much time/sleep over it - especially when the last point has been very true in my experience.
I'll try to share some tips - hopefully this is the kinda thing you're after - i recognize some of it might not be on topic.
* use html partials to reduce complexity
* think about cachability and rendering needs - sometimes a simple display feature can have huge ramifications on code required and complexity
* semantic markup is optional, but definetly helps break up a sea of divs, and is good for people who use screen readers
* decouple your HTML from your CSS - if something is to be blue or big, it should be from the CSS, not because it has a "big" or 'blue" class. (see: csszengarden.com)
* scss & co are really useful, but be careful to not go overboard.
* don't assume what fonts your users have - linux, mac, win all differ. if unsure, check all 3 platforms rendering
* load JS at the bottom of the page to prevent render blocking (vs. in the head)
* always test browser size reflow & zoom rendering
* always test css,html, js validations
* test design in grayscale/color blindness simulations
* be aware of browser compatibility and vendor prefixing needs - its not cookie cutter.
* flexbox is new on the block, but it's dreamy to work with and is great for layout (shoutout to flexboxin5.com for helping me)
* code comments, such as those that highlight return values, or why something is X, are hugely helpful
* check for unused CSS - there are a number of scripts/browser extensions/sites that can tell you what CSS is never used, and help you remove it.
* same for JS - make sure you still need / use it all
* html/css is rarely (for me) polished at first pass. Iteration is instrumental at arriving to clean, maintainable code.