Rachel Andrew

In 2004 I published the first edition of The CSS Anthology with Sitepoint. The idea for the book was to take the entire CSS 2.1 specification, and come up with 101 examples to show people how to use all of the CSS that existed. I have a copy on my shelf, but recently discovered you can read it on archive.org.

Despite the personal horror of realising that book is old enough to buy alcohol in the USA, it’s fun to look at as a snapshot of a certain point in the history of the web. In 2004 many sites were still laid out with tables, several of the examples explain how to do a certain layout “without tables”. It’s also notable how I refer throughout to specific browser versions, because in 2004 a browser version would last for at least a year and usually much longer. Chrome is about to begin a two-week release cycle, we’ve come a long way.

It’s also interesting how long we had to wait for interoperable, robust ways to achieve some of the solutions. On page 328 I explain how to create coloured scrollbars, using the scrollbar-* that only worked in Internet Explorer. Over 20 years later the scrollbar-color property became Baseline Newly available.

I ultimately published four editions of The CSS Anthology. People still tell me how they learned CSS from that book, something which I find amazing and wonderful. I often wonder what a modern version of that book would look like, and how big it would need to be to attempt to cover all of CSS in 2026!

I had a few days off work last week. My daughter was visiting, and in the evening we sat and watched episodes of Being Gordon Ramsey, a documentary series following the chef as he opens a huge restaurant project in London. It’s an interesting watch, but the thing that comes across through every word and action of Ramsey is how much he cares. He cares about the food, the experience, his family, the young chefs he mentors, and the friends he has made during his long career. The tiny things matter as much as the big ones, and fixing them is important. His high standards apply to himself and everyone around him, because it all deeply matters to him.

Yesterday I saw the following post on Bluesky, and my mind immediately linked it to my thoughts around Ramsey’s documentary.

Claude Design unlocks the project manager’s dream of making the button bigger without pushback. Half of your design team will be fired in a month, the design system and branding guidelines thrown in the trash, and the App Store ratings down one or two points in a few months time.— Jae (@jaehanley.social) April 20, 2026 at 5:12 AM

Before generative AI became a thing, many of the roles that support software engineering could be described as things engineers don’t like doing. There are, of course, plenty of engineers who recognise the skill and craft of people like technical writers and designers, however I’ve also met a large number who see us as people who do the lower value work. Work that engineers absolutely could do, but it’s not worth their time. I’ve seen this very clearly in the way I’m treated as a writer, over how I was treated as a developer.

Now we have generative AI, which can also do this work. To a person who doesn’t care about the craft, some generated documentation or design elements are exactly the same as those handed over by a writer or designer. Someone, or something, else has done the work. However, machines don’t care.

Design systems and editorial style guides need people who care. They need people who care about the small details, who obsess over consistency. They need people who are willing to push back, and who are happy to say no to the endless requests to ignore the guidelines just this one time. Yes, we’re sometimes very annoying to people who just want to ship the app or publish their blog post, but we know that consistency matters. The problem for us is that it’s very difficult to demonstrate the impact of it until it’s gone. Even then, people may not connect the fact that support requests have gone up with poor quality documentation, or poor reviews with an unintuitive UI.

I don’t think this problem is exclusive to these roles. Tech is full of people who care deeply about their area of chosen specialism, and we’re all struggling in a world where doing lots of stuff really fast has become the most important thing.

It’s unlikely that our industry can close the door on generative AI, and I think there is a place for tooling of all kinds in helping to speed up and remove toil from production. However, if those tools aren’t under the control of experts who care deeply about the end result, what you end up with is slop. It’s why I believe strongly that AI-led content operations must be owned by writers. There has to be someone who cares enough to push back, with the experience and organisational power to argue for quality over speed when it matters.

Returning to Gordon Ramsey, the other thing I noted from watching his documentary was how his approach and deep level of care was replicated by his entire team. You might think that perhaps it’s because they are afraid of him, given his sweary Kitchen Nightmares persona. However, the lifelong friendships with people who have worked for him seem to show otherwise. Leaders who care build teams who care, they nurture people who are willing to go the extra mile. Leaders who care develop people who have the confidence to tell others that we need to slow down, fix the issues, comply with the design system or style guide, nail the details, for the benefit of the product and the users.

My social feed has divided mostly into two camps—those who can now only talk about how excited they are about AI, and those who are refusing to use it at all.

