Front End Web Development

Botticelli & the Typographers

Typography - Fri, 10/27/2017 - 5:54am

Sandro Botticelli was born in Florence about 1445. In 1470, aged just 25, and shortly after printing was introduced to Italy, his prodigious talent led him to open his own studio. He flourished under the patronage of the Medici family and was invited by Pope Sixtus IV to paint frescoes in the recently restored Sistine Chapel of the Apostolic Palace, almost three decades before Michelangelo wielded his brush and brilliance to the chapel’s ceiling.

Dante’s La Commedia, printed in Florence by Nicolaus Laurentii (also known as Niccolò Tedesco), 1481. With text and images printed on two different kinds of press in different print shops, there was always the chance for this kind of mishap. Image courtesy of Bodleian Library, Oxford University. Shelfmark: Auct. 2Q 1.11

Prior to leaving for Rome in the summer of 1481, Botticelli produced drawings for an illustrated edition of Dante’s Divine Comedy. The drawings were to serve as models for Baccio Baldini’s twenty copper engravings. The book went to print before the illustrations were completed. Most surviving copies exist with just several of the engravings, some printed alongside the text, or inexpertly in the margins, while others have been pasted in at a later date. Although most commentators suggest that the edition, printed in Florence by Nicolaus Laurentii in 1481, was a failure, more than 130 copies have survived, suggesting that the print-run and subsequent sales were nonetheless pretty good. However, as a piece of book design, as an effort to combine engravings with metal type, it is by no means the greatest example.

An intaglio printshop with roller presses. Jan van der Straet. Nova reperta. Engraving, c. 1600. Image courtesy of the Folger Shakespeare Library

Despite the advantages of metal engravings over woodblocks (considerably more durable and permitting finer detail of line), they are seldom seen in fifteenth-century books. The woodcut is an ideal counterpart to movable type. Both are relief processes, meaning that woodblocks and type could be set in the same form and printed at the same time. On the other hand, intaglio printing, like etchings and engraving in metal plates, require printing on a separate roller press (similar, in principle, to a mangle), as they require significantly more pressure than can be achieved in a flat-bed press designed for relief printing like letterpress. (Intaglio also prefers stiffer, more viscous inks.) The intaglio technique, then, is the opposite of relief printing as the ink sits not on the surface, as is the case for relief printing, but below the surface in the engraved or incised crevices and grooves, thus extra pressure is required to push or emboss the paper into those inked grooves to transfer the ink to the paper. Leonardo da Vinci provided illustrations for Luca Pacioli’s famed De divina proportione (On the Divine Proportion) and although written at the close of the fifteenth century, was not printed until 1509 by Paganino Paganini in Venice.

The 1481 Florentine edition of Dante is a rare fifteenth-century example of the involvement of a significant Renaissance artist in book illustration. The only other artist of the fifteenth century, who comes to mind, is that genius pioneer of the Northern Renaissance, Albrecht Dürer, who published his books with, among others, his godfather, Anton Koberger.

“Botticelli is the first, and perhaps the only artist whose pictorial conception of the Divine Comedy does not fall short of the poetical significance.”Drawings by Sandro Botticelli for Dante’s Divina commedia, F. Lippmann, 1896, p. 19

The drawings upon which Baldini’s engravings were based have not survived, but a later set of drawings for an ambitious but unfortunately unfinished manuscript edition of Dante, likely commissioned by Lorenzo di Pierfrancesco de’ Medici (who also commissioned Primavera), do survive and, even in their unfinished state remain, perhaps, the most visceral until those of William Blake and Gustave Doré‘s in the nineteenth century.

Beatrice explaining to Dante the nature of the heavens. Drawing by Sandro Botticelli, c. 1490  Consider your origin; 
 you were not born to live like brutes, 
 but to follow virtue and knowledge. 
The Divine Comedy, Canto XXVI, ll. 118–120

Although engravings were seldom used in fifteenth-century books, they appear, along with etchings, with increasing frequency throughout the sixteenth century, so that by the beginning of the seventeenth century, they have all but replaced the woodcut as the principal source of book illustration until its resurgence in the nineteenth century.

D. McKitterick, Print, Manuscript and the Search for Order, 1450-1830, Cambridge, 2003. (esp., chapter 3)

D. Landau & P. Parshall, The Renaissance Print: 1470-1550, Yale, 1996, p. 108

W.Y. Ottley, An Inquiry into the Origin and Early History of Engraving upon Copper and in Wood, with an Account of Engravers and Their Works,London, 1816.

S. Roberts, Printing a Mediterranean World: Florence, Constantinople, and the Renaissance of Geography, 2013.

Vasari, G., The Lives of the Artists (Oxford World’s Classics), Oxford, 2008.

Dane, J., ‘”Wanting the First Blank”: Frontispiece to the Huntington Copy of Caxton’s Recuyell of the Historyes of Troye’, Huntington Library Quarterly, 67(2), 2004, pp. 315–325.

Wang, Y., ‘Caxton’s Romances and Their Early Tudor Readers’, Huntington Library Quarterly, 67(2), 2004, pp. 173–188.

S. Roach (ed.), Across the narrow seas: studies in the history and bibliography of Britain and the Low Countries : presented to Anna E.C. Simoni, 1991

E. Gebhart & V. Charles, Botticelli, 2010

Sponsored by Hoefler & Co.

Botticelli & the Typographers

The Output Element

Css Tricks - Thu, 10/26/2017 - 3:29am

Last night I was rooting around in the cellars of a particularly large codebase and stumbled upon our normalize.css which makes sure that all of our markup renders in a similar way across different browsers. I gave it a quick skim and found styles for a rather peculiar element called <output> that I'd never seen or even heard of before.

According to MDN, it "represents the result of a calculation or user action" typically used in forms. And rather embarrassingly for me, it isn't a new and fancy addition to the spec since Chris used it in a post all the way back in 2011.

But regardless! What does output do and how do we use it? Well, let's say we have an input with a type of range. Then we add an output element and correlate it to the input with its for attribute.

<input type="range" name="quantity" id="quantity" min="0" max="100"> <output for="quantity"></output>

See the Pen Input Output #2 by CSS-Tricks (@css-tricks) on CodePen.

It... doesn't really do anything. By default, output doesn't have any styles and doesn't render a box or anything in the browser. Also, nothing happens when we change the value of our input.

We'll have to tie everything together with JavaScript. No problem! First we need to find our input in the DOM with JavaScript, like so:

const rangeInput = document.querySelector('input');

Now we can append an event listener onto it so that whenever we edit the value (by sliding left or right on our input) we can detect a change:

const rangeInput = document.querySelector('input'); rangeInput.addEventListener('change', function() { console.log(this.value); });

this.value will always refer to the value of the rangeInput because we're using it inside our event handler and we can then return that value to the console to make sure everything works. After that we can then find our output element in the DOM:

const rangeInput = document.querySelector('input'); const output = document.querySelector('output'); rangeInput.addEventListener('change', function() { console.log(this.value); });

And then we edit our event listener to set the value of that output to change whenever we edit the value of the input:

const rangeInput = document.querySelector('input'); const output = document.querySelector('output'); rangeInput.addEventListener('change', function() { output.value = this.value; });

And voilá! There we have it, well mostly anyway. Once you change the value of the input our output will now reflect that:

See the Pen Input Output #3 by Robin Rendle (@robinrendle) on CodePen.

We should probably improve this a bit by settting a default value to our output so that it's visible as soon as you load the page. We could do that with the HTML itself and set the value inside the output:

<output for="quantity">50</output>

But I reckon that's not particularly bulletproof. What happens when we want to change the min or max of our input? We'd always have to change our output, too. Let's set the state of our output in our script. Here's a new function called setDefaultState:

function setDefaultState() { output.value = rangeInput.value; }

When the DOM has finished loading and then fire that function:

document.addEventListener('DOMContentLoaded', function(){ setDefaultState(); });

See the Pen Input Output #4 by Robin Rendle (@robinrendle) on CodePen.

Now we can style everything! But there's one more thing. The event listener change is great and all but it doesn't update the text immediately as you swipe left or right. Thankfully there's a new type of event listener called input with fairly decent browser support that we can use instead. Here's all our code with that addition in place:

const rangeInput = document.querySelector('input'); const output = document.querySelector('output'); function setDefaultState() { output.value = rangeInput.value; } rangeInput.addEventListener('input', function() { output.value = this.value; }); document.addEventListener('DOMContentLoaded', function() { setDefaultState(); });

See the Pen Input Output #5 by Robin Rendle (@robinrendle) on CodePen.

And there we have it! An input, with an output.

The Output Element is a post from CSS-Tricks

Heavy images slowing down your site?

Css Tricks - Thu, 10/26/2017 - 3:06am

(This is a sponsored post.)

Speed is an important piece of a website's user experience. Since images account for an average of 70% or more of a webpage's weight, optimizing them is crucial to creating a faster website. That's why we created Page Weight, a tool that will diagnose your site’s most problematic images and prescribe solutions on how to optimize them.

Simply enter your URL into Page Weight and we will prepare a custom report of your images performance and what you can do to improve them.

Test your site for free!

Direct Link to ArticlePermalink

Heavy images slowing down your site? is a post from CSS-Tricks

Myriad Devanagari and Myriad Bengali: New Brahmic type from Adobe Type

Nice Web Type - Wed, 10/25/2017 - 9:07am

It is with great satisfaction that I present the two newest additions from Adobe Type to the Typekit library, Myriad Devanagari and Myriad Bengali. Designed by Vaibhav Singh and Neelakash Kshetrimayum, respectively, these typefaces translate the design of our popular Myriad family to the most-used writing systems of India.

From the beginning, the concept for these families was to make them harmonize in spirit with Myriad, Adobe’s best-loved sans serif design, and to continue building out the general usability for the Myriad superfamily. Existing Myriad families already included script coverage for Latin, Cyrillic, Greek, Hebrew, and Arabic writing systems. Designing Devanagari and Bengali extensions of Myriad provides a powerful typographic system for designers who may need to set text in various languages using a consistent style.

