I have a problem with the way the Mac menu is always at the top of the screen, detached from the app.
I can see the reasoning, it’s a good idea to make sure the menu is in a standard, predictable place for all apps. But, that all falls to pieces when you’ve got a massive screen (like an iMac, or a large monitor like I have), and you’re using floating windows.
In the screenshot below you can see I’ve got 2 PHPStorm project windows open. I’m using the VCS controls in the menu to update one of them. But which one?
See how this can be confusing? The top menu shows options for the project window in focus – but when you’re skipping between windows, are you definitely sure you’re editing the right menu? Continue reading I think Mac should abandon the menu bar at the top of the screen
I’ve been given a Mac from work, which is great, but I’ve needed to get back into the habit of its weird quirks again after using Windows again for a while. Some of the ways Mac does things seem so strange when coming from Windows. Here’s a few things I wish Mac did/had. Continue reading I wish on a Mac…
The world of command line tools is still alien to me, even though I use a terminal every day. And it annoys the crap out of me for being deliberately weird. Continue reading There’s a word in computing for saving something, & that word is “save” – except in nano, obviously
Having a persistent taskbar where you can launch applications with a click of a mouse button is such a good idea, that all Desktop operating systems seem to have one, which is great!
On Windows it runs the full width of the bottom of the screen, and in Mac (on every version I’ve used at least) it does the same, but aligns to the center. Continue reading The taskbar in Windows 7-10 is so much better than on Mac
I know many people find CSS quite difficult, and often I see this gif shared as an example of how people work with CSS:
But if you’re doing CSS like this, YOU’RE DOING IT WRONG! CSS isn’t that difficult, but sometimes the chosen syntax does make me WTF. Here’s some examples of that:
Sometimes you need a comma to differentiate multiple values, like:
transition: color 200ms, background 200s;
But sometimes not:
transform: translateX(-50%) translateY(-50%);
Why isn’t this consistent?!
Slashes in shorthand
Ever seen this?
font: 12px/18px "Lucida Grande", sans-serif;
The first 2 values are shorthand for font-size and line-height. Why they’re separated with a slash though seems unusual as I’ve not seen that used anywhere else.
Apart from you can apparently use it in border-radius (here’s an article explaining that) to separate horizontal and vertical axis, but again – that’s inconsistent to how we do it elsewhere!
Camel Case or hyphen?
CSS has always been hyphenated, for example background-color, text-transform etc, so why did we start adding camelcase like translateY, rotateX? It’s inconsistent!
Edit – Also, overflow-y and translateY – Y so different?
Vertical Percentages are Relative to Container Width, Not Height
I didn’t actually realise this for a long time. It can be really useful once you know what it’s doing. Here’s an article about it. But why can’t I also set a height based on a percentage of the container’s height?
Although an improvement on 8, because you don’t have to horizontally scroll, Windows 10’s start menu is ridiculous and full of nonsense. Continue reading Windows 10’s start menu is full of nonsense
Yesterday I was given a task to replace the logos on 5 websites. Something that should have been a quick and simple task. But here’s the steps I had to go through for each website: Continue reading Editing websites has never been more time-consuming
I was recently sent a form through the post to complete. Yes an actual paper form, like from Victorian times!
Annoyed already that I had to do this on paper with a pen, and without handy browser autocomplete, the first thing the form asked really annoyed me. Continue reading Paper forms that annoy me
At work we’re building our latest software product using ReactJS, and have chosen to do the frontend styles a little differently to what I’m used to, using “local styles” which is a way to modularise your CSS.
But I’m on the fence about local styles (if you’re not sure what I mean, here’s an article explaining the methodology).
Sometimes doing it that way is useful, but sometimes time consuming for not much benefit. So here’s a few opinions now I’ve had some time to work with it for a good few weeks.
Good things about local styles in ReactJS
- You can copy a component from one project to another and it’ll have all the styles that’s associated with it. Not that I think this is something we’ll ever do, because every project will probably have a new design.
- Forces you to put all styles associated with the component in the same place. This includes media queries, including print styles. Although this might get a bit cumbersome when styling other ways a component is displayed, like different coloured themeing, or when exported for PDF.
- The classnames will be abstracted when the project is built, so they’ll be super small. Not bulky long BEM names like “header-wrapper__options-wrapper”. For example that’ll probably be compiled to “jk34a” or something even tinier, but still have the correct styles applied.
- It frees up the global namespace. So you can use classnames like “options” or “list” without fear you’ll inherit styles from elsewhere.
- You can use SCSS. Everyone should be using SCSS though, because it’s awesome.
- CSS is inserted inline at the top of the document which saves the user having to download separate files. It’s messy, but reducing the number of files to download is great for speed.
Bad things about local styles in ReactJS
- Difficult to bake Bootstrap into the project. I like to work by @extending parts of bootstrap into styles, to save having to write things over and over. It makes it much more DRY. But the way our project works (and this could just be down to our implementation) I can’t easily extend Bootstrap’s useful classes, instead having to recreate them, which is annoying and less DRY.
- You have to import everything. Each component has a list of files it imports at the top, which is great to be specific, but also dead time-consuming when you have to do it over and over and over. Using relative paths too, which takes waaay too long to find where you need to import from the current file’s location. Also that makes me really worried for if we ever need to change something’s path.
- You have to write “className=” instead of “class=”. This isn’t much of a problem but really irritates me and warps my brain. I’ve started writing “className” in other projects accidentally!
- Some react components use global styles, and that ruins our attempt to keep it local. We use the react-bootstrap library which does everything with global styles. Which means we have to write :global in a local style. Seems to defeat the purpose!
- Because the css is inserted inline, it’s difficult to find and look at the generated styles. SCSS is great, but sometimes you need to look at what it’s doing to make sure it’s not generating something incredibly long. At jQuery conf, @MDO said he accidentally generated an unnecessary 1000 lines of css just through making 1 change in the SCSS, and I want to make sure I don’t do the same!
- The CSS isn’t cascading, or a sheet, so we should rename it from css to just “s”. So because of the way local styles work, they’re all individual blocks of styles, so don’t cascade. And because it’s all inserted inline, it’s not a sheet either.
One of my biggest struggles is keeping it DRY, even though everything is modularised. You can do this by @extending common shared styles. For example we have 2 separate components that need a circular green icon with an arrow. What I’d normally do in this case is create base styles for it, and extend it in both components. Local styles still allows us to do this, but it defeats one of the main purposes, which is to keep all styles for a component contained within.