I’m somewhat bemused by both of these positions, I see LLMs as a useful tool, in the way that I see spreadsheets as a useful tool. I also think that the people who are advocating the use of AI for everything are wrong in the same way they would be if they told me I should use a spreadsheet for everything. The spreadsheet people do exist, they just aren’t on every screen I look at, and all the software I use hasn’t morphed into a spreadsheet. I don’t think we can or should ignore AI, but overuse of this technology is incredibly wasteful. My (perhaps overly-optimistic) hope is that we can get past the hype and into a place where we understand when, and when not, to use these tools.

In my work there are a couple of classes of things I want to use an LLM for. They typically involve things that are very difficult to automate in other ways due to the unstructured nature of the source material. I’ve had a lot of success, for example, in using AI to identify where documentation has drifted from the product. When you work on a web browser, just keeping track of what has changed where each month is hard.

The first class of things are tasks that would be good to do, but we don’t have people to put on them, they aren’t urgent. A lot of content health work falls into this. Minor updates, identifying screen shots that need changing, small bugfixes for typos, and so on. If an LLM can accurately identify and fix even 50% of these things, and I can put safeguards in place to avoid submitting LLM errors, we’re making an improvement that would not happen otherwise.

The second class of things are those that are really high priority, and need high accuracy, but where there’s a lot of work needed to get the data into shape. You can put a load of people on that work, but they will also miss things and make mistakes, and it’s tedious work that’s seen as low impact. In this scenario you can get an LLM to help you with the first pass over that material, by providing it with a Skill that’s essentially the instructions you would give a person doing the task. It will absolutely make mistakes, which is why this is a first pass. Human reviewers can then take and check that output, using it as a starting point and no more. In this case you need a robust system to ensure the second part happens, that people don’t simply rely on the AI output after seeing some level of accuracy.

I have an inkling that the most valuable people over the next few years will be those with enough experience to discern what to use when, and those with the ability to put into place processes that safeguard codebases, datasets, and people from the potential downsides of these tools.

Last week I spoke at the very lovely Web Day Out in Brighton. My talk was about browser support, based on the work I’ve done over the past almost five years on Baseline. I ran through the various things you need to consider when deciding whether to use features that don’t meet your Baseline target. For example, if you are using Baseline Widely available as a target, how do you decide whether it’s “safe” to use a feature that’s still Baseline Newly available? One of the factors to consider, especially when planning a new project, is what will be part of your Baseline come launch day?

Newly available is the point of interoperability, a feature is part of Baseline the minute the last of the core browsers ships a stable version that includes it. From then the clock starts ticking until 30 months have passed and the feature becomes Baseline Widely available. For most people that’s the point at which they can use the feature without worrying about the fallback experience.

The data behind Baseline is what tells you if something is Newly or Widely available. It also gives you a new power, you can now look into the future of the web platform. If you are planning a project today, what’s the launch date? For a brand new site or application, that might be six months to a year from now. Rather than tying yourself to what’s Widely available today, you can probably include anything that will be Widely available on that date. The same is true of picking a different Baseline target based on a Baseline year. If Baseline 2023 makes sense today, and the new site will launch in nine months to a year, perhaps settle for Baseline 2024. Moving a year forward would give you features like Declarative Shadow DOM, @starting-style, and AVIF.

Whenever I talk about new features in CSS, people immediately ask when it will be available everywhere, or when it will be safe to use. The data gives you a way to understand that, and also to talk about the decisions with stakeholders. I think this is one of the most exciting things to come from this project, as we’ve never had this kind of future-facing view before.

Until recently, if a draft was sent to me by a subject matter expert (SME), it might need significant edits, but I could generally assume the technical content was good. At Chrome, my team of experienced writers has a good pipeline for taking those drafts, shaping them up into readable docs, blog posts, and articles and publishing them. Even when I was in the business of commissioning articles from external sources, there were pretty obvious signs that content was plagiarised, or that the SME wasn’t quite the expert they thought they were. You get a good nose for this over time. Over the last year everything has changed.

There used to be an implicit contract between SME and editor. We receive technically accurate content, and we use our skills in developer communication to ensure the information lands well. In general the questions writers ask are clarifying ones, we’re essentially customer zero for the content, working through the tutorial and ensuring each step is as clear as can be. However, other than obvious typos we could assume the SME knows what they are talking about.

