A really like Eric's latest redesign. I'm a huge fan of ink drawings in general, so it figures I'd like this, but more than the graphic elements I feel like the layout manages to strike a great balance of feeling refreshingly different and yet immediately obvious, particularly on desktop. Snooping the source code shows that there's some clever CSS grid wizardry going on here with negative column/row indices that I'll definitely want to remember 🕵️♂️
An in-progress project looking to create a CSS reset that creates modern defaults, rather than just focusing on standardising behaviour across browsers or removing irritating legacy features in browser user agent stylesheets.
You, however, don't have to stay in the past. You can override the UA styles with more modern ideas of how CSS should work by default. Introducing CSS Remedy.
User experience, even over developer experience.
Jeremy has some solid thoughts on what makes a good design principle. In brief, it should be a little provocative and not automatically achievable; it needs to be something to actually drives behaviour and guides decision making, rather than being bland, boring, and already achieved. Something like that initial statement, which I agree should be a fairly universal principle. I also agree with his follow up:
Sadly, I think the current state of “modern” web development reverses that principle. Developer efficiency is prized above all else. Like I said, that would be absolutely fine if we’re talking about technologies that only developers are exposed to, but as soon as we’re talking about shipping those technologies over the network to end users, it’s negligent to continue to prioritise the developer experience.
A simple idea: collate all your feeds (RSS, ATOM, MF2, whatever) into one place. Marcus suggests a pattern of using the
/feeds page (his is here). There have been some valid discussions on the IndieWeb slack about whether an English-language specific pattern is ideal, but overall I feel like it's a positive step until something better comes along. Personally I'd be interested in expanding on the idea and also having silo feeds (Twitter, Instagram etc.) linked on that page too, a little like Marcus does with Mastodon.
A collection of hyper-optimised SVG logos for social media, popular websites, and tech companies. Every logo, whether in PNG or SVG form, is less than 1kb in size and have a base scale of 512px.
Solid reasoning – with a clear example – of the potential dangers of using an array index as the
key value in ReactJS. Not something I'd ever considered (and something I do a lot) but makes sense.
I think there's some real merit to Andy's ideas behind Cube CSS. It's a middle-ground between everything-in-JS or BEM that throw out the cascade entirely and the free-for-all that can happen if you don't have any structure at all. That makes it flexible and scalable. It also feels a lot more like a pace layer approach.
Sure, in the old days of Internet Explorer, the cascade was a bit tricky, but using old knowledge and techniques as the base of a modern approach is like feeding horse feed to a car.
- Composition. These are classes which define the foundational layout, the content skeleton if you will. I imagine this being your grid and flexbox classes.
- Utility. Largely these are just utility classes (
.centreetc.). They do "one thing, and do it well". Makes sense. Not sure I'm a fan of the use of colours as utility glasses; I'd rather use variables for that. In fact, personally I feel like CSS variables are a form of utility class, so would group those two together.
- Block. Pretty much how it is in BEM, a block == a component. Ideally you have very little of these; how you specifically deal with sub-rules is up to you.
- Exception. Exceptions make use of
data-attributes. I like that a lot. They let you manipulate blocks, reversing card order (for example) or highlighting a specific card, and they don't leave you fighting the cascade too much.
I didn't know you could use square brackets within the
class attribute, which is suggested for ordering classes into "primary block", "blocks", and "utility" segments:
class="[ card ] [ section box ] [ bg-case color-primary ]"
Pipes are also acceptable and useful.
I feel like CUBE CSS neatly fits into a model I've been thinking about a lot recently. I've found my approach to using big stylesheets in React more frustrating over time, whilst I really like lumping component-specific styles into, well, the component. I prefer CSS modules, but CSS-in-JS achieves the same thing. The problem is, if that's all you do you end up with repetition and inconsistency. With Growable, we used a combination of CSS modules and a
global.css stylesheet which struck a good balance but still felt like it could be better optimised. I think CUBE CSS maybe hits on a method to achieve that optimisation. I'd be intrigued to give it a go.
There's been a lot of chatter about Spinosaurus recently, thanks to the new revelations about its tail morphology, but I think Mark has put together the best overall argument for what the new papers tell us and what that means for reconstructions. Also, as ever, he's created an amazing illustration. In brief (and with the caveat of as the evidence currently suggests):
- Bipedalism looks likely to be the main form of locomotion, based both on tail weighting and position/size of neck and hindlimb musculature;
- How – or if – Spinosaurus swam is still unclear and the new tail doesn't necessarily help with objections based on buoyancy modelling, but these calculations should be redone. Basically, it's still really weird and unlike anything extant, so we can't really make definitive claims;
- The sail is basically confusing. Depending on what fossils you prioritise, it could be S-shaped or C-shaped or somewhere in between the two. This is muddied by the question of whether the new specimen is a distinct species from the holotype or not;
- Mark has revised his earlier misgivings around tail flexion, particularly as to whether it could be used in a sculling motion like newts or crocodilians do. It looks like the neural spines are thin enough to both withstand and forgive the level of flex required, so they wouldn't snap or overpower musculature. That said, there's still some debate here as the paper itself claims a minimal tail musculature, so perhaps it was more rigid than implied;
- Lips are still very viable and there is little evidence to suggest the jaws were much more specialised than other theropods.
In short, we don't know a lot, but we know a little more than we did. I still like the idea of Spinosaurus as a Cretaceous mega-heron though 😁
At the start of the pandemic, Eric made a strong case that all critical websites needed to rapidly optimise for high traffic and accessibility (here very much meaning both a11y and device/situation inclusion). I keep returning to it in my mind so wanted to note it here. Eric was specifically calling out sites for public health, government services, etc. – the social infrastructure that happens to live online – but it's universally relevant advice.
As much as you possibly can, get it down to static HTML and CSS and maybe a tiny bit of enhancing JS, and pare away every byte you can. Because too many sites are already crashing because their CMSes can’t keep up with the traffic surges. And too many sites are using dynamic frameworks that drain mobile batteries and shut out people with older browsers. That’s annoying and counter-productive in the best of times, but right now, it’s unacceptable.
Apparently, there has been a discussion around whether the term "user" is in some way derogatory. I must say I don't get it, but I do agree with Heydon: if there is a better, more descriptive, more accurate, or more meaningful word – such as contributor or team member – then use it. Otherwise, "user" will do just fine:
But where we have to use the term person to remind ourselves that the person using our product is more than just a user of our product, that says more about the arrogance with which we approach product design than any tokenistic attempts at sounding humane can ever make up for.
The term user is fine, just don’t sell meth.
(bold emphasis mine)
Sound has definitely been abused on the web, but I agree with Josh that it shouldn't be ignored completely. There is still a time and place for using sound to great effect.
However, I believe that this is the bathwater around a baby very much worth saving. Sounds can accentuate user actions, emphasize feedback, and add a bit of delight to an otherwise humdrum action. When done tastefully, sound can make a product feel more tangible and real.
Josh has put together a simple React Hook that lets you trigger sounds using basic browser events. He also discusses some use cases and potential issues. For example, deaf users clearly won't hear it, so sounds should always be mirrored by visual cues as well. Similarly, sounds can be annoying for screen readers, so a mute option must be present.
It's a shame to see the "classical" sail-trees of Furaha are no longer making the reality-check cut, but the reasoning is (as always) fascinating:
- Leaf size is as much a result of humidity and temperature as it is photosynthesis (hence why we don't see giant, solar-panel like leaf "sheets";
- Leaves are good at reflecting infrared light so don't warm up too much, but they still have to cope with the fact the Terran photosynthesis begins to degrade above 26°C;
- In theory, that means warm climate plants should have smaller leaves, but that isn't true (it's inverted, actually). That's because plants have heat-regulating patterns, like lobed (wavy) edges that help and by effectively sweating. Hence, humid-region plants with wavy leaves are the best at growing big and flat;
- However, if leaves get too cold, they can freeze (particularly if they contain lots of water for "sweating") so in cold regions leaves have strategies to stay warm too, such as (you guessed it) being small and having lots of leaves instead of investing energy into less big ones;
- Leaves also have strategies for dealing with wind, including being able to curl into aerodynamic shapes, both individually and as branch-clusters;
Unfortunately, that means sail leaves would be easily broken in high winds, and could only exist in areas of high humidity with low-temperature variability. That's not impossible, but it's so unlikely (and a bit boring) to not work on Furaha.