jbates
commented
5 years ago Definitely do these
I really like the slimmed down gulp file! The one thing I'd like to see is something to make debugging easier with sass (eg. sourcemaps) just to get that in there and standardize debugging for all your developers.
Please add, Candice. :)
Feedback templates: region.html.twig -You have a comment that should be commented out with {# #}.
js: custom.js -You have 'Code for humbergur menu', but it's a general js file (for now).
Please go ahead and fix these bugs.
Please do any or all of these, if you have time.
Suggestions: -Add a preprocess html function in .theme for setting the node id (ideally this would never be used for theming, but as always there's always a situation where a one-off change is needed).
-Depending on your browser support you might want to add x-ua-compatible tags to the preprocess function above.
And better organization of partials, if you're inspired. I liked your suggested structure.
Lately I've been pulling my base styles out into a separate folder, that way once they're set up you know where they are/can easily find them: -sass —-base ——-variables ———-_breakpoints ———-_colors ———-_fonts ——-_accessibility ——-_mixins ——-_typography —-components ——-_example-component
CNDexter
That's next on my list to add. 👍
Thank you for catching those bugs!
These are fixed in real life, this is a duplicate repo and it's a bit behind.
Yes, great suggestion, this is also on the list for adding to the starter theme.
Browser support varies based on particular client data, see below. (Edited to add: I meant to say that I like this idea, also.)
Our main designer doesn't do many mobile comps, so we tend to refine in the browser, based on the content, the needs of the particular project, and the developer's judgment. I tend to want to keep breakpoints as few and simple as possible, and add adjustments only where needed. That said, I think we as a team are weak on our implementation of tablet-ish, in-between widths. In part because our clients sometimes don't have budget to refine those too much. But again, that varies among clients.
If a client has existing Google Analytics, we use the last 3 months of data to help determine what browsers to focus on. Usually, current FF, Chrome, Safari, IE11, and Edge, plus anything else that shows up a decent amount in traffic stats (i.e. IE9, or Android browsers, etc.).
Right now, we've dropped support for IE8 unless specifically asked to support it. That said, I aim for content that can be read and navigation that can be used in IE8, even if ugly, and maybe in a mobile layout. Social media icons that are crisp SVGs in modern browsers maybe fall back to linked text, rather than PNG versions of the icons, for example. So, it's ideally readable and navigable, but very utilitarian.
Even in IE9-10, we say that layouts and design may be simpler (like 2-columns instead of 4, or whatever). If a client has a lot of IE9 users, for example (this happens, I dunno why!), we may give them a simple float layout behind a modernizr class, where modern browsers get flexbox. If I use grid, I have been using it as an enhancement, inside an @supports.
This was rambling, sorry, but the basic idea is that we try to convey to clients that their web design is not going to be pixel perfect identical in every browser, and that's by design, that's the way the web works. I like to talk about layout as an enhancement, with the most modern browsers getting the nicest experience, but older browsers will get a decent enough, readable experience, and we can give them a little more love when there's a use case for it based on stats or internal org knowledge of browser use.
I have been breaking out my own partials into folders on real actual projects, but hadn't standardized a pattern in this starter yet, and I like yours a lot. I would love to establish a pattern for this. Like many humans, I often struggle with how to name or categorize certain kinds of patterns on a real live living breathing site, and I would love to think this through more with someone.
I try to use extends and mixins lightly. I used to swear off extends, but have swung back the other way lately. My mind is open and this is another area I'd love to discuss more in the future, as there are definitely tradeoffs in using Sass abstractions. (For example, I used to nest too deeply, in the early days, ye olden times of Compass, and... yeah I had to learn to chill out on nesting, like we all did!)
I like these, am bookmarking them, thank you!