Generative AI has broken that contract. Increasingly writers receive content that looks polished, yet contains inaccuracies. This can be because the SME, while polishing their content using AI tools, has missed the fact that the tool has also modified some code or changed the meaning of text. It can also be that the drive for productivity with these tools has meant that people are being asked to cover broader subject areas, so are relying on AI tools for research rather than their own knowledge. AI can be very confidently wrong, and if the text seems clear, it’s possible to miss that it’s clearly nonsense.

This places a greater burden on the team editing and producing the content. Even with content handed to us from a known SME, we now need to review things with the assumption that they may be wrong. Does that interface really have those methods? Is that diagram inventing a brand new language? Can those quotes be attributed to those people? This relies on having a writing team who also have a level of expertise that allows them to catch these things. It also relies on having enough people in that writing team to deal with the increased workload.

I mention the GitHub flow example, not to take a dig at a fellow writing team, but as something we all need to learn from. I’m thankful that we’ve not had a similar thing happen so far at Chrome, credit is due to my excellent team and the care in which the broader developer relations team are taking as they adopt AI. But things are moving fast, and writers in giant companies are having to work out how to deal with it as much as anyone else. Separately, the back story of that Ars Technica article is wild. 

The problem becomes bigger if you are relying on vendors and external contributors. You can put as many requirements into your contracts as you like, and reject obvious slop, but the level at which you have to treat what comes in as suspect is like nothing we’ve seen before.

If you are doing content operations at scale, it’s your job to put in place processes to deal with this new reality. People will be putting AI generated content through your pipeline. Even if it’s not completely generated, they may be unaware of how much AI polishing has changed their original words. How are you verifying things? The assumptions that were generally true two years ago don’t work now. Even in smaller operations, you can’t just rely on an experienced editor spotting issues, AI has broken much of the internal knowledge I’ve been able to rely on for years.

I’m not anti-AI, I’m increasingly using AI in my content operations pipeline, and will share some of that on this blog in future. However, as with any new technology, there’s the potential for positive and negative impacts. In this case a seemingly positive thing for the SMEs—help in drafting their content—is resulting in additional work for another team. But that’s how change happens, it doesn’t happen all at once, you have to work down the chain of problems, and understand where old patterns are no longer serving you. I imagine that we’ll see more unfortunate things shipped by content teams as we work through this. I’m dreading the point at which it’s my turn to be the person who LGTM’d the slop! We’re in a transitional time though, and I’m encouraged by the amount of discussion I’m seeing from other writers, as we work to redefine how we do content operations in a world of generative AI.

I concluded my 2024 review post by saying that I hoped to make the move back to the North of England in 2025. The event that defined 2025 (other than my 50th birthday!) is that I managed to do just that, and I’m writing this post from a little town in Northumberland, where I’ve been puzzling the other residents for almost six months. Buying and selling houses is an enormous hassle, as is moving three cats a seven hour drive up the country, but it is now done.

On my first recce to plan my move up here, as I drove across the country from Carlisle, the sense of homecoming was almost overwhelming. For years I’d told myself I didn’t really belong anywhere, I’d buried any thought of moving back North as it was never a consideration while I was married. My ex quite vehemently hated the idea, despite the fact we could have bought property so much sooner than we ultimately did. After that first trip up here, early in 2025, there was no doubt that I was coming home, that this is home.

The cats seem happy enough being Northerners, in fact Em (who was so anxious in Bristol she had pulled off a lot of her fur) seems to love it. I’ve been able to wean her off the anti-anxiety medication and she has a nice fluffy tummy again. In reality she’s probably picking up on my reduced anxiety. It’s nice to live life without the almost constant background sound of police sirens, and without the police helicopter over my house most nights.

Fitness

The move up North has also had an impact on my running, I’ve run slightly fewer miles this year, however since the move it’s been mostly on trails and also significantly uphill. It was hard to leave my harbour loopers in Bristol, but I’ve found a friendly bunch of runners here who have been introducing me to the amazing trails on my doorstep. Also on my doorstep is an amazing community-run gym, and I’ve been focusing more on lifting, mobility work and continuing to try and improve the situation with my arm and shoulder. In 2026 I hope to explore more of Northumberland and Cumbria, no big goals, just keeping moving and looking at cool stuff.

Work