Writing systems supported by Myriad families (from left-to-right, top-to-bottom): Devanagari, Greek, Latin, Bengali, Arabic, Cyrillic, Hebrew.

In addition to usability, an equally important concern was the appropriateness of the design for digital display. The design principles that govern Myriad—letterforms informed by writing, generous counters, bright joins, simplified detailing—are all hallmarks of type design that works well for screen-based media. In adapting the typographic features for Devanagari and Bengali, we took great care to balance the traditional calligraphic conventions of these scripts with the spirit and simplicity of Myriad.

Some calligraphic details of the Brahmic writing systems (highlighted in orange) have been retained, other features (in green) have been rationalized to be more neutral, similar to the original Myriad design.

Vaibhav and Neel, both extremely talented designers, have previously worked with us on the Adobe Gurmukhi and Adobe Bengali types. It was very important to me to involve Robert Slimbach to find the right balance of “Myriadness” for these family extensions as he was one of Myriad’s principal designers, along with Carol Twombly, and had also designed the Arabic and Hebrew extensions of the family. Fiona Ross also consulted on these projects, providing guidance and ensuring that our design decisions were appropriate for the Indian scripts.

The resulting designs for Myriad Devanagari and Bengali are sturdy and dynamic, combining moderately low contrast with traditional proportions, and detailing informed by calligraphy. On screen, the resulting text leaves a strong impression and avoids a dull, heavy texture that can be a pitfall for many sans serifs.

The contrast of Adobe Bengali Bold (left) is is much higher than Myriad Bengali Bold (right). This is shown by the relative weight of the heaviest strokes, highlighted in green, and the thinnest, in orange.

Although the stroke contrast of Myriad Devanagari (right) is considerably reduced in comparison to Adobe Devanagari (left), stroke joins are kept open to provide a pleasing texture in running text.

Each of these new families includes 10 styles, featuring five weights from light to black with accompanying obliques. This suite of variations provides a wide range of typographic options typically unavailable for these writing systems. Myriad Devanagari supports the languages Hindi, Marathi, Nepali, and Sanskrit. Myriad Bengali supports Bangla and Assamese languages. These fonts can be used on the web or synced for desktop use from Typekit, and you’ll find perpetual licenses for them on Fontspring.

Brahmic type design at Adobe

These two new families have been designed and produced as part of an Adobe Originals initiative to provide our customers with premium quality fonts for the top 10 languages of India. This project began in 2005 with the development of Adobe Devanagari by Tiro Typeworks for our library. In 2012, Adobe moved Brahmic type development efforts in-house, collaborating with external designers to produce well-crafted fonts for additional Indian writing systems.

Until now, all of these released Brahmic type designs have been specifically tuned for use in print media in order to meet the needs of our print publishing customers on the Indian subcontinent. The release of Myriad Devanagari and Myriad Bengali, both developed with screen display as a primary use case, is a notable shift in our Brahmic type design philosophy.

Personally, I’m excited that these typefaces are breaking new ground, and it’s always very humbling to work with such talented designers in the process. I feel that it took all of our combined efforts to make these new type families a reality, and I’m looking forward to what’s next.

Code Review Etiquette

Css Tricks - Wed, 10/25/2017 - 4:37am

Code reviews are a big part of writing software, especially when working within a team. It is important to have an agreed-upon etiquette for reviewing code within a team. A code review is a critique and a critique can often feel more personal than the code writing itself. A sloppy, under-researched, or insensitive code critique can cause difficulties between team members, reduce overall team productivity, and diminish code quality over time. This post will briefly define code reviews, describe some common mistakes, and provide some quick tips for improving a code review process.

What are code reviews?

Code reviews are the process of sharing code so that other engineers can review it. Code reviews can happen verbally during pair programming sessions, or through reviewing code on websites like CodePen and GitHub. Mainly, code reviews happen in tools like GitHub when engineers submit pull requests.

Critiques are hugely beneficial. Convening engineers to discussions about code ensure that they're on the same page, regardless of whether it's in person or by sharing comments. Also, a review can help catch small mistakes in code or comments—like spelling and it can help newer or more junior coders learn the codebase. When done well, regular code reviews have nothing but benefits for all involved.

A common goal for code reviews is to make code changes as minimal and clear as possible so that the reviewer can easily understand what has changed and what is happening in the code. If code reviews are smaller, they're more frequent — potentially several a day — and more manageable.

Reviewing code should be a part of every developer's workflow. Senior reviewers are given the opportunity to teach/mentor, and even learn something new from time to time. Junior reviewers can grow and often help ensure code readability through the questions they ask. In fact, junior engineers are usually the best team members to ensure code readability.

For an engineer who works alone, asking for feedback from outsiders — at meet-ups, GitHub, Open Source Slack Channels, Reddit, Twitter, etc — can allow the solo coder the opportunity to participate in a code review process.

If we could all agree on an established process and language for reviewing code, then maintaining a positive environment for creative and productive engineering is easier. A code review etiquette benefits everyone — whether working alone or within a team.

Harsh code reviews can hurt feelings

Seeing bugs and issues continue to roll in and being mentally unable to address them has led to feelings of failure and depression. When looking at the moment project, I could only see the negatives. The bugs and misnomers and mistakes I had made. It led to a cycle of being too depressed to contribute, which led to being depressed because I wasn't contributing.

- Tim Wood, creator of Momentjs

There are many online comments, posts, and tweets by prolific engineers expressing that their feelings have been hurt by code reviews. This doesn't directly mean that reviewers are trying to be mean. Feeling defensive is a normal, quite human reaction to a critique or feedback. A reviewer should be aware of how the pitch, tone, or sentiment of their comments could be interpreted but the reviewee — see Occam's Razor.

It's like these commenters don't consider maintainers to be people, we make mistakes.

— Henry Zhu @SF (@left_pad) September 18, 2017

Although reviewing code is very beneficial, a poor or sloppy review can have the opposite outcome. Avoid criticism without providing context. In other words, take the time to explain why something is wrong, where it went wrong, and how to avoid the mistake moving forward. Showing this level of respect for the reviewee strengthens the team, improves engineering awareness, and helps to provide agreed-upon technical definitions.

Quick tips for improving code review etiquette

Code is logical in nature. It is easy to pinpoint code that is incorrect or could be improved, just like it is easy to notice spelling misteaks. The human condition, when looking at and discussing logical things (like code), is to disregard the feelings of other people. This causes feelings to get hurt and a loss of focus on learning and collaboration.

Improving code review etiquette, because of the human condition, is difficult! Here is a quick list of things that I've done, said, seen, or received, that are easy wins in the art of Code Review Etiquette.

Remove the person

Without realizing it, engineers can neglect the difference between insightful critique and criticism because of personal relationships in communication.

The lines below dissect a code review comment of a theoretical function where it is suggested that there is an opportunity to return out of the function early.

You and I: Using you or I is probably not offensive intentionally, so don't worry. However, over time, involving the person can start to feel less positive—especially if vocal tones are ever added.

You should return out of this function early

We: Using we is inclusive and a safe way to say something more directly without making someone feel defensive. However, if the person speaking says we, and has not worked on the code at all, it may seem falsely inclusive and insensitive.

We should return out of this function early

No personal reference: Without personal reference, conversation or review will closely communicate the problem, idea, or issue.

Return out of this function early

Notice how the amount of text needed to communicate the same thing without using personal references takes fewer words and has greater clarity. This helps with human interaction, separates code discussion from personal discussion, and fewer words are needed to communicate the same idea.

Keep passionate conversations quiet

Passion is an important motivator for improving. Passion that is critical in nature can be very considerate and motivating. Feedback that is critical in nature is most useful if the person receiving the critique is engaged. This sort of communication comes up a lot during architectural conversations or when discussing new products.

Feedback that is critical in nature is most useful if the person receiving the critique is engaged. Note: the person receiving the information must be engaged with the critique.

Imagine this comment when stated with exaggerated physical movement, more excited vocal tone, and higher volume.

There are 8 web fonts used in this mock which may affect page load speed or even certain tracking metrics that could be caused by new race conditions!

Then, imagine a similar comment, even terser but stated with a calm demeanor, slower delivery, and a normal vocal volume — followed by a question.

There are 8 web fonts used in this mock. This will affect page load speed and possible tracking metrics because of potential race conditions. How can this be improved?

Notice how the comments above are almost the same. The second comment is even more direct. It states a problem as a fact and then requests feedback.

An important thing to remember when being passionate is taking on a quieter tone. This is a physical decision — not a social one. Passionate language can be the same, and perceived very differently, based on the orientation of the communicator's tone. If physical tone (body language), vocal tone, vocal pitch, and vocal volume remain gentle, it is observed that it is much more likely for an audience to remain engaged — even if the critique is critical in nature.

If the tone is aggressive in nature (exaggerated physical movement, more excited vocal tone, higher volume), the actual words used can be gentle in nature, but the audience can feel very differently. This communication can lead to embarrassment, a disengaged audience, and even loss of respect.

Aggressive communication is common with passionate communication because the human condition wants to protect ideas that we're passionate about. So, don't worry about it too much if you observe that your audience is disengaged when discussing something that you're passionate about. The key is to remember that if you can create perceived gentle communication, it will be easier for your audience to remain engaged — even if they are not initially in agreement.

Don't review the author, review the code

Following the conversation above, the act of pointing, within written conversation or actual body language, in almost any situation is not optimal for good communication. It changes the focal point of the conversation from the context of the conversation to a person or a thing.

The response below provides a comment and then a link. In the context of the code review, the second part of the comment and link takes the reader out of the context of the code review, which is confusing.

// Return out of this function earlier // You need to learn about functional programming

The comment below provides a comment, and then a pseudo-code suggestion.

