38 private links
"- А у вас есть некий набор стилистических паттернов? Например: предложить клиенту 20 вариантов обоев для сайта.
- Нет. Мы стараемся давать один вариант дизайна."
But lately (several months) I’ve been thinking can we use SVG icons in Social Menu instead of icon fonts. Leland Fiegel picked up my question in Twitter and rolled his own idea. It’s not bad solution but what if we could do this without Javascript.
Do you add a descriptive title attribute to your links? Did you know that you might be making your site even less accessible? Everything I thought I knew about the title attribute was proved wrong when I started using a screenreader.
...And a crossbrowser sticky footer solution
Icons! We see them all over the web, and they're essential to most pattern libraries and web design systems. I recently needed to implement such a system. It had to be non-prescriptive, scalable, and dynamically editable via CSS. The icons were to be used by multiple teams in many different applications, built with various frameworks and techniques. They needed to have the ability to be restyled, get cached, and be updated quickly and easily as more icons are added. Basically, the icon system needed to be really, really flexible. Challenge accepted.
Ideally, we should all be developing our code in our own little space on our own little local server. This allows us to easily make changes without messing up production code or stepping over other's work. This is usually cost prohibitive so we're "forced" to use virtual machines to make this a reality.
The problem we face is that each developer needs to have a virtual machine that is setup exactly (or nearly exactly) like our production server. This requires a long list of configuration changes that need to be made on every machine. For example, install the apache package, update this configuration file, setup MySQL so you can access the databases remotely. Then we run into more problems when additional changes are needed because the developer has to take time out of their schedule to make them on each machine. There are also passwords that have to be remembered and /etc/host changes that need to be made. You'll be in even worse shape if the deployment consists of multiple VMs.
Icons are everywhere. These “little miracle workers” (as John Hicks described them) help us reinforce meaning in the interfaces we design and build. Their popularity in web design has never been greater; the conciseness and versatility of pictograms in particular make them a lovely fit for displays large and small.
But icons on the web have had their fair share of challenges. They were time-consuming to prepare for every intended display size and color. When high-resolution displays hit the market, icons looked particularly low-res and blocky compared to the text they often accompanied.
So it’s really no wonder that icon fonts became such a hit. Icons displayed via @font-face were resolution-independent and customizable in all the ways we expected text to be. Sure, delivering icons as a typeface was definitely a hack, but it was also useful, versatile, and maybe even a little fun.
But now we need to stop. It’s time to let icon fonts pass on to Hack Heaven, where they can frolic with table-based layouts, Bullet-Proof Rounded Corners and Scalable Inman Flash Replacements. Here’s why…
Interestingly I found that there are two actions taken by the browser: firstly on the percentage itself - for example - Internet Explorer 7-11 will truncate any percentage to 2 decimal places, more modern browsers will round to a large number of decimal places.
Slideshows, sliders, carousels: whatever you call them, in terms of web design they are just evil. Do a quick Google search and you will see that most frontend developers and UX/UI designers can agree on this point and have been talking about it for years. But why do we still constantly see them? Part of the issue is that slideshows, especially in the hero region, are so ubiquitous that many clients see them as necessary and keep asking for them. They have essentially become a “home page standard.”
The @extend directive in Sass can produce undesirable side effects. David Khourshid shows how to use @extend effectively to produce clean & organized CSS.
When we work at scale, we often find that we spend a large amount of our time reading, maintaining, and refactoring existing code, rather than writing and adding new features. This is the reason we focus so much on things like architectures, naming conventions, methodologies, preprocessors, scalability, etc.: because writing CSS is easy; looking after it is not.
Luckily for us, solutions exist to the problem of creating fast, responsive, fully customizable grids: Susy is a Sass-based grid framework. It’s very lightweight and enables you to create entirely custom grids in CSS without touching your markup.
@extend is now widely considered an anti-pattern, so its usage is thankfully fading out, but we’re not quite there yet.
Care must be taken when implementing icon fonts to ensure a great experience for all users. What happens when your font doesn’t load? What happens when @font-face isn’t supported in the browser? We’ll show you how to implement bulletproof font icons.
Collapsible content areas are frequently presented in web sites and applications as a way to let users to control how content is shown or hidden on the page. Also called collapsibles, spin-downs, toggle panels, twisties, and content disclosures, they're ideal for selectively displaying optional information — like instructional text or additional details, for example — so users can focus on the task at hand and view this content only as needed.
At many of the web development conferences I attend, there is a talk on how to use an integrated development environment to aid in programming. The speaker will almost invariably mention a few of his favorite keyboard shortcuts within that environment for performing his most frequently used activities. Programmers are big fans of using the keyboard instead of continually shifting between the keyboard and mouse.
During the winter 2014, me and my family rented an apartment from San Diego, CA for few months through my work. While staying there, we had an AT&T hotspot device that provided the network connection. For us, relying on this device, meant constant drops of connection, network latency like we’ve never seen before, and websites that were completely broken because JavaScript wasn’t loading at all. A part of this can be explained by the poor reception at the location where we were staying, but overall, the whole experience put me thinking.
About a year ago, I wrote Mixin or Placeholder (my first article here at SitePoint) immediately followed by What Nobody Told You About Sass Extend. And here I am, one year later, changing my mind again and writing why I think the @extend directive from Sass is really far from being the Eldorado.
Accessibility is an important part of modern web development. It is our responsibility as creators of WordPress themes to make them accessible to all users, on any device. In this article, I’ll offer some simple tips to create better, more accessible WordPress themes.
As the craft of Web design continues to evolve, we’re recognizing the need to develop thoughtful design systems, rather than creating simple collections of web pages.
A lot has been said about creating design systems, and much of it focuses on establishing foundations for color, typography, grids, texture and the like. This type of thinking is certainly important, but I’m slightly less interested in these aspects of design because ultimately they are and will always be subjective. Lately I’ve been more interested in what our interfaces are comprised of and how we can construct design systems in a more methodical way.
In searching for inspiration and parallels, I kept coming back to chemistry. The thought is that all matter (whether solid, liquid, gas, simple, complex, etc) is comprised of atoms. Those atomic units bond together to form molecules, which in turn combine into more complex organisms to ultimately create all matter in our universe.
Similarly, interfaces are made up of smaller components. This means we can break entire interfaces down into fundamental building blocks and work up from there. That’s the basic gist of atomic design.