In October I passed the four year mark at Google. It’s been a busy year with a lot of change and (of course) a huge focus on AI. As a technical writer and a manager of writers, I’ve had to figure out what AI means for me, but also what it means for my team and for their careers in an industry that is, whether you like it or not, changing.

II dislike hype (this is why I still haven’t seen the first Wicked movie, despite being a huge musicals fan). So when the AI hype kicked off I raised an eyebrow in its general direction, followed a few people who I know to be intelligent and sensible, read their stuff, and delayed forming a strong opinion. I’m not someone who feels compelled to jump on every new shiny thing in tech, and while I’ve probably missed a few opportunities because of this, I’ve also saved myself from wasting a huge amount of time over the years.

Initially, I noticed a lot of people seeing docs as low hanging fruit for AI generation. Notably, the people thinking this weren’t writers, they were engineers who sometimes were forced to write docs, didn’t like doing it, and were thrilled to think they might be able to automate away this annoying task. There’s a huge difference however, between AI used to automate something you don’t appreciate or fully understand, and AI tools used appropriately by people with real knowledge of what they are trying to do. Over the last few months I’ve been part of an internal “AI for Authors” group, Google technical writers figuring out together how best to take advantage of these new tools. At the end of 2026, I presented a short talk at AI the Docs in Paris about the initiative. I’d like to write more about this, but as a taste of the sort of things we’re doing, check out Allison Hodsdon’s series on Gemini CLI for Authors for lots of practical ideas.

There’s also been a lot of work travel. According to Tripit I traveled 71595 miles, spending 70 days on the road, visiting 27 cities in 7 countries. Less travel than I used to do, but more than I want to do. In 2025, I switched my airline status from British Airways to KLM. This was partly because my home airport is now Newcastle, and Heathrow is a fine enough airport to start and end travel in, a horrible one to connect through. Schiphol is the opposite, the queues can be a nightmare when starting or ending a journey there, but as a transit hub it’s great. It’s been fun to explore new routes, and connect through new airports.

I don’t expect to do a lot of speaking at events next year, I’ve agreed to a couple of UK-based things, and it’s likely that anything I do will be relatively close to home. There’s other long haul work travel I’ll need to do, so I can’t justify long trips for events like I used to. I do find the conversations that I have at events important though, they spur new ideas or give me insights into the community, so I’m not going to vanish from public speaking completely.

Other things

The move, preparing my Bristol house for sale, packing, and all the related admin has taken up a lot of this year. In my new house I have a garage, which I immediately kitted out as a workshop. It’s exciting to have a place for my tools, and to be able to leave things set up if I need to stop doing something partway through. I still have decorating in the new house to do, and flooring to lay upstairs, but I’m hoping to improve my carpentry skills in 2026. My ultimate aim is to find the house I intend to stay in up here, probably something that needs a bunch of work doing to it, and I’m working on my DIY skills to make it possible for me to do more of the work myself. I’d rented until six years ago, so had no chance to learn many of these skills. I’m proud of the fact I can now do basic plumbing, lay flooring, tile, and am generally confident to give things a go (with the help of the dads-demonstrating-DIY genre of YouTube video!)

In my 2024 post I mentioned I’d started sewing again. Since the move this has taken a backseat, due to not having a place to sew away from the cats. Max will eat thread and wool, so I have to be really careful to tidy things away from him. In March 2026 I’m getting a garden office built, as I miss my one from Bristol. At that point I can make the tiny room I’m currently using as an office a sewing and craft room, with the door closed to felines with dangerous cravings.

I want to take more photos. I live in an astoundingly beautiful place, surrounded by wild and beautiful countryside and so much history. While I get some great shots on my phone while out running, I’d like to document the world around me with a bit more intention in 2026. I’m also playing my mandolin quite a bit, and getting better at it. I think this year I might get some actual lessons as I’m through the knowing where to put my fingers stage.

And that’s mostly it, another year over. I spent Christmas just relaxing with my daughter, who is now forging her own career in tech, and showing her some of the interesting Roman history around my new town. And tomorrow, 2026 begins for real as I go back to work and see what the new year will bring.

I’ve been an amateur genealogist since I was a teenager. I started before the internet existed. This was a world where finding a single fact about a not-too-distant ancestor could involve an entire day of hauling huge indexes off shelves, then waiting five days for the certificate to arrive. It was time-consuming and expensive. As I extended lines it became impossible for me to go further as to do so involved trips across the country to churches and local record offices.

