Truncating a single line of text if is fairly straightforward. Truncating multiple lines is a bit harder. Using just CSS (no JavaScript or server-side dancing) is nice for the simplicity. It’s gotten a little easier lately since Firefox (since version 68) has started supporting the ultra-bizarre -webkit-line-clamp soup method, which makes browser support for that pretty OK.
There is another way though, which is very clever and something I’d call a bonafide CSS trick. We somehow failed to cover it properly in our canonical post on line clamping, so I’ll cover it here then add it to that post. I first saw this trick on the now-dead Mobify blog, and more recently covered by Natalia Onischuk on HackingUI.
The trick uses line height for measuring
Here’s a big part of the trick. Imagine an element has a line-height of 1.4rem and you want to make sure it only shows a maximum of three lines of text. If you set the max-height to 1.4rem * 3, you’ve done it!
I’m not the worlds biggest fan of united line-height, but alas, it’s necessary here to do the math. I’m also not the biggest fan of setting it over and over on elements, so let’s set a variable we can use later, and then use it to set a global line-height.
You actually could leave it like this. That might be good enough if you don’t care about the ellipsis.
The rest of the trick comes in when you want to display that ellipsis stuff
An ellipsis (“…”) signifies that text has been truncated and continues longer than what it displayed. Using it is probably a pretty good practice when truncating text so the content doesn’t come to an abrupt, awkward end. (Well, the content itself might be awkward anyway, but hey, you tried.)
If you set position: relative on the element, you can absolutely position the ellipsis in the bottom-right corner.
I was very tempted to, instead of setting the bottom, to set the top and use top: calc(var(--lh) * (var(--max-lines) - 1)). My thinking there was that you might as well place the ellipsis at the exact point you need it. If the text is too short, the hidden overflow will cut it off. The problem with that is that it doesn’t deal with the “exactly max lines lines” problem. The ellipsis will show when the text matches the max lines — not only when it exceeds that space.
We’ll have to get trickier!
Note that this “setting stuff in the bottom-right” thing is pretty specific to left-to-right languages. I’m going to make the demo with CSS logical properties like inset-inline-end instead of right in hopes to make it more friendly to different languages and flow scenarios.
Another limitation is that the ellipsis doesn’t attach itself to the final word since it’s absolutely placed. We’re not going to fix that as well.
Let’s cover up the ellipsis when the text is too short
This is the second part of the trick. If we position the absolute at the bottom/end of the text all the time, that’s fine. But if the text is exactly equal to the --max-lines value or less, we want to hide it.
The trick there is to make a little box that is the same background as what is behind it and set it on top of the ellipsis to cover it. We can do that with the other pseudo-element:
Another trick we’re using here is not setting a bottom (inset-block-end) property. This places the box at the bottom of the content rather than the bottom of the relative parent, which is very useful.
Let me make the boxes red so you can see them in these three different examples:
The top example has more than three lines, so we see the ellipsis. The second example only has two lines, so the red box shows that the ellipsis will be covered up (but imagine a white box instead). The last example shows that this system works even when the content is exactly the same as the value of --max-lines.
I used CSS logical properties here, as the browser support has gotten pretty good. If you’re supporting any version of IE, you’ll have to switch back to using the bottom and right stuff instead.
This browser support data is from Caniuse, which has more detail. A number indicates that browser supports the feature at that version and up.
“The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.” – Tim Berners-Lee
Accessibility is an important element of web development, and with the ever-growing prevalence of video content, the necessity for captioned content is growing as well. WebVTT is a technology that solves helps with captioned content as a subtitle format that integrates easily with already-existing web APIs.
That’s what we’re going to look at here in this article. Sure, WebVTT is captioning at its most basic, but there are ways to implement it to make videos (and the captioned content itself) more accessible for users.
First and foremost: WebVTT is a type of file that contains the text “WebVTT” and lines of captions with timestamps. Here’s an example:
WEBVTT
00:00:00.000 --> 00:00:03.000
- [Birds chirping]
- It's a beautiful day!
00:00:04.000 --> 00:00:07.000
- [Creek trickling]
- It is indeed!
00:00:08.000 --> 00:00:10.000
- Hello there!
A little weird, but makes pretty good sense, right? As you can see, the first line is “WEBVTT” and it is followed by a time range (in this case, 0 to 3 seconds) on Line 3. The time range is required. Otherwise, the WEBVTT file will not work at all and it won’t even display or log errors to let you know. Finally, each line below a time range represents captions contained in the range.
Note that you can have multiple captions in a single time range. Hyphens may be used to indicate the start of a line, though it’s not required and more stylistic than anything else.
The time range can be one of two formats: hh:mm:ss.tt or mm:ss.tt. Each part follows certain rules:
Hours (hh): Minimum of two digits
Minutes (mm): Between 00 and 59, inclusive
Seconds (ss): Between 00 and 59, inclusive
Milliseconds (tt): Between 000 and 999, inclusive
This may seem rather daunting at first. You’re probably wondering how anyone can be expected to type and tweak this all by hand. Luckily, there are tools to make this easier. For example, YouTube can automatically caption videos for you with speech recognition in addition to allowing you to download the caption as a VTT file as well! But that’s not it. WebVTT can also be used with YouTube as well by uploading your VTT file to your YouTube video.
Once we have this file created, we can then embed it into an HTML5 video element.
The tag is sort of like a script that “plays” along with the video. We can use multiple tracks in the same video element. The default attribute indicates that a the track will be enabled automatically.
Let’s run down all the attributes while we’re at it:
srclang indicates what language the track is in.
kind represents the type of track it is and there are five kinds:
subtitles are usually translations and descriptions of different parts of a video.
descriptions help unsighted users understand what is happening in a video.
captions provide un-hearing users an alternative to audio.
metadata is a track that is used by scripts and cannot be seen by users.
chapters assist in navigating video content.
label is a title for the text track that appears in the caption track
src is the source file for the track. It cannot come from a cross-origin source unless crossorigin is specified.
While WebVTT is designed specifically for video, you can still use it with audio by placing an audio file within a element.
Digging into the structure of a WebVTT file
MDN has great documentation and outlines the body structure of a WebVTT file, which consists of up to six components. Here’s how MDN breaks it down:
An optional byte order mark (BOM)
The string “WEBVTT“
An optional text header to the right of WEBVTT.
There must be at least one space after WEBVTT.
You could use this to add a description to the file.
You may use anything in the text header except newlines or the string “-->“.
A blank line, which is equivalent to two consecutive newlines.
Zero or more cues or comments.
Zero or more blank lines.
Note: a BOM is a unicode character that indicates the unicode encoding of the text file.
Bold, italic, and underline — oh my!
We can absolutely use some inline HTML formatting in WebVTT files! These are the ones that everyone is familiar with: , , and . You use them exactly as you would in HTML.
WEBVTT
00:00:00.000 --> 00:00:03.000 align:start
This is bold text
00:00:03.000 --> 00:00:06.000 align:middle
This is italic text
00:00:06.000 --> 00:00:09.000 vertical:rl align:middle
This is <u>underlined text</u>
Cue settings
Cue settings are optional strings of text used to control the position of a caption. It’s sort of like positioning elements in CSS, like being able to place captions on the video.
For example, we could place captions to the right of a cue timing, control whether a caption is displayed horizontally or vertically, and define both the alignment and vertical position of the caption.
Here are the settings that are available to us.
Setting 1: Line
line controls the positioning of the caption on the y-axis. If vertical is specified (which we’ll look at next), then line will instead indicate where the caption will be displayed on the x-axis.
When specifying the line value, integers and percentages are perfectly acceptable units. In the case of using an integer, the distance per line will be equal to the height (from a horizontal perspective) of the first line. So, for example, let’s say the height of the first line of the caption is equal to 50px, the line value specified is 2, and the caption’s direction is horizontal. That means the caption will be positioned 100px (50px times 2) down from the top, up to a maximum equal to coordinates of the boundaries of the video. If we use a negative integer, it will move upward from the bottom as the value decreases (or, in the case of vertical:lr being specified, we will move from right-to-left and vice-versa). Be careful here, as it’s possible to position the captions off-screen in addition to the positioning being inconsistent across browsers. With great power comes great responsibility!
In the case of a percentage, the value must be between 0-100%, inclusive (sorry, no 200% mega values here). Higher values will move the caption from top-to-bottom, unless vertical:lr or vertical:rl is specified, in which case the caption will move along the x-axis accordingly.
As the value increases, the caption will appear further down the video boundaries. As the value decreases (including into the negatives), the caption will appear further up.
Tough picture this without examples, right? Here’s how this translates into code:
00:00:00.000 --> 00:00:03.000 line:50%
This caption should be positioned horizontally in the approximate center of the screen.
00:00:03.000 --> 00:00:06.000 vertical:lr line:50%
This caption should be positioned vertically in the approximate center of the screen.
00:00:06.000 --> 00:00:09.000 vertical:rl line:-1
This caption should be positioned vertically along the left side of the video.
00:00:09.000 --> 00:00:12.000 line:0
The caption should be positioned horizontally at the top of the screen.
Setting 2: Vertical
vertical indicates the caption will be displayed vertically and move in the direction specified by the line setting. Some languages are not displayed left-to-right and instead need a top-to-bottom display.
00:00:00.000 --> 00:00:03.000 vertical:rl
This caption should be vertical.
00:00:00.000 --> 00:00:03.000 vertical:lr
This caption should be vertical.
Setting 3: Position
position specifies where the caption will be displayed along the x-axis. If vertical is specified, the position will instead specify where the caption will be displayed on the y-axis. It must be an integer value between 0% and 100%, inclusive.
00:00:00.000 --> 00:00:03.000 vertical:rl position:100%
This caption will be vertical and toward the bottom.
00:00:03.000 --> 00:00:06.000 vertical:rl position:0%
This caption will be vertical and toward the top.
At this point, you may notice that line and position are similar to the CSS flexbox properties for align-items and justify-content, and that vertical behaves a lot like flex-direction. A trick for remembering WebVTT directions is that line specifies a position perpendicular to the flow of the text, whereas position specifies the position parallel to the flow of the text. That’s why line suddenly moves along the horizontal axis, and position moves along the vertical axis if we specify vertical.
Setting 4: Size
size specifies the width of the caption. If vertical is specified, then it will set the height of the caption instead. Like other settings, it must be an integer between 0% and 100%, inclusive.
00:00:00.000 --> 00:00:03.000 vertical:rl size:50%
This caption will fill half the screen vertically.
00:00:03.000 --> 00:00:06.000 position:0%
This caption will fill the entire screen horizontally.
Setting 5: Align
align specifies where the text will appear horizontally. If vertical is specified, then it will control the vertical alignment instead.
The values we’ve got are: start, middle, end, left and right. Without vertical specified, the alignments are exactly what they sound like. If vertical is specified, they effectively become top, middle (vertically), and bottom. Using start and end as opposed to left and right, respectively, is a more flexible way of allowing the alignment to be based on the unicode-bidi CSS property’s plaintext value.
Note that align is not unaffected by vertical:lr or vertical:rl.
WEBVTT
00:00:00.000 --> 00:00:03.000 align:start
This caption will be on the left side of the screen.
00:00:03.000 --> 00:00:06.000 align:middle
This caption will be horizontally in the middle of the screen.
00:00:06.000 --> 00:00:09.000 vertical:rl align:middle
This caption will be vertically in the middle of the screen.
00:00:09.000 --> 00:00:12.000 vertical:rl align:end
This caption will be vertically at the bottom right of the screen regardless of vertical:lr or vertical:rl orientation.
00:00:12.000 --> 00:00:15.000 vertical:lr align:end
This caption will be vertically at the bottom of the screen, regardless of the vertical:lr or vertical:rl orientation.
00:00:12.000 --> 00:00:15.000 align:left
This caption will appear on the left side of the screen.
00:00:12.000 --> 00:00:15.000 align:right
This caption will appear on the right side of the screen.
WebVTT Comments
WebVTT comments are strings of text that are only visible when reading the source text of the file, the same way we think of comments in HTML, CSS, JavaScript and any other language. Comments may contain a new line, but not a blank line (which is essentially two new lines).
WEBVTT
00:00:00.000 --> 00:00:03.000
- [Birds chirping]
- It's a beautiful day!
NOTE This is a comment. It will not be visible to anyone viewing the caption.
00:00:04.000 --> 00:00:07.000
- [Creek trickling]
- It is indeed!
00:00:08.000 --> 00:00:10.000
- Hello there!
When the caption file is parsed and rendered, the highlighted line above will be completely hidden from users. Comments can be multi-line as well.
There are three very important characters/strings to take note of that may not be used in comments: <, &, and -->. As an alternative, you can use escaped characters instead.
Not Allowed
Alternative
NOTE PB&J
NOTE PB&J
NOTE 5 < 7
NOTE 5 < 7
NOTE puppy --> dog
NOTE puppy --> do
A few other interesting WebVTT features
We’re going to take a quick look at some really neat ways we can customize and control captions, but that are lacking consistent browser support, at least at the time of this writing.
Yes, we can style captions!
WebVTT captions can, in fact, be styled. For example, to style the background of a caption to be red, set the background property on the ::cue pseudo-element:
video::cue {
background: red;
}
Remember how we can use some inline HTML formatting in the WebVTT file? Well, we can select those as well. For example, to select and italic () element:
video::cue(i) {
color: yellow;
}
Turns out WebVTT files support a style block, a lot like the way HTML files do:
Elements can also be accessed via their cue identifiers. Note that cue identifiers use the same escaping mechanism as HTML.
WEBVTT
STYLE
::cue(#middle cue identifier) {
text-decoration: underline;
}
::cue(#cue identifier 33) {
font-weight: bold;
color: red;
}
first cue identifier
00:00:00.000 --> 00:00:02.000
Hello, world!
middle cue identifier
00:00:02.000 --> 00:00:04.000
This cue identifier will have an underline!
cue identifier 3
00:00:04.000 --> 00:00:06.000
This one won't be affected, just like the first one!
Different types of tags
Many tags can be used to format captions. There is a caveat. These tags cannot be used in a element where kind attribute is chapters. Here are some formatting tags you can use.
The class tag
We can define classes in the WebVTT markup using a class tag that can be selected with CSS. Let’s say we have a class, .yellowish that makes text yellow. We can use the tag in a caption. We can control lots of styling this way, like the font, the font color, and background color.
WEBVTT
00:00:00.000 --> 00:00:03.000
<c.yellowish>This text should be yellow.</c> This text will be the default color.
00:00:03.000 --> 00:00:06.000
<c.redcolor>This text should be red.</c> This text will be the default color.
The timestamp tag
If you want to make captions appear at specific times, then you will want to use timestamp tags. They’re like fine-tuning captions to exact moments in time. The tag’s time must be within the given time range of the caption, and each timestamp tag must be later than the previous.
Voice tags are neat in that they help identify who is speaking.
WEBVTT
00:00:00.000 --> 00:00:03.000
<v Alice>How was your day, Bob?
00:00:03.000 --> 00:00:06.000
<v Bob>Great, yours?
The ruby tag
The ruby tag is a way to display small, annotative characters above the caption.
WEBVTT
00:00:00.000 --> 00:00:05.000
<ruby>This caption will have text above it<rt>This text will appear above the caption.
Conclusion
And that about wraps it up for WebVTT! It’s an extremely useful technology and presents an opportunity to improve your site’s accessibility a great deal, particularly if you are working with video. Try some of your own captions out yourself to get a better feel for it!
One random day not long ago, I started hearing joke after joke about “micro frontends” — sort of how I first learned about Toast. I didn’t understand the source until asking around, which uncovered this article from Cam Jackson.
In this article we’ll describe a recent trend of breaking up frontend monoliths into many smaller, more manageable pieces, and how this architecture can increase the effectiveness and efficiency of teams working on frontend code.
I’d argue it should read “front-end monoliths” and “front-end code,” but I digress already.
The idea is similar to microservices, but for the front end. So, instead of one big front-end architecture (e.g. a React app), different parts of the front end are developed entirely independent of one another, have no dependencies on each other, and can be worked on and deployed independently.
It’s one of those things where you can’t quite tell if it’s really an interesting foretelling of the future, just a niche architectural choice that happened to work for a handful of large organizations, or even just a theoretical option.
The first place my mind goes is consistency and DRY-ness. Anywhere I’ve worked, these things are a big deal and it seems like the industry at large has had endless front-end problems with shipping designs that start and stay consistent and cohesive without repeating itself with shovelfuls of technical debt. Independent front-ends sound like they might be a problem if Team B is being blocked by Team A for something not directly related, but then it introduces the problem of Team B’s output drifting towards inconsistency with Team A’s output.
The article itself talks about a browse/search landing page, a details/ordering page, and a profile page, with all three of those tackled by different independent products/teams. It sounds kinda cool and interesting to me, and it also sounds like those teams better sit right next to each other at work; otherwise this app is going the way of Frankenstein’s monster in two weeks. Styling is only lightly addressed with a, “I dunno, do a good job” sort of vibe. Teams struggle with this when they are all on the same product, so I’d have huge concerns here. The first thing I’d try to solve if this is being discussed seriously would be a design system that transcends all of it and that everyone uses without fail.
And what if those micro front ends co-exist on the same page? Use , the article says. I can’t see a world where that leads to a good user experience. (iFrames are slow, especially many of them all booting up their own worlds — and what about elements that might overflow bounds like tooltips and menus?)
The other integration options… isolating them to their own bundles or even native web components sounds a bit better. But still, the idea of siloed development where a React component might be slapped on the same page as a Vuew component seems like a huge user penalty for a pretty specific organizational problem. Not to mention you’re losing the benefits of a shared understanding of a codebase and the benefits of a deeper technical understanding of a smaller set of tools.
I’m probably not characterizing all of this fairly, especially because the idea is rather new to me and I’ve never worked like this before.
Nader Dabit has a follow up article: Building Micro Frontends with React, Vue, and Single-spa. Just so I’m not mischaracterizing that: The idea really is that you might build a React app and I build a Vue app and we’ll slap ’em together on the same page. I definitely come from an era where we laughed-then-winced when we found sites that used multiple versions of jQuery on the same page, plus one thing that loaded all of MooTools and Prototype thrown on there seemingly by accident. We winced because that was a bucket full of JavaScript, mostly duplicated for no reason, causing bugs and slowing down the page. This doesn’t seem all that much different.
I’m pointing out that we’re in the “hate without closely examining” stage of the idea. It’s entirely possible that after legitimate, close examination that the idea still fails. But too early to tell.
Do you have a transport company and want to use AI techniques in your business to grow it?
Are you willing to use Artificial Intelligence (AI) in your logistics business?
Here, in this blog, you will get answers to all such questions. Let’s start!
The excitement around Artificial Intelligence (AI) and Machine Learning continues to grow and the business applications are quite fascinating. In the present time, business leaders are trying to integrate AI into their organization’s workflows and decision making.
Before moving ahead, let’s have a look at some stats related to AI:
AI technology can enhance business productivity by up to 40 % (Accenture)
The number of AI startups since 2000 has increased 14 times. (Forbes)
AI will automate 16 percent of American jobs. (Forrester)
15 percent of enterprises are utilizing AI, and 31 percent of them say that it is their agenda for the next 12 months (Adobe)
Hence, it is quite clear that the use of AI is going to enhance with time and the need for machine learning services by software companies will increase manifolds.
Now, let’s discuss some of the uses of this amazing technology i.e. artificial intelligence (AI) in the logistics and transport industry.
Use of AI in the Transport Industry
AI making Advanced Warehouses
Various eCommerce firms have already initiated the process of using robots to automate the procedure of sorting of products and their packaging. Robots are instructed in such a way that they pack a product and sort it according to the delivery requirements.
Warehouses use Artificial Intelligence for automating and interconnecting the internal processes inside. Several advanced methods such as geocoding and locating intelligence are being used for optimum performance. The B2B and B2C sectors use AI enabled systems for allocating vehicles and selecting the best route for cars.
AI helps in finding the Quickest Delivery Route
Logistics sector faces a big traveling salesman problem. Here, the biggest problem is to find out the shortest path to deliver the item to the customer. Hence, there is a need to analyze the information associated with the task of completing deliveries.
Creating a personalized experience for the customer is the last mile delivery here. Once a customer places an order, an executive will look after it and process it and then they need to give an Estimated Time of Arrival for the delivery based on the data they have. It is really very tough to manage this data.
Here, the role of Artificial Intelligence comes in. This technique has the potential of using the most complicated dataset in an effective way. Using AI, it will be easy for you to leverage data platforms and make datasets for the purpose of regulating patterns.
Mostly, data patterns are based on predictive analysis. Moreover, the use of AI enabled drones for last mile delivery can be seen in various parts of the world.
Voice Assistants
Amazon’s Alexa is an example of a Voice assistant that helps customers to track their orders placed with logistics partner DHL. A customer asks Alexa about its package and Alexa tells the exact location of the product.
Moreover, If a customer is facing problems with the package, Alexa can route calls to the customer support of the courier. Also,
Use of AI in the Transport Industry
Public Safety
With the help of Artificial Intelligence, companies in the transportation industry to make sure the safety of the public at the time of using their services. With tracking crime data in real-time, it is possible to enhance the safety of citizens in the urban area that uses public transport.
Moreover, it will also help the police to enhance their efficiency by patrolling and keeping the citizens safe.
Autonomous Vehicles
Nowadays, the self-driving car is a new buzzword in the transportation sector. These cars use several Artificial Intelligence techniques to function and make calculated decisions on the road.
These autonomous vehicles show up to be a big opportunity to reduce the number of accidents on highways and enhance productivity.
Pedestrian Safety
With the help of the amazing potential of Artificial Intelligence, It is quite easy to forecast the path of pedestrians or cyclists. This will ultimately help in reducing the number of accidents. It will enhance the usage of transportation.
Control Traffic Flow
Traffic flow puts a big impact on transport. If artificial intelligence is used in the traffic flow data, it will result in efficient traffic patterns. Moreover, it will reduce congestion considerably.
Also, it is possible to manage higher and lower traffic patterns in an effective manner by using real-time tracking and AI enabled traffic light algorithms. However, this technique is also used in public transport for optimal scheduling and routing.
Better Planning and Decision Making
AI can help a transport company to simplify its planning procedure. The road freight transport system can use accurate prediction techniques to predict their volume with the help of Artificial Intelligence.
Moreover, various decision-making tools for the transport industry can be designed with the help of Artificial Intelligence. It will put a large impact on investments made by the companies in the future in an effective way.
Autonomous vehicles are quite helpful to the transport industry. Besides, voice assistants serve big to the logistics industry.
If you want to use AI in your business, you can contact a firm that works on Artificial Intelligence. In case, you have any feedback or suggestion, please leave a comment below.
To facilitate your font picking and pairing process, I’ve included examples of how these typefaces have been put to use recently, as well as a few pairing ideas. Enjoy and don’t forget to ping me on Twitter to show me how you’ve used them — I’d love to see it!
Gangster Grotesk
Designed by Adrien Midzic, Gangster Grotesk is a contemporary grotesque with angled terminal strokes that slightly curve inward. Because of these quirky individual touches, the typeface brings a unique flavor to headlines and posters when used at large sizes. Its low contrast and slightly condensed width make it a good choice for body copy and other texts of small type sizes as well.
The font family comes in three weights, from Light to Bold, with stylistic alternates, including a loopy expressive ampersand. Gangster Grotesk is offered for free when signing up for the Fresh Fonts newsletter.
When applying Gangster Grotesk to titles, the quirky grotesque pairs well with low x-height serifs for text settings, such as FF Atma. Used at small point sizes instead, pairing Gangster Grotesk with Le Murmure (see below) offers the right mix of character and neutrality.
Use Case
Gangster Grotesk excels in punchy designs with strong colors when it’s asked to render strings of text, for example on this flyer designed by Tokyo-based Juri Okita for Pells Coffee.
Recently awarded a Certificate of Typographic Excellence by the Type Directors Club, Le Murmure was commissioned by French design agency Murmure to renew their brand image. Drawing inspiration from magazine titling fonts, Le Murmure is a condensed sans serif with an interesting mismatch between its characters, making it especially distinctive for use at large sizes. Its height and the singularity of its shapes provide elegance while conveying notions of experimentation and creativity. Le Murmure comes with many — even more — original alternate letters, and there is even a stylistic set that ‘randomizes’ all alternates for you (SS08).
Used as a titling font, Le Murmure can pair well with a sans serif with warm curves, like Standard CT, or with a sans that has more pronounced irregularities, like Dinamo’s Prophet.
Use Case
Marrakesh’s Untitled Duo picked Le Murmure for the headlines of their studio’s website, complemented with Classic Sans for the navigation, which they also used at smaller size for the body text.
Reforma is a bespoke typeface designed by PampaType for the Universidad Nacional de Córdoba in Argentina, an educational institution more than 400 years old. The typeface is composed of three subfamilies: Reforma 1918, a classic Serif, Reforma 2018, a modern Sans, and Reforma 1969, an intermediate hybrid that combines the qualities of the other two (subtle modulation and flare serifs). I find all three subfamilies to adapt well to a wide range of bodies, from display to immersive text, and each one of them comes in three weights, with matching italics.
This typeface allows for interesting combinations among its different styles. The most obvious would be to use Reforma Sans for display use and to pair it with its serif counterpart for body text. However, I would encourage you to do something more original and try it the other way around, using the serif for titling.
Use Case
Graphic designer Étienne Pouvreau chose Reforma for the creation of the annual programs of the two Caf family centers of the Loir-et-Cher department in France. The booklets feature Reforma 1918 (the serif) for the headings, in italic, and Reforma 2018 (the sans) for the titles, subtitles and body text.
The new foundry of Florian Karsten is behind this versatile, geometric sans serif. Derived from Space Mono, a monospaced typeface designed by Colophon Foundry for Google Fonts in 2016, Space Grotesk kept the nerdy charm of its predecessor and its particular retro-future voice. Available in five weights, Space Grotesk is well-suited for a wide range of uses, from body text to bold headlines. In addition, it comes with five sets of alternate letters, the third one (SS03) removing the connections between the diagonal strokes of uppercase A, M, N, V, W, and lowercase v, w, y? — which can be particularly effective to create distinctive headlines.
As one would guess, Space Grotesk pairs well with Colophon Foundry’s Space Mono, the typeface it was derived from, which is also open source and free to use. Alternatively, if you’d like to pair it with a serif typeface, I would recommend one with pointy serifs and sharp details, such as Fortescue, or Wremena, which is also free to use (see below).
Use Case
Little & Big, a web design and development studio based in Sydney, Australia, chose Space Grotesk as the body text font for their website, including on blog entries, header and footer. They decided to pair it with Verona Serial, giving the website a professional, yet playful look and feel.
Syne is a type family designed by Bonjour Monde for the visual identity of Synesthésie, an art center close to Paris. It consists of five distinct styles, amplifying the notion of structural differentiation within a font family: Syne Extra is a wide, heavy weight intended for use at large sizes, Syne Regular is a geometric sans with short ascenders and descenders (visible in the lowercase ‘g’ among others), complemented with a wider bold style, an italic in a handwritten style and a monospaced with a distorted look. Updated just days ago, Syne now comes with more alternates, a set of brand new accents, and a variable font version.
The particularity of this typeface is that you can play with its different styles, and create fresh and atypical associations among them. For instance, Syne Extra does wonder for titles and headlines, and works well with Syne Regular for body copy.
Use Case
Syne was recently used by WeTransfer to present the results of their Ideas Report 2018, making extensive use of the typeface’s five different cuts on the website of the report and on its beautiful PDF companion.
Named after the VG 5000, a computer created by Phillips in 1984, this typeface playfully combines pixelated and curved strokes, blurring the lines between old and new digital shapes. It also includes many early emojis and pictograms from the VG 5000’s original set, allowing you to create unexpected combinations. Moreover, the typeface comes with contemporary gender inclusive characters for the French language, replacing pronouns “il” and “elle” (“he” and “she”) with the neutral “iel”, and providing an alternative to gendered words by combining their masculine and feminine versions.
Because of its pixelated details, and to remain truthful to its origins, I would suggest pairing VG5000 with a monospaced font, for example League Mono, which is also open source. Alternatively, you could decide to pair it with the sans or serif version of Input, or with a semi-proportional typeface like ETC Trispace, which is also free.
Use Case
French design studio Brand Brothers put VG5000 to use for the visual identity of Les Halles de la Cartoucherie, a new, versatile space dedicated to cultural, artistic and gastronomic activities in Toulouse. Paired with a custom, grid-based logo that represents the structure of the space, VG5000 was used both at large and small sizes on print materials, on the website of the space and even on its walls, using VG5000’s pixelated arrows for its wayfinding system.
Wremena is a serif typeface designed by Roman Gornitsky and published by Moscow-based foundry Typefaces of The Temporary State. Its design was based on Vremena, a free typeface by the same designer, but it features more pronounced triangular serifs and sharper angles, which become even more visible in heavier weights. Wremena is available in three styles (Light, Regular and Bold) without italics but with support for the Latin and Cyrillic scripts. Because of its similarities with Times New Roman, Wremena can be used as a free, more contemporary alternative to the ever-popular typeface.
A good tip to find pairings for a specific font is to browse the library of typefaces created by the same designer, as they often pair well together. This is especially true in this case, as Roman Gornitsky designed two sans serifs that are great matches for Wremena: Nowie Vremena, with its distinctive lowercase ‘g’, and more recently, Steinbeck, a lively font with intentional irregularities.
Use Case
The Jewish Museum of Moscow is behind Russian Spleen, a picturesque interactive web project that explores how Russian landscape painter Isaac Levitan impacted the 20th-century cinematography. Designer Pavel Kedich decided to typeset the website in Steinbeck (used at large sizes) and Wremena (here used for captions). Both fonts being multi-script, they allow the website to be available in English and Russian languages.
While I’ve included great examples of how these free fonts can be used, there are many more on Typewolf and Fonts in Use. And if you’d like to discover new, high-quality free and open source fonts, make sure to subscribe to my newsletter Fresh Fonts.
All works and screenshots are property of their respective owners.
For those too young to remember, the Browser Wars entailed a tech rush by, among others, Netscape and Microsoft, resulting in useless features being implemented because they were fast to bolt-on, and useful features being rushed because they were hard. After the Browser Wars, the internet entered an era of stability as the last vestiges of the old web were mercilessly hunted down and destroyed by Google.
Chrome and Chromium-based browsers have the vast majority of the market share, and with the new version of Edge being based on Chromium, only Firefox is truly left to compete. We’re already seeing the effects of this, and they’re not ideal.
Get ready, this one is going to have a lot of links, and they’re important…
The Saga of
On June 12th, 2019, Google developers asked for a review of a proposed new element for HTML. Specifically, they asked the Web Platform Incubator Community Group (WICG), a community dedicated to fostering open discussion about the future of the Internet as a platform. It’s run by the W3C, and generally, it’s exactly where you should be asking about potential changes to the actual foundation of the Internet.
On the same day, however, they announced their intent to include the element in the Blink rendering engine. Now, that doesn’t mean it’s going to happen any time soon, but it caused some significant consternation.
The Basic Idea
Well first, let’s talk about the element itself. It’s a pop-up notification. Literally, it’s a notification that pops up from the bottom of your screen, like toast… from a toaster, or from the top, like toast from an upside-down toaster [feel free to insert a joke about Australia here].
This notification element can show up and disappear on its own (the term used is “auto-expiring”, or it can require interaction to send it away. It’s basically an HTML element devoted just to “we use cookies” notifications.
The basic HTML could be written like one of the following examples:
I mean… besides the unfortunate acronym at the beginning of the tag? And the problem that actual toasters are not, in fact, a universal metaphor in Internet-having countries, as pointed out by the ever-brilliant Jen Simmons?
I believe new HTML elements should go through a standards process, be debated by multiple parties (not one), be useful to most websites (pave the cowpaths), and be written in language that makes sense for HTML, especially for folks who don’t speak English well. So no on this.
Ignoring those issues, it still requires JavaScript to work properly at all.
It’s additionally galling that toast is fundamentally an ephemeral UI element that is apart from page layout, and can’t work without JavaScript. Is there any other html element with those semantics? It’s a really odd precedent.
An HTML element that requires JavaScript. I’ll say it one more time for the Google devs at the back: JavaScript breaks, and it breaks a lot more often than plain HTML/CSS.
Then, it’s just gimmicky as hell. I mean, it’s something that we can already make with existing technology, and implementing it into HTML doesn’t actually make it that much easier. Nor is it particularly useful outside of a very narrow use-case. All it does is make the web’s underlying technologies “more like apps”, and while that’s not strictly a bad thing, is that really all we want for the Internet?
makes no sense to me. It reminds me of , , and all the other gimmicky tags from before we figured we should separate styling, behavior and markup.
An additional point: even marquee and blink didn’t need JavaScript to just work. They were awful in so many ways, but they ‘worked’ on their own.
The Development and Review Process
One common perception is that a couple of employees at Google had this idea, and decided to just throw it into their browser engine, figuring that everyone else would just go with it. As previously mentioned, the whole situation is highly reminiscent of the browser wars, when browser vendors came up with gimmicky proprietary elements in an effort to compete.
Timeline: initial commit to personal repo: May 24 comment by an editor of WHATWG HTML (also a Google employee): May 28 Intent to implement email: June 12 Request for TAG review: June 12 First mention in WICG: June 12
Web standardization according to Google? “Nobody outside my team has reviewed or approved of the explainer in my private repo, but if we implement and encourage devs to use it, surely our competitors will agree to implement it [because our market dominance determines compat]”.
This has understandably upset people who very strongly believe in a community-driven approach to developing technologies as basic and open as HTML.
One of the benefits of standardization through W3C Working Groups is diversity of input. W3C requires the consideration of all feedback, requires consensus to move forward. The diversity of vendor perspectives considered matters, because different vendors have different values.
There is a process. It’s quite formal and clear. It’s not new. It’s not a matter of personal preference, nor a “misunderstanding”. Not a “you say tomato I say tomato”. https://www.w3.org/2005/10/Process-20051014/tr.html#cfi
Think of all the many HTML elements that were considered and rejected over the years — and we are supposed to be on-board with TOAST? Because a couple guys at Google decided they want it. And they can. So no to But yes to ???
Even people who generally like and support the idea of the std-toast element are unhappy with how it was presented to the community:
Look, I get the “Move fast! Break things!” attitude. And I think it is exactly right that Google should experiment with the web. We all should! And, again, I think that is probably a useful addition to HTML.
But the way Google has gone about introducing it to the world betrays a huge lack of empathy for the poor sods who have review standards, for other browsers, for users, and for the broader Web community.
Despite everything shady Google has ever pulled [please don’t kill our PageRank, thanks!], I’d honestly like to believe that this was the mistake of a few, rather than the beginning of Google dictating the direction of web design and development as a whole. But if it is, we have a whole new problem on our hands.
Google’s priority has been, is, and always will be making loads of money. And who can blame them? But if we don’t have competition between, not just browsers, but browser rendering engines, then a couple of random people at Google who haven’t necessarily thought things through will be able to drastically change the direction of the web pretty much whenever they like.
Look, I still generally like the things Google makes, but let’s be real: they don’t always make the best decisions. I could make a joke about Google+, here, or the even more ill-fated Google Buzz, but let’s have a look at a something that more directly impacts web designers and developers:
If Google were in charge of the Web Platform, we would not have CSS Grid Layout. With the personal exception of @tabatkins, Google did not believe in CSS Grid. Microsoft and Mozilla implemented their own, but it was Bloomberg who funded @igalia to code Blink’s implementation.
Promises are one of the most celebrated features introduced to JavaScript. Having a native asynchronous artifact baked right into the language has opened up a new era, changing not only how we write code but also setting up the base for other freat APIs — like fetch!
Let’s step back a moment to recap the features we gained when they were initially released and what new bells and whistles we’re getting next.
Let’s take a quick look at some of the things we can currently do with promises. When JavaScript introduced them, it gave us an API to execute asynchronous actions and react to their succesful return or failure, a way to create an association around some data or result which value we still don’t know.
Here are the Promises features we have today.
Handling promises
Every time an async method returns a promise — like when we use fetch — we can pipe then() to execute actions when the promise is fulfilled, and catch() to respond to a promise being rejected.
The classic use case is calling data from an API and either loading the data when it returns or displaying an error message if the data couldn’t be located.
In addition, in its initial release we got two methods to handle groups of Promises.
Resolving and rejecting collections of promises
A promise can be fulfilled when it was successfully resolved, rejected when it was resolved with an error, and pending while there’s no resolution. A promise is considered settled when it has been resolved, disregarding the result.
As such, there are two methods we have to help with the behavior of handling a group of promises depending on the combination of states we obtain.
Promise.all is one or those methods. It fulfills only if all promises were resolved successfully, returning an array with the result for each one. If one of the promises fails, Promise.all will go to catch returning the reason of the error.
Promise.all(
fetch('//resource.to/some/data'),
fetch('//resource.to/more/data')
])
.then(results => console.log('We got an array of results', results)
.catch(error => console.error('One of the promises failed', error)
In this case, Promise.all will short-circuit and go to catch as soon as one of the members of the collections throws an error, or settle when all promises are fulfilled.
Check out this short writing about promises states by Domenic Denicola for a more detailed explanation about the wording and concepts about them.
We also have Promise.race, which immediately resolves to the first promise it gets back, whether it was fulfilled or rejected. After the first promise gets resolved, the remaining ones are ignored.
Promise.race([
fetch('//resource.to/some/data'),
fetch('//resource.to/other/data')
])
.then(result => console.log('The first promise was resolved', result))
.catch(reason => console.error('One of the promises failed because', reason))
The new kids on the block
OK, we’re going to turn our attention to new promise features we can look forward to.
Promise.allSettled
The next proposed introduction to the family is Promise.allSettled which, as the name indicates, only moves on when the entire collection members in the array are no longer in a pending status, whether they were rejected or fulfilled.
Notice how this is different from Promise.all in that we will never enter in the catch statement. This is really good if we are waiting for sets of data that will go to different parts of a web application but want to provide more specific messages or execute different actions for each outcome.
Promise.any
The next new method is Promise.any, which lets us react to any fulfilled promise in a collection, but only short-circuit when all of them failed.
Promise.any([
fetch('//resource.to/some/data'),
fetch('//resource.to/more/data'),
fetch('//resource.to/even/more/data')
])
.then(result => console.log('a batch of data has arrived', result))
.catch(() => console.error('all promises failed'))
This is sort of like Promise.race except that Promise.race short-circuits on the first resolution. So, if the first promise in the set resolves with an error, Promise.race moves ahead. Promise.any will continue waiting for the rest of the items in the array to resolve before moving forward.
Demo
Some of these are much easier to understand with a visual, so I put together a little playground that shows the differences between the new and existing methods.
Wrap-up
Though they are still in proposal stage, there are community scripts that emulate the new methods we covered in this post. Things like Bluebird’s any and reflect are good polyfills while we wait for browser support to improve. They also show how the community is already using these kind of asynchronous patterns, but having them built-in will open the possibilities for new patterns in data fetching and asynchronous resolution for web applications.
“When does finally fire in a JavaScript promise?” This is a question I was asked in a recent workshop and I thought I’d write up a little post to clear up any confusion.
The answer is, to quote Snape:
…always.
The basic structure is like this:
try {
// I'll try to execute some code for you
}
catch(error) {
// I'll handle any errors in that process
}
finally {
// I'll fire either way
}
async function getData() {
try {
let chuckJokes = await fetch(`https://api.chucknorris.io/jokes/random`)
.then(res => res.json())
console.log('I got some data for you!')
document.getElementById("quote").innerHTML = chuckJokes.value;
}
catch(error) {
console.warn(`We have an error here: ${error}`)
finally {
console.log('Finally will fire no matter what!')
}
In the console:
Now, let’s introduce a typo to the API and accidentally put a bunch of r‘s in the URL of the API. This will result in our try statement failing, which means the catch now throws an error.
async function getData() {
try {
// let's mess this up a bit
let chuckJokes = await fetch(`https://api.chucknorrrrris.io/jokes/random`)
.then(res => res.json())
console.log('I got some data for you!')
document.getElementById("quote").innerHTML = chuckJokes.value;
}
catch(error) {
console.warn(`We have an error here: ${error}`)
}
finally {
console.log('Finally will fire no matter what!')
}
}
Console:
One giant important piece that the example doesn’t illustrate is that the finally block will run even if in the try or catch block, a return or break statement stops the code.
When would you use this?
I’ve found it particularly useful in two different situations, though I’m sure there are others:
When I otherwise would duplicate code that’s need in the try and catch blocks. Here’s an example in a Vue cookbook recipe I wrote. I shut off the loading state in a finally block. This includes, like the example above, where I need to change the UI somehow in either case.
When there’s some cleanup to do.Oracle mentions this in their documentation. It’s Java, but the same premises apply.
Finally is not useful as often as try and catch, but worth noting for some use cases. Hope that clears it up!
Who needs a project manager? You’re an organized person who can keep track of your own work, right?
Wrong.
Well, wrong if you’re part of a team. The thing about being self-organized is that it’s related to project management but not synonymous with it. Case in point: what happens if your project relies on someone else’s involvement? Sure you’re organized, but can you always say the same about your co-workers? Chances are you need something to keep everyone in sync so that a project stays on course.
monday.com is project management, but with a human touch. Sure, there’s task lists, assignments, milestones, due dates, and such like you would expect from any project management tool. That’s a given. That said, monday.com takes things up a notch by stripping away the barriers that prevent team members from collaborating with one another. For example, monday.com includes real-time messaging, file sharing, reporting, and a slew of other features that bridge the gaps between people and tasks so that everyone has purview into the progress of a project. Plus, it’s so pretty to look at.
There’s so much more than meets the eye because monday.com goes beyond project management. There’s resource management that ensures you have the right tools for a project, forecasting to affirm the prospect of a business opportunity, and even client management services. Seriously, your team and perhaps company can lean into monday.com and get a ton of use out of it.
You know what to do from here. Give monday.com a try. There’s a free trial and we’re sure you’ll find it to be so useful that you’ll want to stick with it well beyond.
After months of extensive testing, the new design is a confident, and positive change for one of the web’s biggest names, albeit with some controversy that is bound to cause a ruckus. If you’d like to be among the first to have an opinion, you can opt-in right now, or Twitter will opt-in for you in the coming days, because this change is mandatory.
the new Twitter site is self-consciously dashboard-like
Twitter’s life began as a deliberately stripped down social network, in the same way that Google began as a stripped down search interface. Throughout its history, design changes seem to have been attempts to add features, without changing the core simplicity of its timeline UI.
The new Twitter design throws that strategy out of the window, with fundamental changes to the site. Where once there was the illusion of a simple news feed, the new Twitter site is self-consciously dashboard-like. Helped, in no small part, by the relocation of the menu from top horizontal, to left vertical.
The navigation change has been an opportunity – or more probably, a solution – to expose some of the features that have been introduced, but are rarely used outside of the mobile apps; the explore tab, bookmarks, and lists are all prioritized, and direct messages now have a dedicated space.
You’ll also find the introduction of not one, but two dark modes, which is presumably intended to increase eye-fatigue, ensuring you spend less time on the site ranting about the lack of an edit button.
there’s very little new here, other than a more app-like experience for users who prefer not to use an app
There is, frustratingly, still no edit button. Anyone who spends any time on Twitter will be aware that 50%+ of all tweets are instant replies, by the same account, correcting a typo in its original tweet. Of course people can’t be allowed to edit a tweet that’s already been liked or retweeted, but there’s no reason Twitter couldn’t strip likes and retweets from any edit.
Perhaps more frustrating is the fact that verification is still limited. Pop-stars, movie-stars, politicians, et al get a little blue badge, but you and I don’t. What this means is the platform is still essentially anonymous, and will continue to be plagued by bots, trolls, and spam. If Twitter is looking for a way to monetize its main product, paid verification with the option to auto-mute anyone not verified, would make Twitter more usable, more profitable, and just plain nicer overnight.
This design feels like a long-overdue update, delivering necessary breathing room to allow the introduction of as yet unseen features. However, there’s very little new here, other than a more app-like experience for users who prefer not to use an app.
Some might suggest that a company is entitled to update its site design any time it likes, but those people must not have witnessed the meltdown some users had the last time Twitter introduced a far less substantial tweak to its UI than this. Others might question whether anyone actually uses Twitter on desktop; isn’t that what cellphones and bathroom breaks were invented for?