/* return early like this: */ const calculateStuff = (stuff) => { if (noStuff) return // calculate stuff return calculatedStuff }

In the two examples above, the first example causes the reader to go far beyond the issue. The conversation is more abstract—even existential. The second example refers directly to the issue and then provides a pseudo code snippet that relates directly to the comment.

It is best to only comment on contextually specific items when reviewing code. Broad comments lead to a loss of context. If broader discussions must happen, they should happen outside of code reviews. This keeps the code review clear and scoped to the code that is being reviewed.

Right and wrong can change

Developers almost always want to re-write things. It is natural to break problems down into tasks in real-time to address today's situation. However, focusing on the who's and why's of a product's history is important to conceptualize because great context is gained. 'History repeats itself' is an important phrase to remember when critiquing products or when a product you've written is critiqued. There is always a great amount of knowledge to be gained from historical context.

JavaScript was made in a week, considered a hacky scripting language, and then became the most widely used programming language in the world. Scalable Vector Graphics (SVGs) were supported in 1999, pretty much forgotten about, and now, they continue to gain popularity for the new opportunities they provide. Even the World Wide Web (the Internet) was meant for document sharing with little anticipation of the current result today. All of these technologies are important to remember when considering software and engineering—as logical and predictable results are supposed to be, success is often derived from unexpected results! Be open!

Some resources and tools that can help with code review etiquette Conclusion

The list above includes general, high-level things that can help with positive engagement when talking about, reviewing, or reading about code—code review etiquette.

I am a hypocrite. I have made all the mistakes that I advise not to do in this article. I am human. My goal here is to help others avoid the mistakes that I have made, and to perhaps encourage some behavior standards for reviewing code so that engineers can more openly discuss code with less worry about being hurt or hurting others.

Code Review Etiquette is a post from CSS-Tricks

Creating Vue.js Transitions & Animations

Css Tricks - Tue, 10/24/2017 - 4:01am

My last two projects hurled me into the JAMstack. SPAs, headless content management, static generation... you name it. More importantly, they gave me the opportunity to learn Vue.js. More than "Build a To-Do App" Vue.js, I got to ship real-life, production-ready Vue apps.

The agency behind Snipcart (Spektrum) wanted to start using decoupled JavaScript frameworks for small to medium sites. Before using them on client projects, however, they chose to experiment on themselves. After a few of my peers had unfruitful experiences with React, I was given the green light to prototype a few apps in Vue. This prototyping morphed into full-blown Vue apps for Spektrum connected to a headless CMS. First, I spent time figuring out how to model and render our data appropriately. Then I dove head first into Vue transformations to apply a much-needed layer of polish on our two projects.

I've prepared live demos on CodePen and GitHub repos to go along with this article.

This post digs into Vue.js and the tools it offers with its transition system. It is assumed that you are already comfortable with the basics of Vue.js and CSS transitions. For the sake of brevity and clarity, we won't get into the "logic" used in the demo.

Handling Vue.js Transitions & Animations

Animations & transitions can bring your site to life and entice users to explore. Animations and transitions are an integral part of UX and UI design. They are, however, easy to get wrong. In complex situations like dealing with lists, they can be nearly impossible to reason about when relying on native JavaScript and CSS. Whenever I ask backend developers why they dislike front end so vehemently, their response is usually somewhere along the lines of "... animations".

Even for those of us who are drawn to the field by an urge to create intricate micro-interactions and smooth page transitions, it's not easy work. We often need to rely on CSS for performance reasons, even while working in a mostly JavaScript environment, and that break in the environment can be difficult to manage.

This is where frameworks like Vue.js step in, taking the guess-work and clumsy chains of setTimeout functions out of transitions.

The Difference Between Transitions and Animations

The terms transition and animation are often used interchangeably but are actually different things.

  • A transition is a change in the style properties on an element to be transitioned in a single step. They are often handled purely through CSS.
  • An animation is more complex. They are usually multi-step and sometimes run continuously. Animations will often call on JavaScript to pick up where CSS' lack of logic drops off.

It can be confusing, as adding a class could be the trigger for a transition or an animation. Still, it is an important distinction when stepping into the world of Vue because both have very different approaches and toolboxes.

Here's an example of transitions in use on Spektrum's site:

Using Transitions

The simplest way to achieve transition effects on your page is through Vue's <transition> component. It makes things so simple, it almost feels like cheating. Vue will detect if any CSS animations or transitions are being used and will automatically toggle classes on the transitioned content, allowing for a perfectly timed transition system and complete control.

First step is to identify our scope. We tell Vue to prepend the transition classes with modal, for example, by setting the component's name attribute. Then to trigger a transition all you need to do is toggle the content's visibility using the v-if or v-show attributes. Vue will add/remove the classes accordingly.

There are two "directions" for transitions: enter (for an element going from hidden to visible) and leave (for an element going from visble to hidden). Vue then provides 3 "hooks" that represent different timeframes in the transition:

  • .modal-enter-active / .modal-leave-active: These will be present throughout the entire transition and should be used to apply your CSS transition declaration. You can also declare styles that need to be applied from beginning to end.
  • .modal-enter / .modal-leave: Use these classes to define how your element looks before it starts the transition.
  • .modal-enter-to / .modal-leave-to: You've probably already guessed, these determine the styles you wish to transition towards, the "complete" state.

To visualize the whole process, take a look at this chart from Vue's documentation:

How does this translate into code? Say we simply want to fade in and out, putting the pieces together would look like this:

<button class="modal__open" @click="modal = true">Help</button> <transition name="modal"> <section v-if="modal" class="modal"> <button class="modal__close" @click="modal = false">&times;</button> </section> </transition> .modal-enter-active, .modal-leave-active { transition: opacity 350ms } .modal-enter, .modal-leave-to { opacity: 0 } .modal-leave, .modal-enter-to { opacity: 1 }

This is likely the most basic implementation you will come across. Keep in mind that this transition system can also handle content changes. For example, you could react to a change in Vue's dynamic <component>.

<transition name="slide"> <component :is="selectedView" :key="selectedView"/> </transition> .slide-enter { transform: translateX(100%) } .slide-enter-to { transform: translateX(0) } .slide-enter-active { position: absolute } .slide-leave { transform: translateX(0) } .slide-leave-to { transform: translateX(-100%) } .slide-enter-active, .slide-leave-active { transition: all 750ms ease-in-out }

Whenever the selectedView changes, the old component will slide out to the left and the new one will enter from the right!

Here's a demo that uses these concepts:

See the Pen VueJS transition & transition-group demo by Nicolas Udy (@udyux) on CodePen.

Transitions on Lists

Things get interesting when we start dealing with lists. Be it some bullet points or a grid of blog posts, Vue gives you the <transition-group> component.

It is worth noting that while the <transition> component doesn't actually render an element, <transition-group> does. The default behaviour is to use a <span> but you can override this by setting the tag attribute on the <transition-group>.

The other gotcha is that all list items need to have a unique key attribute. Vue can then keep track of each item individually and optimize its performance. In our demo, we're looping over the list of companies, each of which has a unique ID. So we can set up our list like so:

<transition-group name="company" tag="ul" class="content__list"> <li class="company" v-for="company in list" :key=""> <!-- ... --> </li> </transition-group>

The most impressive feature of transition-group is how Vue handles changes in the list's order so seamlessly. For this, an additional transition class is available, .company-move (much like the active classes for entering and leaving), which will be applied to list items that are moving about but will remain visible.

In the demo, I broke it down a bit more to show how to leverage different states to get a cleaner end result. Here's a simplified and uncluttered version of the styles:

/* base */ .company { backface-visibility: hidden; z-index: 1; } /* moving */ .company-move { transition: all 600ms ease-in-out 50ms; } /* appearing */ .company-enter-active { transition: all 300ms ease-out; } /* disappearing */ .company-leave-active { transition: all 200ms ease-in; position: absolute; z-index: 0; } /* appear at / disappear to */ .company-enter, .company-leave-to { opacity: 0; }

Using backface-visibility: hidden on an element, even in the absence of 3D transforms, will ensure silky 60fps transitions and avoid fuzzy text rendering during transformations by tricking the browser into leveraging hardware acceleration.

In the above snippet, I've set the base style to z-index: 1. This assures that elements staying on page will always appear above elements that are leaving. I also apply a absolute positioning to items that are leaving to remove them from the natural flow, triggering the move transition on the rest of the items.

That's all we need! The result is, frankly, almost magic.

Using Animations

The possibilities and approaches for animation in Vue are virtually endless, so I've chosen one of my favourite techniques to showcase how you could animate your data.

We're going to use GSAP's TweenLite library to apply easing functions to our state's changes and let Vue's lightning fast reactivity reflect this on the DOM. Vue is just as comfortable working with inline SVG as it is with HTML.

We'll be creating a line graph with 5 points, evenly spaced along the X-axis, whose Y-axis will represent a percentage. You can take a look here at the result.

See the Pen SVG path animation with VueJS & TweenLite by Nicolas Udy (@udyux) on CodePen.

Let's get started with our component's logic.

new Vue({ el: '#app', // this is the data-set that will be animated data() { return { points: { a: -1, b: -1, c: -1, d: -1, e: -1 } } }, // this computed property builds an array of coordinates that // can be used as is in our path computed: { path() { return Object.keys(this.points) // we need to filter the array to remove any // properties TweenLite has added .filter(key => ~'abcde'.indexOf(key)) // calculate X coordinate for 5 points evenly spread // then reverse the data-point, a higher % should // move up but Y coordinates increase downwards .map((key, i) => [i * 100, 100 - this.points[key]]) } }, methods: { // our randomly generated destination values // could be replaced by an array.unshift process setPoint(key) { let duration = this.random(3, 5) let destination = this.random(0, 100) this.animatePoint({ key, duration, destination }) }, // start the tween on this given object key and call setPoint // once complete to start over again, passing back the key animatePoint({ key, duration, destination }) {, duration, { [key]: destination, ease: Sine.easeInOut, onComplete: this.setPoint, onCompleteParams: [key] }) }, random(min, max) { return ((Math.random() * (max - min)) + min).toFixed(2) } }, // finally, trigger the whole process when ready mounted() { Object.keys(this.points).forEach(key => { this.setPoint(key) }) } });

Now for the template.

<main id="app" class="chart"> <figure class="chart__content"> <svg xmlns="" viewBox="-20 -25 440 125"> <path class="chart__path" :d="`M${path}`" fill="none" stroke="rgba(255, 255, 255, 0.3)" stroke-width="1.2" stroke-linecap="round" stroke-linejoin="round"/> <text v-for="([ x, y ]) in path" :x="x - 10" :y="y - 7.5" font-size="10" font-weight="200" fill="currentColor"> {{ 100 - (y | 0) + '%' }} </text> </svg> </figure> </main>

Notice how we bind our path computed property to the path element's d attribute. We do something similar with the text nodes that output the current value for that point. When TweenLite updates the data, Vue reacts instantly and keeps the DOM in sync.

That's really all there is to it! Of course, additional styles were applied to make things pretty, which at this point you might realize is more work then the animation itself!

Live demos (CodePen) & GitHub repo

Go ahead, browse the live demos or analyze/re-use the code in our open source repo!


I've always been a fan of animations and transitions on the web, but I'm also a stickler for performance. As a result, I'm always very cautious when it comes to relying on JavaScript. However, combining Vue's blazing fast and low-cost reactivity with its ability to manage pure CSS transitions, you would really have to go overboard to have performance issues.

It's impressive that such a powerful framework can offer such a simple yet manageable API. The animation demo, including the styling, was built in only 45 minutes. And if you discount the time it took to set up the mock data used in the list-transition, it's achievable in under 2 hours. I don't even want to imagine the migraine-inducing process of building similar setups without Vue, much less how much time it would take!

Now get out there and get creative! The use cases go far beyond what we have seen in this post: the only true limitation is your imagination. Don't forget to check out the transitions and animations section in Vue.js' documentation for more information and inspiration.

This post originally appeared on Snipcart's blog. Got comments, questions? Add them below!

Creating Vue.js Transitions & Animations is a post from CSS-Tricks

Reboot, Resets, and Reasoning

Css Tricks - Mon, 10/23/2017 - 5:01am

I saw in an article by Nicholas Cerminara the other day (careful visiting that link, looks like they have some tracking scripts run wild) that Bootstrap 4 has a new CSS reset baked in they are calling Reboot:

Reboot, a collection of element-specific CSS changes in a single file, kickstart Bootstrap to provide an elegant, consistent, and simple baseline to build upon.

If you're new to CSS development, the whole idea of a CSS reset is to deal with styling inconsistencies across browsers. For example, just now I popped a <button> onto a page with no other styling whatsoever. Chrome applies padding: 2px 6px 3px; - Firefox applies padding: 0 8px;. A CSS reset would apply new padding to that element, so that all browsers are consistent about what they apply. There are loads of examples like that.

By way of a bit of history...

In 2007 Jeff Starr rounded up a bunch of different CSS resets. The oldest one dated is Tantek Çelik's undohtml.css (that's a direct link to the source). We can see that the purpose behind it was to strip away default styling.

/* undohtml.css */ /* (CC) 2004 Tantek Celik. Some Rights Reserved. */ /* */ /* This style sheet is licensed under a Creative Commons License. */ /* Purpose: undo some of the default styling of common (X)HTML browsers */

By far, the most popular reset came shortly after: the Meyer reset. It has different stuff in it than Tantek's did (it has even been updated with some HTML5 elements) but the spirit is the same: remove default styling. You'll probably recognize this famous block of code, finding its way into your DevTools style panel everywhere:

html, body, div, span, applet, object, iframe, h1, h2, h3, h4, h5, h6, p, blockquote, pre, a, abbr, acronym, address, big, cite, code, del, dfn, em, img, ins, kbd, q, s, samp, small, strike, strong, sub, sup, tt, var, b, u, i, center, dl, dt, dd, ol, ul, li, fieldset, form, label, legend, table, caption, tbody, tfoot, thead, tr, th, td, article, aside, canvas, details, embed, figure, figcaption, footer, header, hgroup, menu, nav, output, ruby, section, summary, time, mark, audio, video { margin: 0; padding: 0; border: 0; font-size: 100%; font: inherit; vertical-align: baseline; }

Start with a reset like this (at the top of your production stylesheet) and the styles you write afterword will be on a steady foundation.

Years later, as HTML5 became more real, resets like Richard Clark's HTML5 Reset gained popularity. It was still a modified version of the Meyer reset, and the retained that spirit.

article,aside,details,figcaption,figure, footer,header,hgroup,menu,nav,section { display:block; }

Sprinkled all throughout this, there were plenty of developers who went minimal by just zapping margin and padding from everything and leaving it at that:

* { padding: 0; margin: 0; }

Dumb trivia: the CSS-Tricks logo was inspired by the universal selector and that idea.

Along comes Normalize.css...

Normalize.css represents the first meaningful shift in spirit for what a CSS reset should do. This is what seemed so different about it to me:

  • It was a fresh evaluation of everything that could be styled different across browsers and it address all of it. Where older CSS resets were a handful of lines of code, the uncompressed and documented normalize is 447.
  • It didn't remove any styling from elements that were already consistent across browsers (for the most part). For example, there isn't anything in Normalize for h2-h6 elements, just a fix for a weird h1 thing. That means you aren't zapping away header hierarchy, that default styling remains.
  • It was more accommodating to the idea of altering it, rather than just including it. For example, there is a section just for the <pre> tag and one line of that sets its font-family. You could change that to the font-family you want, and it would be just as effective of a reset.

The code is satisfying to read, as it explains what it's doing without drowning in specifics:

/** * 1. Remove the bottom border in Chrome 57- and Firefox 39-. * 2. Add the correct text decoration in Chrome, Edge, IE, Opera, and Safari. */ abbr[title] { border-bottom: none; /* 1 */ text-decoration: underline; /* 2 */ text-decoration: underline dotted; /* 2 */ }

Today Normalize is at 7.0.0 and has going on 30,000 GitHub stars. It's wicked popular.

So... resets can be opinionated?

We've seen lots of different takes on CSS resets and we've seen fundamental shifts in the approach, so I think it's fair to say CSS resets can take an opinionated stance.

Let's consider some ways...

  • Does the reset touch every single possible element? Or a subset of elements? How does it decide which elements to touch and which not to?
  • What properties are changed? Only ones with cross-browser differences? Or some other criteria, like the similarity to other elements that needed changes? Is it OK to apply properties to elements that don't have cross-browser issues in the name of consistency and efficiency?
  • Do you try to preserve the spirit of the user agent stylesheet? Sensible defaults?
  • Do you apply any properties that don't have cross-browser issues could be considered beneficial to "reset", like typographic defaults or box-sizing?
  • Do you include "toolbox" classes for common needs? Or leave that for other projects to handle?
  • Are you concerned about the size of it?
  • Do you use a preprocessor or any other tooling?

Take a look at Vanilla CSS Un-Reset. Loads of opinions here, starting with the idea that it's meant to re-style elements after you un-style then with a reset. It set's the body font size in pt, set a very specific monospace font stack, includes a ol ol ol ol selector, a clearfix, and alignment helper classes. No judgment there. People make things to help with their own problems and I'm sure this was helpful to the creator. But we can see the opinions shine through there.

Now look at MiniReset.css. Very different! It does wipe out type styles "so that using semantic markup doesn't affect the styling", but leaves some defaults in place on purpose "so that buttons and inputs keep their default layout", puts in some things that don't have cross-browser problems but are useful globally (box-sizing), and adds some minor responsive design helpers.

Totally different set of opinions there.

Jonathan Neal created a reset called santize.css that is very clear about it's opinions. Search for the word "opinionated" in the source code and you'll see it 19 times. All these are choices that Jonathan made based on research and what seem to be modern best practices, and no doubt sprinkled with his own needs and desires for what should be in a reset.

/* * Remove the text shadow on text selections (opinionated). * 1. Restore the coloring undone by defining the text shadow (opinionated). */ ::-moz-selection { background-color: #b3d4fc; /* 1 */ color: #000000; /* 1 */ text-shadow: none; } ::selection { background-color: #b3d4fc; /* 1 */ color: #000000; /* 1 */ text-shadow: none; } The word "reset"

Personally, I think it's useful to think of all of them under the same umbrella term and just be aware of the philosophical differences. But, Normalize intentionally separates itself:

A modern, HTML5-ready alternative to CSS resets

Sanitize calls itself a CSS library and doesn't use the word "reset" anywhere except to cite the Meyer reset.


Reboot is interesting as it's perhaps the newest player in this world. It's file history dates back to 2015, which is probably related to Bootstrap 4 taking a while to drop after Bootstrap 3. Reboot doesn't have its own repo, it's a part of Bootstrap. Here's the direct file and the docs.

The way they think about it is interesting:

Reboot builds upon Normalize, providing many HTML elements with somewhat opinionated styles using only element selectors. Additional styling is done only with classes. For example, we reboot some <table> styles for a simpler baseline and later provide .table, .table-bordered, and more.

You can have a class that does styling, but if you use a reset, you don't have to overload that class with reset styles that handle cross-browser consistency issues.

// // Tables // table { border-collapse: collapse; // Prevent double borders } caption { padding-top: $table-cell-padding; padding-bottom: $table-cell-padding; color: $text-muted; text-align: left; caption-side: bottom; } th { // Matches default `<td>` alignment by inheriting from the `<body>`, or the // closest parent with a set `text-align`. text-align: inherit; }

It's definitely opinionated, but in a way that rolls with Bootstrap nicely. The fact that it's buried within Bootstrap is pretty good signaling this is designed for that world, not as a drop-in for any project. That said, I did my best to compile a straight CSS version of it here.

Tailoring a reset based on browser support

So long as we're talking about the past and future of resets, it's worth mentioning Browserslist again, which is a standardized format for declaring what browsers/versions a project supports.

A reset could be built in a such a way that the things it includes know why they are there. Exactly what browser and version it is there to support. Then if browserslist configuration says that particular browser isn't supported by this project anyway, that CSS could be removed.

That's what PostCSS Normalize does.

Reboot, Resets, and Reasoning is a post from CSS-Tricks


Css Tricks - Fri, 10/20/2017 - 10:41am

It was awesome to hear Charlotte Dann on CodePen Radio the other day, who is Kickstarting a new jewelry business. The idea is that you draw your own jewelry (everything you draw looks awesome because it's on this interesting hexagon grid) and then it gets actually made. This tying together of her passions sprang to life on CodePen.

Direct Link to ArticlePermalink

Hexatope is a post from CSS-Tricks

Breaking down CSS Box Shadow vs. Drop Shadow

Css Tricks - Fri, 10/20/2017 - 5:57am

Drop shadows. Web designers have loved them for a long time to the extent that we used to fake them with PNG images before CSS Level 3 formally introduced them to the spec as the box-shadow property. I still reach for drop shadows often in my work because they add a nice texture in some contexts, like working with largely flat designs.

Not too long after box-shadow was introduced, a working draft for CSS Filters surfaced and, with it, a method for drop-shadow() that looks a lot like box-shadow at first glance. However, the two are different and it's worth comparing those differences.

For me, the primary difference came to light early on when I started working with box-shadow. Here's a simple triangle not unlike the one I made back then.

See the Pen CSS Caret by CSS-Tricks (@css-tricks) on CodePen.

Let's use this to break down the difference between the two.

Box Shadow

Add a box-shadow on that bad boy and this happens.

See the Pen CSS Caret Box Shadow by CSS-Tricks (@css-tricks) on CodePen.

It's annoying, but makes sense. CSS uses a box model, where the element's edges are bound in the shape of a rectangle. Even in cases where the shape of the element does not appear to be a box, the box is still there and that is was box-shadow is applied to. This was my "ah-ha moment" when understanding the box in box-shadow.

CSS Filter Drop Shadow

CSS Filters are pretty awesome. Take a gander at all the possibilities for adding visual filters on elements and marvel at how CSS suddenly starts doing a lot of things we used to have to mockup in Photoshop.

Filters are not bound to the box model. That means the outline of our triangle is recognized and the transparency around it is ignored so that the intended shape receives the shadow.

See the Pen CSS Caret Drop Shadow by CSS-Tricks (@css-tricks) on CodePen.

Deciding Which Method to Use

The answer is totally up to you. The simple example of a triangle above might make it seem that filter: drop-shadow() is better, but it's not a fair comparison of the benefits or even the possibilities of both methods. It's merely an illustration of their different behaviors in a specific context.

Like most things in development, the answer of which method to use depends. Here's a side-by-side comparison to help distinguish the two and when it might be best to choose one over the other.

Box Shadow Drop Shadow Specification CSS Backgrounds and Borders Module Level 3 Filter Effects Module Level 1 Browser Support Great Good Supports Spread Radius Yes, as an optional fourth value No Blur Radius Calculation is based on a pixel length Calculation is based on the stdDeviation attribute of the SVG filter Supports inset shadows Yes No Performance Not hardware accelerated Hardware accelerated in browsers that support it. It's a heavy lift without it. Wrapping Up

The difference between box-shadow and filter: drop-shadow() really boils down to the CSS box model. One sees it and the other disregards it. There are other differences that distinguish the two in terms of browser support, performance and such, but the way the two treat the box model is the key difference.

Update: Amelia identified another key difference in the comments where the spread of the radius for drop-shadow() is calculated differently than box-shadow and even that of text-shadow. That means that the spread radius you might specify in box-shadow is not one-to-one with the default spread value for drop-shadow, so the two are not equal replacements of one another in some cases.

Let's cap this off with a few other great examples illustrating that. Lennart Schoors also has a nice write-up with practical examples using tooltips and icons that we previously called out.

See the Pen Drop-shadow vs box-shadow (2) by Kseso (@Kseso) on CodePen.

See the Pen box-shadow & drop-shadow by qnlz (@qnlz) on CodePen.

See the Pen Drop-shadow vs box-shadow (3) en png´s by Kseso (@Kseso) on CodePen.

Breaking down CSS Box Shadow vs. Drop Shadow is a post from CSS-Tricks

New variable fonts from Adobe Originals

Nice Web Type - Thu, 10/19/2017 - 7:18am

Photoshop and Illustrator announced plenty of new features at Adobe MAX this week, include some exciting typographic features we’ve been anticipating: support for OpenType variable fonts.

This new font format allows users to customize the styles within a typeface design, effectively giving them an entire family of fonts in a single file. We’ve included a few Adobe Originals families with this release of Illustrator and Photoshop to make it easier for you to explore what variable fonts can do.

Here’s a quick walkthrough of this week’s typographic updates from the Photoshop team.

Don’t miss the Illustrator announcement, either, which introduces its own nifty typographic controls.

We chose six families to best show what the new format will allow, and how the possibilities may differ from one typeface to another. Five of these are from our Variable Concept font collection, allowing you to play with the full variable design space on some of our most popular Adobe Originals families (although you’ll only have a limited character set for now).

  • Myriad Variable Concept allows you to see how the weight and width styles of Myriad Pro can interact as you adjust each property.
  • Acumin Variable Concept allows you to adjust weight, width, and even the slant angle, combining all of Acumin’s 90 variants in a single dynamic font file.
  • Minion Variable Concept is a special treat — a preview of a major update to the Minion family that will be released in the near future. Although you won’t yet get to see all the features of the new Minion, you’ll be able to adjust its revamped weight and optical size settings with this version.

From the Source superfamily, Source Sans Variable, Source Serif Variable, and Source Code Variable all allow you to play with the weight range in each design, and they also contain the complete character set of the Pro versions.

In addition to using the Source Variable families in Photoshop and Illustrator, you can download them from our GitHub page so you can try them out in other applications and environments as the support for variable fonts becomes more widespread. We’ll keep you posted as that support develops! Check out our roundup of variable fonts news and follow the discussions on TypeDrawers.

MDN Product Advisory Board

Css Tricks - Thu, 10/19/2017 - 5:09am

We all know and love MDN for already being the best documentation for web features out there. It looks like it's poised to get even better with Google and Microsoft both joining a new board.

Mozilla's vision for the MDN Product Advisory Board is to build collaboration that helps the MDN community collectively maintain MDN as the most comprehensive, complete, and trusted reference documenting the most important aspects of modern browsers and web standards.

Interesting none of them mentioned WebPlatform, the previous attempt at this that kinda fizzled out. This effort seems a little more likely to succeed as it already has a successful foundation, actual staff, and a benevolent dictator in Mozilla. It's great to see browsers complete on user features but cooperate on standards and education.

Worth a shout that we dabble in "docs" for CSS features ourselves here at CSS-Tricks with the Almanac, but if anything in there is worth taking for a unified resource like MDN, be our guest. Not to mention everything public on CodePen is MIT, and there are loads of Pens that demonstrate web features wonderfully. For instance, that's why I built this one.

Direct Link to ArticlePermalink

MDN Product Advisory Board is a post from CSS-Tricks

Designing Hebrew Type

Typography - Thu, 10/19/2017 - 5:02am

Just to be clear from the start: I don’t speak Hebrew. When I first started working with Hebrew type, I couldn’t tell one letter from another, or even whether the page was right-side-up or upside-down. In short, I was completely unqualified to work with the Hebrew alphabet. As odd as it may seem, though, there […]

Sponsored by Hoefler & Co.

Designing Hebrew Type

Designing Hebrew Type

Typography - Thu, 10/19/2017 - 5:02am

Just to be clear from the start: I don’t speak Hebrew. When I first started working with Hebrew type, I couldn’t tell one letter from another, or even whether the page was right-side-up or upside-down. In short, I was completely unqualified to work with the Hebrew alphabet.

As odd as it may seem, though, there were some advantages to my lack of knowledge. Without any preconceptions, I was open to all possible design options, and I was prepared to undertake serious research. Most importantly, I understood that the project would be a long-term commitment, and I was prepared to give it as much time as it needed.

Even so, the question remains whether an outsider can make a useful or inspiring contribution to a script that he is not familiar with. I am a firm believer that it is possible, and in fact many great advances in type design and typography have been made by people who were outsiders or even illiterate, since the skills required to speak a language are quite different from the skills required to work with its visual aspect. Of course, an outsider has to work harder to learn a script’s history, traditions and conventions, mapping out its expressive potential. I knew that in the process of exploring Hebrew type I would make silly mistakes that would never even occur to a native designer, that coming to understand the historical models, references and writing tools would be a long journey, but having already designed Cyrillic, Greek, Armenian, Inuktitut and Arabic typefaces, I was willing to take on this challenge.

Part of my motivation came from discussions with Israeli friends who told me that the most useful Hebrew typefaces were designed in the early 20th century. The typefaces of Rafael Frank (1867–1920), Henry Friedlaender (1904–1996), Ismar David (1910–1996), and Zvi Narkiss (1921–2010) have come to define the look of modern Hebrew typography, and even now, many decades later, publishers continue to return to them for their legibility and usefulness for setting large quantities of text. Newer typefaces have never quite overtaken the three most popular, Frank Rühl (C.F. Rühl, 1910), David (Intertype, 1954), and Hadassah (Amsterdam type foundry, 1958).

Frank Rühl (C.F. Rühl, 1910), David (Intertype, 1954), and Hadassah (Amsterdam Type Foundry, 1958)

I was also motivated by my interest in Arabic script. I’ve spent a decade working with Arabic type, and more recently, together with Kristyan Sarkis, started a foundry specialising in the development of original, contemporary, authentic Arabic typefaces. Arabic designers may have little motivation to deal with Hebrew and vice versa, but the fact is that Arabic and Hebrew are related, and designing them in unison can create very useful type systems for the region, so I became interested in designing typefaces that support both scripts, as well as Latin.

The project was not to create a particular style or a typeface family, but rather a complete Hebrew type programme: high-contrast (based on Greta Text Latin), low-contrast (based on Greta Sans Latin) and display typefaces.

I started with the most difficult task, designing a newspaper typeface for running text at small sizes, as I thought that designing a more complex style would provide future solutions to the simpler styles such as display fonts. Although I used Greta Text as a starting point, my intention was not to emulate any of its particular structural details, but rather to create an authentic, contemporary Hebrew typeface with similar formal parameters (width, weight, proportions, spacing, curve tension, texture) informed by Hebrew conventions.

It soon became apparent that I needed a consultant. I approached New York typographer Misha Beletsky, who was extremely helpful in setting up the direction and construction principles of a new typeface. He is a self-described purist, a strong proponent of following historical models, and critical of the mix-and-match approach which has became so popular in multi-script typography. At his suggestion, I looked closely at Friedlaender’s Hadassah as a model of a Hebrew typeface designed for legibility. I also studied Adi Stern’s MA dissertation ‘Some Guidelines and Recommendations for the Design of a Hebrew Book Typeface’, which was helpful in gaining a better understanding of the proportions of Hebrew characters. I collected most of the available books on Hebrew typography and various calligraphic styles and dug through them in search of solutions.

Early sketches of Hebrew letter terminations

The Hebrew script is deceptively simple. It consists of just 22 characters, has no upper/lower case distinction, no required ligatures and no contextual shapes. Very quickly, however, I encountered two major problems. The first was that my idea of letter proportions, the balance of forms and counter-forms, ran completely contrary to the expectations of Hebrew readers. Following the optical rules that I was used to, I made complex shapes such as ? and ? wider, and simpler shapes such as ? and ? narrower. This looked odd to native designers, and retraining my eyes and brain took years of work. The second biggest problem were the serifs. Serifs are foreign to most non-Latin scripts, but the fairly high contrast of Greta Text requires some ending at the end of the strokes. I tried dozens of solutions for stroke terminations, and none seemed to work. Calligraphic endings seemed more natural to high-contrast Hebrew letters, but alien to the crisp lines of Greta Text. Sharp geometric endings fit the design of Greta, but looked out of place on the Hebrew characters. In the end I settled on smaller, stylised endings inspired by the broad-nib pen. I discovered that the comparatively homogenous structure of Hebrew letters made it necessary to vary the endings slightly in order to avoid a monotonous texture in large blocks of text, and that individualising the terminations also helped to increase legibility and differentiate the glyphs.

In 2015, after four years of slow, continuous work, I was invited by professor Adi Stern to give a type design workshop at the Bezalel Academy of Arts and Design in Jerusalem. I took advantage of the opportunity to show Adi my work-in-progress and seek his feedback. He was encouraging, which gave me confidence to continue the work. I also met Yanek Iontef, an experienced and respected Israeli type designer, and now also my friend. And most importantly, at least for this project, I met another teacher from Bezalel, Michal Sahar.

Michal is both an established type designer with an eye for innovation, as well as a skilled and celebrated book designer. During my visit she mentioned that she was interested in Fedra Serif, and to my astonishment had already sketched a Hebrew version. She quickly became a close collaborator, and consultant on all our Hebrew types.

Early variations of the letter alef.
The underlined version was proposed by Michal Sahar, and finally implemented in Greta Text Hebrew.

Back in The Hague, I welcomed Daniel Berkovic, a Bezalel student, for a month-long internship in our office. Daniel made a significant contribution to Greta Text Hebrew, first polishing my ill-conceived proportions, then going further and proposing new solutions to letters that I had struggled with (? ,? and ?). Together we also completed Greta Sans Hebrew and submitted it to the Type Directors Club in NYC, where it won the Certificate of Excellence for 2016.

In spite of this international recognition I felt that the project still hadn’t quite achieved its goal, and I continued working on the Greta Text version, again with Daniel’s help. I went back and forth, sometimes accepting his suggestions, sometimes feeling that they transformed the project into something else. Daniel Grumer, who came to Hague to study at the Type & Media programme also contributed thoughtful advice, and worked with me on November Hebrew, which became Typotheque’s first released Hebrew typeface. Daniel also chose to work on Zico, a robust Slab serif which is typically challenging to interpret in Hebrew, where serifs look odd. He did a great job, and made Zico Slab Hebrew look natural. In 2016 I approached Yanek Iontef to work on the Hebrew extension of the Bodoni-inspired Parmigiano. All of these projects, while completely different, served as important lessons for me, allowing me to see Greta Hebrew from a different perspective. In the meantime, Michal Sahar completed Fedra Serif Hebrew and Fedra Sans Hebrew, using them in a number of book projects and designing unique cursive styles.

Finally in 2017, spurred by the completion of November, Parmigiano and Fedra, I felt that it was also time to finish Greta, the project which had started my interest in Hebrew in the first place. I compared different versions, prepared notes and shared them with Michal.

A proof of Greta Text from 2015, two years before the official release. The author believed that it lacked the personality of the original, and invited Michal Sahar to collaborate on the project.

After six years of work it seemed to me that the Hebrew letter shapes were well executed but lacked personality, that I had managed to craft a legible typeface, but one perhaps too generically correct, too much driven by convention, lacking Greta’s personality. Michal responded not with just words, but with completely redrawn characters. It was a joy to see solutions that had escaped me, not just a good Hebrew typeface, but a deft adaptation of Greta Text.

In the world of Hebrew script I will always remain an outsider in spite of the experience and insight that I have gained through these projects. This long process allowed me to discover my own limits, to realise when to seek the help and advice of others. I thank all my collaborators for their patience and their contribution and in making those typefaces what they should be. I am pleased to introduce all new Typotheque Hebrew collection.

Sponsored by Hoefler & Co.

Designing Hebrew Type

5 Tips for Starting a Front-End Refactor

Css Tricks - Thu, 10/19/2017 - 12:20am

For the last two weeks, I've been working on a really large refactor project at Gusto and I realize that this is the first time that a project like this has gone smoothly for me. There haven't been any kinks in the process, it took about as much time as I thought it would, and no-one appears to be mad at me. In fact, things have gone almost suspiciously well. How did this happen and what was the issue?

Well, we had a problem with how our CSS was organized. Some pages in our app loaded Bootstrap and some didn't. Others were loading only our app styles and some weren't loading the styles we served from our component library, a separate repo that includes all our forms, buttons, and variables, etc. This led to all sorts of design inconsistencies but most important of all it wasn't clear how to write CSS in our app. Do the component library styles override Bootstrap? Does Bootstrap override the app styles? It was scary stuff.

The goal was a rather complex one then. First, I needed to figure out how our styles were loaded in the app. Second, I wanted to remove Bootstrap from our node_modules and make a new Sass file with all those styles. Third, I then had to remove all our Bootstrap styles and place them into the component library where we would be able to refactor every line of Bootstrap into each individual component (so all the styles for the Tabs.jsx component was styled only by the Tabs.scss file). All of this work should reduce the amount of CSS we write by thousands of lines and generally make our codebase more readable and much more developer-friendly for the future.

However, before I started I knew that everything would have to be extraordinarily organized because this would involve a big shakeup in terms of our codebase. There will be spreadsheets! There will be a single, neat and tidy pull request! Lo, and behold! There will be beautiful, glorious documentation for everyone to read.

So here are some tips on making sure that big refactor projects go smoothly, based on my experience working on this large and complex codebase. Let's begin!

Tip #1: Gather as much data as you can

For this project, I needed to know a bunch of stuff beforehand, namely in the form of data. This data would then serve as metrics for success because if I could show that we could safely remove 90% of the CSS in the app then that's a huge win that the rest of the team can celebrate.

My favorite tool for refactoring CSS these days is Chrome's Coverage tab in DevTools and that's because it can show you just how much CSS is applied to any given page. Take a look here:

And it showed me everything I needed: the number of CSS files we generated, the overall size of those files and how much CSS we can safely delete from that page.

Tip #2: Make a list of everything you have to do

The very first refactor project I worked on at Gusto was a complete nightmare because I jumped straight into the codebase and started blowing stuff up. I'd remove a class here, an element there, and soon enough I found myself having changed thousands of lines of CSS and breaking hundreds of automated tests. Of course, all of this was entirely my fault and it caused a bunch of folks to get mad at me, and rightly so!

This was because I hadn't written down a list of everything that I wanted to do and the order I needed to do it in. Once you do this you can begin to understand just how big the scope of the project really is.

Tip #3: Keep focused

The second reason I made such a huge mistake on my first refactor project was that I wasn't focused on a very specific task. I'd just change things depending on how I felt, which isn't any way to manage a project.

But once you've made that list of tasks you can then break it down even further into each individual pull request that you'll have to make. So you might already be doing this but I would thoroughly recommend trying to keep each commit as focused and as small as you can. You'll need to be patient, a quality I certainly lack, and determined. Slow, small steps during a refactoring project is always better than a single large, unfocused pull request with dozens of unrelated commits in them.

If you happen to notice a new issue with the CSS or with the design as you're refactoring then don't rush to fix it, trust me. It'll be a distraction. Instead, focus on the task at hand. You can always return to that other thing later.

Tip #4: Tell everyone you're working on this project

This might just be something that I struggle with personally but I never realized until recently just how much of front-end development is a community effort. The real difficulty of the work doesn't depend on whether you know the fanciest CSS technique, but rather how willing you are to communicate with the rest of your team.

Tell everyone you're working on this project to make sure that there isn't anything you overlooked. Refactoring large codebases can lead to edge cases that can then lead to overwhelmingly painful customer-facing problems. In our case, if I messed up the CSS then potentially thousands of people wouldn't be paid that week by our app. Every little bit of information can only help you make this refactor process as efficient and as smooth as possible.

Tip #5: Document as much as you can

I really wish I could find the precise quote, but somewhere deep in Ellen Ullman's excellent book Life in Code she writes about how programming is sort of like a bad translation of a book. Outside the codebase we have ideas, thoughts, knowledge. And when we convert those ideas into code something inexplicable is lost forever, regardless of how good you are at programming.

amzn_assoc_tracking_id = "csstricks-20"; amzn_assoc_ad_mode = "manual"; amzn_assoc_ad_type = "smart"; amzn_assoc_marketplace = "amazon"; amzn_assoc_region = "US"; amzn_assoc_design = "enhanced_links"; amzn_assoc_asins = "0374534519"; amzn_assoc_placement = "adunit"; amzn_assoc_linkid = "195e7b7f883bf4a3b3340e6144828552";

One small tip that helps that translation process is writing really detailed messages in the pull request itself. Why are you doing this? How are you going about it? How do you plan to test that your refactor didn't break everything? That's precisely the sort of information that will help someone in the future learn more about your original intent and what your goals were.

Wrapping up

I learnt all this stuff the really hard, long stupid way. But if you happen to follow these tips then large front-end projects are bound to go a whole lot smoother, both for you and your team. I guarantee it.

5 Tips for Starting a Front-End Refactor is a post from CSS-Tricks

Sponsor: Media Temple

Css Tricks - Thu, 10/19/2017 - 12:03am

(This is a sponsored post.)

Media Temple is my web host here at CSS-Tricks. I still remember what it was like buying my first web hosting, pointing a domain name to it, FTPing into that server, and having the files I put there appear in the web browser. Powerful stuff, kids. Watch out or you might try to turn it into a career!

I've upgraded my server a few times since then, but it's still a pretty standard grade Media Temple server that happily hosts this site with little trouble. When there is anything weird, I use the same support system to get help as is available to anybody else, and they always go out of there way to investigate what's going on and explain what's up.

Direct Link to ArticlePermalink

Sponsor: Media Temple is a post from CSS-Tricks

A Look Back at the History of CSS

Css Tricks - Wed, 10/18/2017 - 7:00am

When you think of HTML and CSS, you probably imagine them as a package deal. But for years after Tim Berners-Lee first created the World Wide Web in 1989, there was no such thing as CSS. The original plan for the web offered no way to style a website at all.

There's a now-infamous post buried in the archives of the WWW mailing list. It was written by Marc Andreessen in 1994, who would go on to co-create both the Mosaic and Netscape browsers. In the post, Andreessen remarked that because there was no way to style a website with HTML, the only thing he could tell web developers when asked about visual design was, “sorry you're screwed.

10 years later, CSS was on its way to full adoption by a newly enthused web community. *W**hat happened along the way?*

Finding a Styling Language

There were plenty of ideas for how the web could theoretically be laid out. However, it just was not a priority for Berners-Lee because his employers at CERN were mostly interested in the web as a digital directory of employees. Instead, we got a few competing languages for web page layout from developers across the community, most notably from Pei-Yaun Wei, Andreesen, and Håkon Wium Lie.

Take Pei-Yuan Wei, who created the graphical ViolaWWW Browser in 1991. He incorporated his own stylesheet language right into his browser, with the eventual goal of turning this language into an official standard for the web. It never quite got there, but it did provide some much-needed inspiration for other potential specifications.

ViolaWWW upon release

In the meantime, Andreessen had taken a different approach in his own browser, Netscape Navigator. Instead of creating a decoupled language devoted to a website's style, he simply extended HTML to include presentational, unstandardized HTML tags that could be used to design web pages. Unfortunately, it wasn't long before web pages lost all semantic value and looked like this:

<MULTICOL COLS="3" GUTTER="25"> <P><FONT SIZE="4" COLOR="RED">This would be some font broken up into columns</FONT></P> </MULTICOL>

Programmers were quick to realize that this kind of approach wouldn't last long. There were plenty of ideas for alternatives. Like RRP, a stylesheet language that favored abbreviation and brevity, or PSL96 a language that actually allowed for functions and conditional statements. If you’re interested in what these languages looked like, Zach Bloom wrote an excellent deep dive into several competing proposals.

But the idea that grabbed everyone's attention was first proposed by Håkon Wium Lie in October of 1994. It was called Cascading Style Sheets, or just CSS.

Why We Use CSS

CSS stood out because it was simple, especially compared to some of its earliest competitors.

window.margin.left = 2cm = times h1.font.size = 24pt 30%

CSS is a declarative programming language. When we write CSS, we don't tell the browser exactly how to render a page. Instead, we describe the rules for our HTML document one by one and let browsers handle the rendering. Keep in mind that the web was mostly being built by amateur programmers and ambitious hobbyists. CSS followed a predictable and perhaps more importantly, forgiving format and just about anyone could pick it up. That's a feature, not a bug.

CSS was, however, unique in a singular way. It allowed for styles to cascade. It's right there in the name. Cascading Style Sheets. The cascade means that styles can inherit and overwrite other styles that had previously been declared, following a fairly complicated hierarchy known as specificity. The breakthrough, though, was that it allowed for multiple stylesheets on the same page.

See that percentage value above? That's actually a pretty important bit. Lie believed that both users and designers would define styles in separate stylesheets. The browser, then, could act as a sort of mediator between the two, and negotiate the differences to render a page. That percentage represents just how much ownership this stylesheet is taking for a property. The less ownership, the more likely it was to be overwritten by users. When Lie first demoed CSS, he even showed off a slider that allowed him to toggle between user-defined and developer-defined styles in the browser.

This was actually a pretty big debate in the early days of CSS. Some believed that developers should have complete control. Others that the user should be in control. In the end, the percentages were removed in favor of more clearly defined rules about which CSS definitions would overwrite others. Anyway, that's why we have specificity.

Shortly after Lie published his original proposal, he found a partner in Bert Bos. Bos had created the Argo browser, and in the process, his own stylesheet language, pieces of which eventually made its way into CSS. The two began working out a more detailed specification, eventually turning to the newly created HTML working group at the W3C for help.

It took a few years, but by the end of 1996, the above example had changed.

html { margin-left: 2cm; font-family: "Times", serif; } h1 { font-size: 24px; }

CSS had arrived.

The Trouble with Browsers

While CSS was still just a draft, Netscape had pressed on with presentational HTML elements like multicol, layer, and the dreaded blink tag. Internet Explorer, on the other hand, had taken to incorporating some of CSS piecemeal. But their support was spotty and, at times, incorrect. Which means that by the early aughts, after five years of CSS as an official recommendation, there were still no browsers with full CSS support.

That came from kind of a strange place.

When Tantek Çelik joined Internet Explorer for Macintosh in 1997, his team was pretty small. A year later, he was made the lead developer of the rendering engine at the same as his team was cut in half. Most of the focus for Microsoft (for obvious reasons) was on the Windows version of Internet Explorer, and the Macintosh team was mostly left to their own devices. So Starting with the development of version 5 in 2000, Çelik and his team decided to put their focus where no one else was, CSS support.

It would take the team two years to finish version 5. During this time, Çelik spoke frequently with members of the W3C and web designers using their browser. As each piece slid into place, the IE-for-Mac team verified on all fronts that they were getting things just right. Finally, in March of 2002, they shipped Internet Explorer 5 for Macintosh. The first browser with full CSS Level 1 support.

Doctype Switching

But remember, the Windows version of Internet Explorer had added CSS to their browser with more than a few bugs and a screwy box model, which describes the way elements are calculated and then rendered. Internet Explorer included attributes like border and padding inside the total width and height of an element. But IE5 for Mac, and the official CSS specification called for these values to be added to the width and height. If you ever played around with box-sizing you know exactly the difference.

Çelik knew that in order to make CSS work, these differences would need to be reconciled. His solution came after a conversation with standards-advocate Todd Fahrner. It's called doctype switching, and it works like this.

We all know doctypes. They go at the very top of our HTML documents.

<!DOCTYPE html>

But in the old days, they looked like this:


That's an example of a standards-compliant doctype. The //W3C//DTD HTML 4.0//EN is the crucial bit. When a web designer added this to their page the browser would know to render the page in "standards mode," and CSS would match the specification. If the doctype was missing, or an out of date one was in use, the browser would switch to "quirks mode" and render things according to the old box model and with old bugs intact. Some designers even intentionally opted to put their site into quirks mode in order to get back the older (and incorrect) box model.

Eric Meyer, sometimes referred to as the godfather of CSS, has gone on record and said doctype switching saved CSS. He's probably right. We would still be using browsers packed with old CSS bugs if it weren't for that one, simple trick.

The Box Model Hack

There was one last thing to figure out. Doctype switching worked fine in modern browsers on older websites, but the box model was still unreliable in older browsers (particularly Internet Explorer) for newer websites. Enter the Box Model Hack, a clever trick from Çelik that took advantage of a little-used CSS attribute called voice-family to trick browsers and allow for multiple widths and heights in the same class. Çelik instructed authors to put their old box model width first, then close the tag in a small hack with voice-family, followed by their new box model width. Sort of like this:

div.content { width: 400px; voice-family: ""}""; voice-family: inherit; width: 300px; }

Voice-family was not recognized in older browsers, but it did accept a string as its definition. So by adding an extra } older browsers would simply close the CSS rule before ever getting to that second width. It was simple and effective and let a lot of designers start experimenting with new standards quickly.

The Pioneers of Standards-Based Design

Internet Explorer 6 was released in 2001. It would eventually become a major thorn in the side of web developers everywhere, but it actually shipped with some pretty impressive CSS and standards support. Not to mention its market share hovering around 80%.

The stage was set, the pieces were in place. CSS was ready for production. Now people just needed to use it.

In the 10 years that the web hurtled towards ubiquity without a coherent or standard styling language, it's not like designers had simply stopped designing. Not at all. Instead, they relied on a backlog of browser hacks, table-based layouts, and embedded Flash files to add some style when HTML couldn't. Standards-compliant, CSS-based design was new territory. What the web needed was some pioneers to hack a path forward.

What they got was two major redesigns just a few months apart. The first from Wired followed soon after by ESPN.

Douglas Bowman was in charge of the web design team for Wired magazine. In 2002, Bowman and his team looked around and saw that no major sites were using CSS in their designs. Bowman felt almost an obligation to a web community that looked to Wired for examples of best practices to redesign their site using the latest, standards-compliant HTML and CSS. He pushed his team to tear everything down and redesign it from scratch. In September of 2002, they pulled it off and launched their redesign. The site even validated.

ESPN released their site just a few months later, using many of the same techniques on an even larger scale. These sites took a major bet on CSS, a technology that some thought might not even last. But it paid off in a major way. If you pulled aside any of the developers that worked on these redesigns, they would give you a laundry list of major benefits. More performant, faster design changes, easier to share, and above all, good for the web. Wired even did daily color changes in the beginning.

Dig through the code of these redesigns, and you'd be sure to find some hacks. The web still only lived on a few different monitor sizes, so you may notice that both sites used a combination of fixed width columns and relative and absolute positioning to slot a grid into place. Images were used in place of text. But these sites laid the groundwork for what would come next.

CSS Zen Garden and the Semantic Web

The following year, in 2003, Jeffrey Zeldman published his book Designing with Web Standards, which became a sort of handbook for web designers looking to switch to standards-based design. It kicked off a legacy of CSS techniques and tricks that helped web designers imagine what CSS could do. A year later, Dave Shea launched the CSS Zen Garden, which encouraged designers to take a basic HTML page and lay it out differently using just CSS. The site became a showcase of the latest tips and tricks, and went a long way towards convincing folks it was time for standards.

Slowly but surely, the momentum built. CSS advanced, and added new attributes. Browsers actually raced to implement the latest standards, and designers and developers added new tricks to their repertoire. And eventually, CSS became the norm. Like it had been there all along.

Enjoy learning about web history? Jay Hoffmann has a weekly newsletter called The History of the Web you can sign up for here.

A Look Back at the History of CSS is a post from CSS-Tricks

On-Site Search

Css Tricks - Wed, 10/18/2017 - 3:13am

CSS-Tricks is a WordPress site. WordPress has a built-in search feature, but it isn't tremendously useful. I don't blame it, really. Search is a product onto itself and WordPress is a CMS company, not a search company.

You know how you can make a really powerful search engine for your site?

Here you go:

<form action="" target="_blank" type="GET"> <input type="search" name="q"> <input type="submit" value="search"> </form>

Just a smidge of JavaScript trickery to enforce the site it searches:

var form = document.querySelector("form"); form.addEventListener("submit", function(e) { e.preventDefault(); var search = form.querySelector("input[type=search]"); search.value = " " + search.value; form.submit(); });

I'm only 12% joking there. I think sending people over to Google search results for just your site for their search term is perfectly acceptable. Nobody will be confused by that. If anything, they'll be silently pleased.

Minor adjustments could send them to whatever search engine. Like DuckDuckGo:


  1. They will leave your site
  2. They will see ads

To prevent #1, Google has long-offered a site search product where you can create and configure a custom search engine and embed it on your own site.

There has been lots of news about Google shutting down that service. For example, "Google site search is on the way out. Now what?" Eeek! This was quite confusing to me.

Turns out, what they are really are shutting down what is known as Google Site Search (GSS), which is an enterprise product. It shuts down entirely on April 1, 2018. Google has another product called Google Custom Search Engine (CSE) that doesn't seem to be going anywhere.

CSE is the thing I was using anyway. It has a free edition which has ads, and you can pay to remove them, although the pricing for that is also very confusing. I literally can't figure it out. For a site like CSS-Tricks, it will be hundreds or possibly thousands a year, best I can tell. Or you can hook up your own AdSense and at least attempt to make money off the ads that do show.

In the wake of all that, I thought I'd try something new with search. Algolia is a search product that I'd heard of quite a few people try, and it seems pretty beloved. With a little help from the wonderfully accommodating Algolia team, we've had that going for the last few months.

If we were to set up an implementation difficulty scale where my HTML/JavaScript form up there is a 1 and spinning up your own server and feeding Solr a custom data structure and coming up with your own rating algorithms is a 10, Algolia is like a 7. It's pretty heavy duty nerdy stuff.

With Alogolia, you need to bring all your own data and stucture and get it over to Algolia, as all the search magic happens on their servers. Any new/changed/deleted data needs to be pushed there too. It's not your database, but generally any database CRUD you do will need to go to Algolia too.

On that same difficulty scale, if you're adding Algolia to a WordPress site, that goes down to a 3 or 4. WordPress already has it's own data structure and Algolia has a WordPress plugin to push it all to them and keep it all in sync. It's not zero work, but it's not too bad. The plugin also offers a UI/UX replacement over the default WordPress search form, which offers "instant results" as a dropdown. It really is amazingly fast. Submit the form anyway, and you're taken to a full-page search results screen that is also taken over by Algolia.

For disclosure, I'm a paying customer of Algolia and there is no sponsorship deal in place.

It's a pretty damn good product. As one point of comparison, I've gotten exactly zero feedback on the switch. Nobody has written in to tell me they noticed the change in search and now they can't find things as easily. And people write in to tell me stuff like that all the time, so not-a-peep feels like a win.

I'm paying $59 a month for superfast on-page search with no ads.

It's almost a no-brainer win, but there are a few downsides. One of them is the ranking of search results. It's pretty damn impressive out of the box, returning a far more relevant set of results than native WordPress search would. But, no surprise, it's no Google. Whatever internal magic is happening is trying it's best, but it just doesn't have the data Google has. All it has is a bunch of text and maybe some internal linking data.

There are ways to make it better. For example, you can hook up your Google Analytics data to Algolia, essentially feeding it popularity data, so that Algolia results start to look more like Google results. It's not a trivial to set up, but probably worth it!


What do y'all use for search on your sites?

On-Site Search is a post from CSS-Tricks

Introducing visual search on Typekit

Nice Web Type - Wed, 10/18/2017 - 3:00am

Whether your inspiration comes from signage, posters, flat artwork, or that weird billboard you drive by all the time, our visual search feature brings a new dimension to the way you find type with Typekit. We launched an Early Access preview for visual search back in September, and today we’re very proud to announce that we’ve rolled these capabilities out to everyone.

Start with a photo of type you’ve seen, and send it through visual search to find the fonts in our inventory that are visually similar to it. From your desktop or your mobile device, you can highlight a specific line of type from your photo to control the search, and then sync the fonts you like best right away.

Want visual search from Typekit in your app?

We’ve made the APIs available, too. Learn more.

Start a visual search from any page on Typekit — drag & drop, or upload directly on mobile.

Adobe Capture CC also got a makeover for MAX and now includes Type Capture, a new feature powered by the same Adobe Sensei technology as the new visual search on Typekit. Now as you snap pictures of type on the go, you can save similar fonts as character styles and use them in your favorite desktop apps like Illustrator, Photoshop, and InDesign.

Adobe Capture uses the same Sensei technology as Typekit to find similar fonts on the go.

Get started now — on Typekit, either look for the camera icon in the search box to find or capture your photo, or check out the Discover page for tips and even more inspiration.

You might start noticing type in more interesting places!

Need a walkthrough? If our Early Access blog post doesn’t clear things up, reach out to us directly at and we’ll help you out.

Adobe Sensei as a service: Visual search APIs released for developers

Nice Web Type - Wed, 10/18/2017 - 3:00am

If you’re a developer who loves type, and you want to share that love with the people using your apps — we’ve got great news. Starting today, we’ve made the API for our visual search feature available on

Visual search from Typekit pairs our team’s typographic savvy with Adobe Sensei’s machine-learning technology, and in fact is the first Adobe Sensei capability to be released to the public as a service. With these APIs, your users can upload any photo of lettering or type and visual search will return a list of similar typefaces on Typekit.

When you enable visual search from Typekit in your own apps, you’ll be engaging with your users from the very beginning of their creative process — regardless of typographic skill level. Consider the initial design research phase of a creative professional. It’s impossible to know where and when inspiration will strike, but it’s pretty likely that user has a camera-enabled smartphone. An integration with our visual search means they can tap into a vast network of typographic knowledge early on.

In addition to the updated APIs, we’ve continued with our policy of providing fully thought-out documentation to accompany this new feature. You’ll find well-organized design patterns, API reference materials, and full endpoint documentation at your disposal on Have a look, and eliminate the guesswork in your development cycle.

Our visual search documentation includes well-organized design patterns.

We believe there is immense value in enabling customers to find, get, organize, and use fonts from Typekit without ever leaving the application they’re working in. That’s why we’ve been hard at work on reimagining how we support integrating the Typekit service into apps. Got questions? Get in touch with us about what you’re working on, and how you’d like to integrate type. We’d love to hear your ideas.

I haven’t experienced imposter syndrome, and maybe you haven’t either

Css Tricks - Tue, 10/17/2017 - 7:31am

In recent years it’s become trendy to discuss how we all apparently suffer from this imposter syndrome - an inability to internalize one's accomplishments and a persistent fear of being exposed as a “fraud”.

I take two issues with this:

  • it minimizes the impact that this experience has on people that really do suffer from it.
  • we’re labelling what should be considered positive personality traits - humility, an acceptance that we can’t be right all the time, a desire to know more, as a “syndrome” that we need to “deal with”, “get over” or “get past”.

It's not an officially recognized syndrome (yet?), but you can have medical diagnoses that are like imposter syndrome. A general feeling that you're faking it or don't know as much as you should isn't it.

Direct Link to ArticlePermalink

I haven’t experienced imposter syndrome, and maybe you haven’t either is a post from CSS-Tricks

Syndicate content
©2003 - Present Akamai Design & Development.