Here’s how and why the team at GitHub has slowly been deprecating jQuery from their codebase:
We have recently completed a milestone where we were able to drop jQuery as a dependency of the frontend code for GitHub.com. This marks the end of a gradual, years-long transition of increasingly decoupling from jQuery until we were able to completely remove the library. In this post, we will explain a bit of history of how we started depending on jQuery in the first place, how we realized when it was no longer needed, and point out that—instead of replacing it with another library or framework—we were able to achieve everything that we needed using standard browser APIs.
The team explores how using tools like eslint-plugin-jquery discourages developers at GitHub from using jQuery, but the team also notes that they decided to remove certain design behaviors altogether to help them achieve this goal:
As part of our refined approach to building frontend features on GitHub.com, we focused on getting away with regular HTML foundation as much as we could, and only adding JavaScript behaviors as progressive enhancement. As a result, even those web forms and other UI elements that were enhanced using JS would usually also work with JavaScript disabled in the browser. In some cases, we were able to delete certain legacy behaviors altogether instead of having to rewrite them in vanilla JS.
I think all of this is wonderful news. It’s good for jQuery, it’s good for developers, and it’s good for the web. But it also shows just how far browsers have come since the first release of jQuery back in 2006. What will browsers be capable of 12 years from now, I wonder.
Worldwide, retail e-commerce sales totaled $2.29 trillion last year. By the end of this year they’ll have reached $2.8 trillion. If the trend continues apace, e-commerce sales will reach a whopping $4.479 trillion by 2021.
The message is clear: Consumers love the convenience of e-commerce; the reduced prices compared to real world stores, with their real world overheads; the greater range of products.
With a simple click, or tap, you can buy or subscribe to almost any product or service. Never has impulse buying been so easy.
It’s clear that e-commerce will continue to grow as a sector. But what exactly will it look like in the coming months and years?
The story of Adidas is a long and interesting one. Adolf and Rudolf Dassler became the best shoe makers in Germany, and then internationally during Nazism. The Adidas Logo is recognized world-wide and today we’ll find out how it was conceived.
The Beginning
At a young age, both the brothers knew that they were destined to be shoemakers. After many years of practice, the time came for them to establish their own business. Thus, Dassler Brothers Shoe Factory was born. Together, the brothers accomplished many great things. However, all of that came to a halt in 1949 when the brothers parted ways. Adolf Dassler became the sole owner of the newly branded Adidas, and his brother, Rudolf Dassler, went on to create what we know now as Puma. Ironically, these two brands have been direct competitors ever since.
The First Logo: The Three Stripes
Throughout the history of the company, much has changed. Even though Adidas is a much different company than when it started, one thing has remained the same: it’s the brand with the three stripes. With every logo change, new campaign, and new product line, the company has tried their best to implement the three stripes. From the very first shoe until now in 2018, anyone can recognize a pair of Adidas when they see one. All thanks to a simple and iconic logo.
The Second Adidas Logo: The Trefoil
The second logo that came out of Adidas was designed after a leaf. With the three stripes still present, the idea was for this logo to represent growth. At this point in the company’s history, it had become a lot larger than it was before and there were now more than one branch. I think Adidas did a wonderful job representing their roots and at the same time symbolizing change. Even today, this logo is still used on many of Adidas’ classic designs.
The Third Logo: The Three Bars
Adidas’ latest and greatest logo is meant to symbolize power. The incline of the classic three stripes represents a mountain. It was created to inspire people to push themselves to the limit.
The reason the Adidas is so effective is because it’s simple and easy to place; combine that with the quality product they offer, and you have a hit.
Guides, resources and discussions about Semantic HTML are often focused around specific elements, like a heading, or a sectioning element, or a list. It’s not often that we talk specifically about how we can combine HTML elements to increase their effectiveness.
Normally, when we introduce HTML, we talk about how it is used to apply meaning to content in a document, and we do this by using examples like:
“Is it a paragraph?”
“Is it a heading?”
“Is it a numbered list”
“Is it a button”
We use these examples because they are easy to understand — it’s a single piece or chunk of the same content that needs to be represented in a particular way. This is useful, but it only scratches the surface of how we can use and combine elements to provide more context and meaning.
You remember Voltron, right? Each member of the Voltron force was powerful in their own right, but it was when they combined together to form a towering figure that their mighty powers became unstoppable.
The same is true of HTML elements. I have a few favorite combinations that I’ll take you through. They may seem obscure, but you’d be surprised at how often they come up when you take the time to think outside of divs and spans.
Abbreviations and Definitions
and are two of my favorite HTML elements. I particularly like them because they work really well together.
You can combine the abbreviation and definition elements to allow browsers, search bots, and other technologies to recognize that something is being defined and that the acronym is associated to that phrase.
<p>
The <dfn><abbr title="International Good
Dog Association">IGDA</abbr></dfn> is an international,
not-for-profit organization responsible for determining
that all dogs are good.
</p>
In the above example, I’m defining that the acronym “IGDA” as “International Good Dogs Association.” I do this by wrapping the acronym in an element with a title attribute defining the full name. By adding the element around the abbreviation, it indicates that the surrounding paragraph defines the term “International Good Dogs Association.”
The element is useful because it can tell screen readers what they should read, while also providing a useful visual representation in the form of a tooltip explaining what the abbreviation is.
Visual representation of and .
Keyboard, Sample and Variable
If you haven’t heard of these elements, then get ready to have your socks blown off, because they are awesome.
First up, the element is used to represent text for a textual user input (e.g. from a keyboard). You can also nest multiple elements to represent multiple keystrokes. I love this because, as developers, we find ourselves (hopefully) writing documentation, blog posts, and guides on a regular basis and HTML provides us with native ways to represent this content straight out of the box!
If I wanted to tell someone how you copy and paste with the keyboard, I could mark it up like the code below.
<p>I like to <kbd><kbd>Ctrl</kbd>+<kbd>C</kbd></kbd> and <kbd><kbd>Ctrl</kbd>+<kbd>V</kbd></kbd> a lot.</p>
It looks a bit nuts but the above code, when rendered, looks like the following without any styling applied to it. If you are wondering why kbd is nested inside another kbd element, what this does is specify that the key or input is part of a larger input. Even more combined superpowers!
You can further target the elements with CSS to make it look more like little keyboard controls. (Note: Browsers tend to render this by default with a monospace font.)
If you're wondering what the difference is between using versus a span, I believe it comes down to information. I will repeat this sentiment a lot: we do not know how someone is going to consume our HTML, so give your content it's best chance by representing it in the most meaningful and contextual way possible. If you are still not on board, then please go read my post about HTML as told by TypeScript.
The element is really cool because you can nest it inside the element and vice versa. WHAT? I know, so versatile! Let's have a look at some examples from MDN.
The following code is an example of nesting a element inside a element. This is used to mark up content that represents input based on the text displayed by the system (e.g. button names).
<p>To save the image file, select <kbd><kbd><samp>File</samp></kbd> - <kbd><samp>Save as...</samp></kbd></kbd>.
</p>
In the above code, we define our keyboard shortcuts the same as our previous example, but we also determine that the menu and menu item names (contained within both and ) are an input selected from something displayed by the system, e.g. a dialog or widget.
In other words, this piece of text is a message from the system which has some user inputs that you need to follow (like File and Save as…).
Whereas, when we nest inside , we determine that the input has been echoed back to the user by the system.
<p><samp>yarn start:theproject does not exist, did you mean:</p>
<blockquote><samp><kbd>yarn start:the-project</kbd></samp></blockquote>
Finally, the element! This is used to mark up the name of a variable in math or programming, for example:
<var>E</var> = <var>m</var><var>c</var><sup>2</sup>.
<samp>Error: <var>console<var> is undefined.</samp>
Here you can start to see how combining with other elements like
, , or starts to make your content's markup more explicit by adding more context. Anything that interprets your HTML markup can start to derive more meaning from the elements you are using rather than just assuming that it's all standard text.
If you put this content in a paragraph with some spans, there is no way for technology to distinguish this from any other old text on your page. You don't have to resort to or a
to represent this content because HTML already provides us with more semantically accurate elements we can use. HTML is not just about presentation; it's about meaning. Various technologies outside of visual rendering engines rely on this meaning to make decisions about how to communicate our content in the most meaningful way (e.g. screen readers, text to voice, reading apps, bots, or the next big thing in the future).
Figures
Figures () are a great example of a power combination element. Unfortunately, I think it is widely misused and under appreciated (much like , which I could talk about for hours). The obvious combination you are probably familiar with is using and together. We often use this duo to represent graphical content like images, illustrations and diagrams — but it can also be used for things like code, poems and quotes!
Because a figure is so flexible in what kind of content it represents, there are a bunch of different HTML elements you can use within a figure to provide more context around the type of content you are putting in your page.
Figcaption
The element is often seen with an optional which represents a caption or legend for a figure. It should be the first child or last child of the element. You can also use any flow content (e.g. paragraphs, headings, etc.) in the to provide more context and you can have multiple images inside a represented by a single .
<figure>
<img src="jello.jpg" alt="Golden Retriever Puppy" />
<figcaption>Jello the Golden Retriever enjoying being carried home.</figcaption>
</figure>
Preformatted Text
The
element is used to display preformatted text or code and is usually rendered using a monospace font. While can be used on its own, it can also be combined with and . By doing this, the content inside the element becomes more accessible to assistive technologies, like screen readers, since it allows us to use as a label for the text or code.
We can go even further by combining the and elements to identify the pre- formatted content as code.
Because is considered flow content, it can also be used inside a to mark up inline references to code (i.e. a single phrase or line).
Cite and Blockquote
Quotations are something I use a lot and it honestly didn't occur to me it could be used as part of a figure. But it still makes sense to use cite or quotation if the content they contain is relevant to the overall content, even if it is not part of the main document flow.
I like the example of using a figure for poems, mainly so I could share the amazing poem I wrote about my dog. Here I use the element inside the :
<figure>
<p>
Jello - A little fluffy dog.
Hello!
Squishy Jello - you little fluffy fellow.
BOUNCY yellow Jello.
A very mellow fellow.
EATING MY MARSHMALLOW.
</p>
<figcaption><cite>Eating my Marshmallow by Mandy Michael</figcaption>
</figure>
It's easy to fall into the trap of thinking that the figure element is just for images or image-like content, but you can use it for content like audio, video, charts, poems, quotations or even tables of statistics. Because the element is so versatile you can combine it with so many other elements to provide more and more context about the figure for assistive technology, browsers, and other technologies consuming your website.
Wrapping Up
These are just some of the ways HTML elements can be combined for better context. HTML elements are indeed useful and valuable on their own when used as isolated pieces — and using them this way is a good first step. But, like Voltron, when you combine HTML elements together, the individual pieces form a greater whole and gain much more meaning and power. It's important that we don't think of HTML as individual pieces of code, but parts of a whole because HTML is really a mass of totally amazing combinations.
You can combine and use HTML elements in any number of ways to best represent your content. Don't simply stick to the same old things you know; take the time to explore HTML and learn about all it has to offer. Like any language, we should make the most of it and use it to its full potential.
The more accurate you are in marking up your content, the better that content will be represented across technologies, and the more prepared it will be for any anything else that is used to interpret your HTML in the future.
So, go forth and HTML elements, unite!
Resources
In my opinion, the best resource for learning and understanding how to use HTML (outside of the spec itself) is the MDN Web Docs. It lists all the HTML elements you could ever need.
The following are among the elements covered in this post:
We’ve all seen articles like “The Top 5 Ways To Fix Your Sign Up Flow and Get On With Your Life.” Articles like this aren’t wrong or bad, they are just shallow and a bit junk food-y and BuzzFeed-y. Of course, a designer’s actual job is complicated, nuanced, and difficult. But deep dives into all that are far less common.
It’s clear that the currency of design discourse is really concerned with the “how” of design, not the “why” of it. As Teixeira and Braga write:
While designers tend to be skeptical of magic formulas—we’re decidedly suspicious of self-help gurus, magic diets, or miraculous career advice—we have a surprisingly high tolerance for formulaic solutions when it comes to design.
That’s a pointed criticism but, from my perspective, it’s also quite accurate.
It’s an interesting concept to compare JavaScript with CO2 and yet a very valid one. Alex Russel who works for the Chrome team and has a lot of insights into the current state of the web says that using too much JavaScript or using it exclusively (without progressive enhancement/graceful degradation) will have the same effect as too much CO2 for the ecosystem on planet Earth — the ecosystem will fall apart. And just like we need a certain amount of CO2 to live, we need JavaScript on the web. It’s that fine line that makes the difference — the line between not too much and none at all.
I feel that with the native browser APIs that we have these days we have a fantastic opportunity to build great web services without bloating them too much and without relying only on JavaScript. We can enhance native elements with the Custom Elements API easily via ES6 Classes, with so little code that it seems ridiculous to build all that on your own in a third-party framework. Coincidentally, the Github engineering team published an article about how they dropped jQuery entirely and what they now use instead: native JavaScript and small, lean code that is progressively enhancing their platform. Less code, better maintainability, and more stability.
News
Chrome 70 is now in beta, bringing shape detection as an origin trial that allows us to perform QR code reading, face detection, and text recognition in images. The Web Authentication API got some updates, too, and referrerpolicy support was added to elements. This version will also deprecate Custom Elements v0, HTML Imports, and Shadow DOM v0.
Finally, with Firefox 62, Mozilla ships ::selection instead of :-moz-selection. They also implemented flat(), and flatMap() for JavaScript arrays and developers get a new Shape Path Editor.
Chrome 69 is out and brings us CSS Scroll Snap Points, the CSS viewport-fit property for cutout-displays like the one of iPhone X, and the Web Locks API which allows scripts running in one tab or worker to asynchronously acquire a lock, hold it while work is performed, and then release it. The update also comes with CSS conic gradient support, toggleAttribute() (which is similar to the classList.toggle() method but for attributes), and flat() and flatMap() for arrays. Unfortunately, this release changed how the browser displays the URL, and it seems that people consider it a security bug. Let’s see how that will evolve.
With Firefox 62 supporting variable web fonts, we finally have support in all major browsers and can use it widely now to improve performance, be more creative with typography, and reduce data traffic drastically.
Anyone who isn’t an expert would be hard-pressed to explain how tracking on the internet actually works. That’s why Firefox now changes their default settings and enforces tracking blocking in their browser by default.
PHP7.3 is coming soon with new Heredoc and Nowdoc syntax, trailing commas in function calls, is_countable(), array_key_first(), array_key_last(), and Argon2 password hash enhancements.
General
Alex Russell’s “The ‘Developer Experience’ Bait-and-Switch” is a great piece that explains the toxic environments we currently build for the web and why JavaScript can be compared to CO2 — both are needed in small portions, but if there’s too much of it, it’ll put the entire ecosystem (the web) at risk. A thoughtful article that I recommend everyone here to read, share, and remember.
As Alexa, Cortana, Siri, and even customer support chat bots become the norm we have to start considering not only how our content looks but how it could sound. We can — and should — use HTML and ARIA to make our content structured, sensible, and most importantly, meaningful.
Nightwatch Cybersecurity published a security vulnerability in Android that exposes information about the user’s device to all applications running on it. This seems to include the WiFi network name, BSSID, local IP addresses, DNS server information, and the MAC address — all in all quite a lot of private information that allows people to track individual Android devices. Unfortunately, all Android OS versions including forks (except for Android P/9 where a fix was provided) seem to be affected with no plan to fix older versions.
CSS Shapes have quite some history already. Brought to the web early by an initiative of the Adobe Web team, browser vendors removed the implementations soon again, and are now slowly coming back with iterated, improved specifications and implementations. Rachel Andrew shares how to implement CSS Shapes.
With the web’s growth come new features to better accommodate its new form factors and use cases. One feature I’m excited about is the color-adjust property, proposed in CSS Color Module Level 4. It is an acknowledgment that the web will continue to show up on devices that have less-than-stellar displays.
Stefan Judis read what the Mozilla documentation has to say about input elements and discovered a couple of interesting things that could be very useful for your next project.