Genealogists were quick to take their research online. The early days of the genealogical web were based around usenet and mailing lists, and the ability to trade information and lookups in local records and graveyards made research easier. In the early 2000s I bought a microfiche reader and fiche copies of the records of some villages I was interested in. I could then provide lookups in those records for other researchers. Volunteers transcribed records, and made them available online. We all built websites to share our trees in GEDCOM format, along with the names and places we were researching. I found distant cousins through name lists kept by family history societies and on more than one occasion received a printed out tree in the mail.

Unless you are lucky enough to be connected to an important family, records are pretty thin on the ground. If you are lucky you’ll find a baptism, marriage, and death record from the records of the local Parish church. That might be all the recorded evidence of a person’s time on earth. You’ll discover that a significant portion of your ancestors never bothered to marry, or only did so when showing up to baptise their firstborn. I like to imagine the Vicar looking the young couple with their baby up and down and saying, “Well, while you are both here…” You’ll also discover just how many children died in infancy, how many women died in childbirth, and that people moved around far more than you imagine.

Despite the scarcity of information, in those early days of internet research, most of the genealogists I encountered made their best effort to corroborate information. There’s a lot of guesswork involved, and quite often you have to satisfy yourself that it’s most likely, based on ages and location, that these children belong to this couple. However, we tried, and I still try, to fact check findings, or at least to rule out obvious issues—such as a second family of the same name who could easily lay claim to some of those children!

Then Ancestry happened, and very quickly started to change the face of genealogical research. Backed by an ever growing set of records, and the ability to search the trees of other genealogists, it makes following lines back through multiple generations something you can do in an evening. But it also does something else. You can do genealogy as you always did, but more conveniently, or you can also check out the hints being offered against each individual. These hints can be all kinds of information. Ancestry may have found your individual in a record, such as a census, record of army service, or even a newspaper report. It might also have found your ancestor in another researcher’s public tree. You can look through your hints for each individual, and decide if this actually is the person you are interested in. This checking is the important bit, genealogical data is incredibly messy, Ancestry is good, but it’s also going to surface a lot of information that couldn’t possibly be your ancestor.

It’s in this fact checking that genealogy seems to have changed. As I am presented with another public tree that seems related to me, more often than not I can see a glaring problem with the data. Typically someone in the USA, has accepted a hint that links them to one of my lines in the UK, when I know there was no possible way that the person they have connected to ever travelled to America. At first I would reach out to the connection to explain the problem, typically they just didn’t care, or would argue that their story was more correct. Even genealogy can’t escape post-truth, they believed in their link to England and that was enough.

Ancestry, and other platforms, have actually made fact checking easier, in particular through DNA genealogy. I’ve proved what seemed to be a unlikely link to the tiny Scottish island of Coll due to a effort to match the DNA of descendants. I can say that without doubt I had ancestors there. I’ve also managed to prove that two men, born around 1800 in a small village in Wiltshire were most probably brothers by way of finding a researcher who matched as a distant cousin to me from that connection. It’s fascinating, a new angle on this strange hobby of collecting dead people, helping me prove guesses made over thirty years ago spooling through microfilm in a library somewhere.

I’m really excited that the reading-flow and reading-order properties are in Chrome 137 (current beta, will be Chrome stable as of May 27, 2025).

Finding a way to deal with the visual and source order disconnect created by grid and flex layout has been something I’ve kept returning to ever since grid shipped in browsers. It turned out to be far more complex than the proposal I made in 2022, but I think that what we’ve now specified and has been implemented in Chrome gives us what I was aiming for, and more.

I’ve worked on the specification for this, but all the credit for the Chrome implementation goes to Chrome engineer Di Zhang, who has done the implementation work, and also worked the related HTML issues through the WHATWG process. Read our post Use CSS reading-flow for logical sequential focus navigation, for details of what shipped in the Chrome beta yesterday, and check out the demos.

We really need you to try this out. There’s a lot of scope for edge cases with something that touches focus order. We want to find and fix any actual issues when used in practice, as opposed to thinking up theoretical problems. You can raise bugs against the spec on the CSSWG GitHub repo, or bugs with the Chrome implementation at crbug.com. Whenever I’ve talked about this issue, lots of people have told me they want this problem fixed. If you are one of those people, do check to see if what we’ve implemented solves the use cases you have. If we can show it’s working well, that will help make the case for other browsers to implement this so it can become part of Baseline.

Ever since I became an editor of the Multiple-column layout specification I’ve wanted to add the ability to let overflow columns wrap in the block direction, rather than extend out in the inline direction—creating the sort of horizontal scrollbar that almost nobody wants.

And, now we’re doing it. I’m working on the specification (which is in a very draft state right now). There’s also an experimental implementation behind a runtime flag in Chrome Canary, thanks to the work of Morten Stenshorne at Chrome.

If you want to follow along as we pick through the details, keep an eye on the css-multicol-2 tag.

You can also check out the experimental implementation by starting Canary with the MulticolColumnWrapping flag. See Chrome flags for how to do that. This CodePen should then show you a multicol with multiple rows, as in the following screenshot.

I was tagged by Jon Hicks and it seems like as good a time as any to return to ye olde blogge days, so here’s my answers.

Why did you start blogging in the first place?

I had some personal notes on an older incarnation of this site, and when blogging became a thing, I realized those notes were pretty much what people were calling a blog. So it really evolved from there.

What platform are you using to manage your blog and why did you choose it? Have you blogged on other platforms before?

Like Jon, I started with Moveable Type. I then built myself a blog in Classic ASP with VBScript and moved everything to it. At some point I moved it all to WordPress, then to my own product Perch, and it’s now back on WordPress. Why WordPress? I wanted to move it, after selling Perch, and it was trivial to write a converter from Perch to WordPress, so that was the easiest option that didn’t lose stuff. This means that my blog software has followed my personal coding language journey of Perl, to Classic ASP, to PHP. I’ve most recently been learning Python, so maybe that will be its next incarnation.

I’m not a fan of file-based systems, I am baffled when I see people reinventing things that databases solved perfectly well back in the late 90s, but I’ll save that rant for another post.

When do you feel most inspired to write?

I’m not someone who expects or requires inspiration or motivation. These days my job involves a lot of writing, much of it is just stuff that needs to be done, and isn’t going to wait until I feel inspired. That said, I often write entire posts, documents, and talks in my head while out running. I can come home, grab a coffee, and write 2000 words or so. I’m not sure I’d call it inspiration. It’s more that the act of getting away from my keyboard allows me to connect things up and formulate a solid piece.

I don’t post here as much, mostly due to a lack of time. You’ll find a lot of my writing over on web.dev and developer.chrome.com though. As I’m part of Chrome Developer Relations, there’s a balance to make between posting on my own site about the web platform, and putting that content on one of our sites. If I feel the content fits one of those platforms I’d post it there first.

Do you publish immediately after writing, or do you let it simmer a bit as a draft?

I usually leave things long enough to be able to read it with fresh eyes and with my editor hat on. A few hours of doing something else is usually enough. Self-editing is never perfect, my lovely writing team at work catch enough of my typos to know that, but a bit of distance helps to catch the worst problems.

What’s your favourite post on your blog?

There’s a post about turnip lanterns that picks up traffic every halloween. I like the fact I’ve documented various things here, such as my work on CSS grid layout. I’m fond of this post from 2011 about lucky breaks and saying yes to things. I’m still amazed at the career I’ve ended up with, and I’m still learning interesting things and writing about them, I don’t think I’ll ever stop.

Any future plans for your blog? Maybe a redesign, a move to another platform, or adding a new feature?

I might move off WordPress. Other than it being easy to move to, another reason I went with WordPress is that there are lots of good quality templates available. I’m not a designer, and while I can write the CSS to implement a design, I can’t come up with something that looks reasonable to implement. That’s really the main blocker for moving platforms.

I’d like to write more about some of the non-tech stuff that I do. My daughter suggested I set up an Instagram for my dressmaking and DIY projects, but I’m not sure I really want to do that at this point in history. However, the nice thing about Instagram is the fact you can set up multiple accounts for various things, and speak to the people interested in them. You can build a completely different audience with each of these, and it’s easy for people to find those accounts. The primarily web developer audience of this blog are going to be less interested in me sharing a cool dressmaking pattern I got from an indie designer on Etsy, than a targeted Instagram account audience. Back in the pre-social media days, blogs did serve that purpose, but I don’t think we’re going back there.