Tag: HTML

Detecting Specific Text Input with HTML and CSS

Posted on November 10, 2021 in Design

Louis Lazaris breaks down some bonafide CSS trickery from Jane. The Pen shows off interactivity where:

  1. You have to press a special combination of keys on a keyboard.
  2. Then type a secret password.

From there, a special message pops up on the screen. Easily JavaScript territory, but no, this is done here entirely in HTML and CSS, which is wild.

A lot of little known features and tricks is combined here to pull this off, like HTML’s accesskey and pattern attributes, as well as :not(), :placeholder-shown, and :valid in CSS—not to mention the custom property toggle trick.

That’s… wow. And yet, look how very little code it is.

To Shared Link — Permalink on CSS-Tricks

The post Detecting Specific Text Input with HTML and CSS appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.

CSS-Tricks

, , , ,

Can Include (a Certain HTML element within another Certain HTML Element)

Posted on October 22, 2021 in Design

A single-serving website from Alexander Vishnyakov for testing if it’s valid to put any particular HTML element within another type of HTML element. Kinda neat to have a quick reference for this.

Some combinations feel fairly obvious: can you put a <video> inside an <input>? Uh, no. Some are trickier: can you put a <div> inside an <h1>? Nope — that one bit me this week (derp). Some are a little confusing, like <div> is an invalid child of an <ol> but a valid child of a <dl>.

Direct Link to Article — Permalink

The post Can Include (a Certain HTML element within another Certain HTML Element) appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.

CSS-Tricks

, , , , ,
[Top]

Comparing HTML Preprocessor Features

Posted on September 30, 2021 in Design

(This is a sponsored post.)

Of the languages that browsers speak, I’d wager that the very first one that developers decided needed some additional processing was HTML. Every single CMS in the world (aside from intentionally headless-only CMSs) is essentially an elaborate HTML processor: they take content and squoosh it together with HTML templates. There are dozens of other dedicated HTML processing languages that exist today.

The main needs of HTML processing being:

  • Compose complete HTML documents from parts
  • Template the HTML by injecting variable data

There are plenty of other features they can have, and we’ll get to that, but I think those are the biggies.

This research is brought to you by support from Frontend Masters, CSS-Tricks’ official learning partner.

Need front-end development training?

Frontend Masters is the best place to get it. They have courses on all the most important front-end technologies, from React to CSS, from Vue to D3, and beyond with Node.js and Full Stack.

Diagram showing partials and {{ data }} turning into a complete HTML document.

Consider PHP. It’s literally a “Hypertext Preprocessor.” On this very website, I make use of PHP in order to piece together bits of templated HTML to build the pages and complete content you’re looking at now.

<h2>   <?php the_title(); // Templating! ?> </h2>  <?php include("metadata.php"); // Partials! ?>

In the above code, I’ve squooshed some content into an HTML template, which calls another PHP file that likely contains more templated HTML. PHP covers the two biggies for HTML processing and is available with cost-friendly hosting — I’d guess that’s a big reason why PHP-powered websites power a huge chunk of the entire internet.

But PHP certainly isn’t the only HTML preprocessor around, and it requires a server to work. There are many others, some designed specifically to run during a build process before the website is ever requested by users.

Pug
Ruby ERB
Markdown
PHP
Haml
Liquid
Slim
Go html/template
Handlebars
Mustache
Twig
Nunjucks
Kit
Sergey

Let’s go language-by-language and look at whether or not it supports certain features and how. When possible the link of the preprocessor name links to relevant docs.

Does it allow for templating?

Can you mix in data into the final HTML output?

Processor Example
Pug ✅
- var title = "On Dogs: Man's Best Friend";
- var author = "enlore";
h1= title
p Written with love by #Chris Coyier
ERB ✅
<%= title %>
<%= description %>

<%= @logged_in_user.name %>
Markdown ❌
PHP ✅
<?php echo $ post.title; ?>
<?php echo get_post_description($ post.id) ?>Also has HEREDOC syntax.
Slim ✅
tr
td.name = item.name
Haml ✅
<h1><%= post.title %></h1>
<div class="subhead"><%= post.subtitle %></div>
Liquid ✅
Hello {{ user.name }}!
Go html/template ✅
{{ .Title }}
{{ $ address }}
Handlebars ✅
{{firstname}} {{lastname}}
Mustache ✅
Hello {{ firstname }}!
Twig ✅
{{ foo.bar }}
Nunjucks ✅
<h1>{{ title }}</h1>
Kit ✅
<!-- $ myVar = We finish each other's sandwiches. -->
<p> <!-- $ myVar --> </p>
Sergey ❌

Does it do partials/includes?

Can you compose HTML from smaller parts?

Processor Example
Pug ✅
include includes/head.pug
ERB ✅
<%= render 'includes/head' %>
Markdown ❌
PHP ✅
<?php include 'head.php'; ?>
<?php include_once 'meta.php'; ?>
Slim ⚠️
If you have access to the Ruby code, it looks like it can do it, but you have to write custom helpers.
Haml ✅
.content
=render 'meeting_info'
Liquid ✅{% render head.html %}
{% render meta.liquid %}
Go html/template ✅{{ partial "includes/head.html" . }}
Handlebars ⚠️
Only through registering a partial ahead of time.
Mustache ✅{{> next_more}}
Twig ✅{{ include('page.html', sandboxed = true) }}
Nunjucks ✅{% include "missing.html" ignore missing %}
{% import "forms.html" as forms %}
{{ forms.label('Username') }}
Kit ✅<!-- @import "someFile.kit" -->
<!-- @import "file.html" -->
Sergey ✅<sergey-import src="header" />

Does it do local variables with includes?

As in, can you pass data to the include/partial for it to use specifically? For example, in Liquid, you can pass a second parameter of variables for the partial to use. But in PHP or Twig, there is no such ability—they can only access global variables.

Processor Example
PHP ❌
ERB ✅<%= render(
partial: "card",
locals: {
title: "Title"
}
) %>
Markdown ❌
Pug ❌
Slim ❌
Haml ✅.content
= render :partial => 'meeting_info', :locals => { :info => @info }
Liquid ✅{% render "name", my_variable: my_variable, my_other_variable: "oranges" %}
Go html/template ✅{{ partial "header/site-header.html" . }}
(The period at the end is “variable scoping.”)
Handlebars ✅{{> myPartial parameter=favoriteNumber }}
Mustache ❌
Twig ❌
Nunjucks ✅{% macro field(name, value='', type='text') %}
<div class="field">
<input type="{{ type }}" name="{{ name }}" value="{{ value | escape }}" />
</div>
{% endmacro %}
Kit ❌
Sergey ❌

Does it do loops?

Sometimes you just need 100 <div>s, ya know? Or more likely, you need to loop over an array of data and output HTML for each entry. There are lots of different types of loops, but having at least one is nice and you can generally make it work for whatever you need to loop.

Processor Example
PHP ✅for ($ i = 1; $ i <= 10; $ i++) {
echo $ i;
}
ERB ✅<% for i in 0..9 do %>
<%= @users[i].name %>
<% end %>
Markdown ❌
Pug ✅for (var x = 1; x < 16; x++)
div= x
Slim ✅- for i in (1..15)
div #{i}
Haml ✅(1..16).each do |i|
%div #{i}
Liquid ✅{% for i in (1..5) %}
{% endfor %}
Go html/template ✅{{ range $ i, $ sequence := (seq 5) }}
{{ $ i }}: {{ $ sequence }
{{ end }}
Handlebars ✅{{#each myArray}}
<div class="row"></div>
{{/each}}
Mustache ✅{{#myArray}}
{{name}}
{{/myArray}}
Twig ✅{% for i in 0..10 %}
{{ i }}
{% endfor %}
Nunjucks ✅{% set points = [0, 1, 2, 3, 4] %}
{% for x in points %}
Point: {{ x }}
{% endfor %}
Kit ❌
Sergey ❌

Does it have logic?

Mustache is famous for philosophically being “logic-less”. So sometimes it’s desirable to have a templating language that doesn’t mix in any other functionality, forcing you to deal with your business logic in another layer. Sometimes, a little logic is just what you need in a template. And actually, even Mustache has some basic logic.

Processor Example
Pug ✅#user
if user.description
h2.green Description
else if authorised
h2.blue Description
ERB ✅<% if show %>
<% endif %>
Markdown ❌
PHP ✅<?php if (value > 10) { ?>
<?php } ?>
Slim ✅- unless items.empty?If you turn on logic less mode:
- article
h1 = title
-! article
p Sorry, article not found
Haml ✅if data == true
%p true
else
%p false
Liquid ✅{% if user %}
Hello {{ user.name }}!
{% endif %}
Go html/template ✅{{ if isset .Params "title" }}
<h4>{{ index .Params "title" }}</h4>
{{ end }}
Handlebars ✅{{#if author}}
{{firstName}} {{lastName}}
{{/if}}
Mustache ✅
It’s kind of ironic that Mustache calls itself “Logic-less templates”, but they do kinda have logic in the form of “inverted sections.”
{{#repo}}
{{name}}
{{/repo}}
{{^repo}}
No repos :(
{{/repo}}
Twig ✅{% if online == false %}
Our website is in maintenance mode.
{% endif %}
Nunjucks ✅{% if hungry %}
I am hungry
{% elif tired %}
I am tired
{% else %}
I am good!
{% endif %}
Kit ✅
It can output a variable if it exists, which it calls “optionals”:
<dd class='<!-- $ myVar? -->'> Page 1 </dd>
Sergey ❌

Does it have filters?

What I mean by filter here is a way to output content, but change it on the way out. For example, escape special characters or capitalize text.

Processor Example
Pug ⚠️
Pug thinks of filters as ways to use other languages within Pug, and doesn’t ship with any out of the box.
ERB ✅
Whatever Ruby has, like:
"hello James!".upcase #=> "HELLO JAMES!"
Markdown ❌
PHP ✅$ str = "Mary Had A Little Lamb";
$ str = strtoupper($ str);
echo $ str; // Prints MARY HAD A LITTLE LAMB
Slim ⚠️
Private only?
Haml ⚠️
Very specific one for whitespace removal. Mostly for embedding other languages?
Liquid ✅
Lots of them, and you can use multiple.
{{ "adam!" | capitalize | prepend: "Hello " }}
Go html/template ⚠️
Has a bunch of functions, many of which are filter-like.
Handlebars ⚠️
Triple-brackets do HTML escaping, but otherwise, you’d have to register your own block helpers.
Mustache ❌
Twig ✅{% autoescape "html" %}
{{ var }}
{{ var|raw }} {# var won't be escaped #}
{{ var|escape }} {# var won't be doubled-escaped #}
{% endautoescape %}
Nunjucks ✅{% filter replace("force", "forth") %}
may the force be with you
{% endfilter %}
Kit ❌
Sergey ❌

Does it have math?

Sometimes math is baked right into the language. Some of these languages are built on top of other languages, and thus use that other language to do the math. Like Pug is written in JavaScript, so you can write JavaScript in Pug, which can do math.

Processor Support
PHP ✅<?php echo 1 + 1; ?>
ERB ✅<%= 1 + 1 %>
Markdown ❌
Pug ✅- const x = 1 + 1
p= x
Slim ✅- x = 1 + 1
p= x
Haml ✅%p= 1 + 1
Liquid ✅{{ 1 | plus: 1 }}
Go html/template ✅
{{add 1 2}}
Handlebars ❌
Mustache ❌
Twig ✅{{ 1 + 1 }}
Nunjucks ✅{{ 1 + 1 }}
Kit ❌
Sergey ❌

Does it have slots / blocks?

The concept of a slot is a template that has special areas within it that are filled with content should it be available. It’s conceptually similar to partials, but almost in reverse. Like you could think of a template with partials as the template calling those partials to compose a page, and you almost think of slots like a bit of data calling a template to turn itself into a complete page. Vue is famous for having slots, a concept that made its way to web components.

Processor Example
PHP ❌
ERB ❌
Markdown ❌
Pug ✅
You can pull it off with “mixins”
Slim ❌
Haml ❌
Liquid ❌
Go html/template ❌
Handlebars ❌
Mustache ❌
Twig ✅{% block footer %}
© Copyright 2011 by you.
{% endblock %}
Nunjucks ✅{% block item %}
The name of the item is: {{ item.name }}
{% endblock %}
Kit ❌
Sergey ✅<sergey-slot />

Does it have a special HTML syntax?

HTML has <angle> <brackets> and while whitespace matters a little (a space is a space, but 80 spaces is also… a space), it’s not really a whitespace dependant language like Pug or Python. Changing these things up is a language choice. If all the language does is add in extra syntax, but otherwise, you write HTML as normal HTML, I’m considering that not a special syntax. If the language changes how you write normal HTML, that’s special syntax.

Processor Example
PHP ❌
ERB In Ruby, if you want that you generally do Haml.
Markdown ✅
This is pretty much the whole point of Markdown.
# Title
Paragraph with [link](#link).

- List
- List

> Quote
Pug ✅
Slim ✅
Haml ✅
Liquid ❌
Go html/template ❌
Handlebars ❌
Mustache ❌
Twig ❌
Nunjucks ❌
Kit ⚠️
HTML comment directives.
Sergey ⚠️
Some invented HTML tags.

Wait wait — what about stuff like React and Vue?

I’d agree that those technologies are component-based and used to do templating and often craft complete pages. They also can do many/most of the features listed here. Them, and the many other JavaScript-based-frameworks like them, are also generally capable of running on a server or during a build step and producing HTML, even if it sometimes feels like an afterthought (but not always). They also have other features that can be extremely compelling, like scoped/encapsulated styles, which requires cooperation between the HTML and CSS, which is an enticing feature.

I didn’t include them because they are generally intentionally used to essentially craft the DOM. They are focused on things like data retrieval and manipulation, state management, interactivity, and such. They aren’t really focused on just being an HTML processor. If you’re using a JavaScript framework, you probably don’t need a dedicated HTML processor, although it absolutely can be done. For example, mixing Markdown and JSX or mixing Vue templates and Pug.

I didn’t even put native web components on the list here because they are very JavaScript-focused.

Other considerations

  • Speed — How fast does it process? Do you care?
  • Language — What was in what is it written in? Is it compatible with the machines you need to support?
  • Server or Build – Does it require a web server running to work? Or can it be run once during a build process? Or both?

Superchart

Templating Includes Local Variables Loops Logic Filters Math Slots Special Syntax
PHP ✅ ✅ ❌ ✅ ✅ ✅ ✅ ❌ ❌
ERB ✅ ✅ ✅ ✅ ✅ ✅ ✅ ❌ ⚠️
Markdown ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ✅
Pug ✅ ✅ ❌ ✅ ✅ ⚠️ ✅ ✅ ✅
Slim ✅ ⚠️ ❌ ✅ ✅ ⚠️ ✅ ❌ ✅
Haml ✅ ✅ ✅ ✅ ✅ ⚠️ ✅ ❌ ✅
Liquid ✅ ✅ ✅ ✅ ✅ ✅ ✅ ❌ ❌
Go html/template ✅ ✅ ✅ ✅ ✅ ⚠️ ✅ ❌ ❌
Handlebars ✅ ⚠️ ✅ ✅ ✅ ❌ ❌ ❌ ❌
Mustache ✅ ✅ ❌ ✅ ✅ ❌ ❌ ❌ ❌
Twig ✅ ✅ ❌ ✅ ✅ ✅ ✅ ✅ ❌
Nunjucks ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ❌
Kit ✅ ✅ ❌ ❌ ✅ ❌ ❌ ❌ ⚠️
Sergey ❌ ✅ ❌ ❌ ❌ ❌ ❌ ✅ ⚠️

The post Comparing HTML Preprocessor Features appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.

CSS-Tricks

, , ,
[Top]

You don’t need external assets in an HTML file

Posted on September 8, 2021 in Design

A fun exercise from Terence Eden. You can send an HTML file over the wire including anything a website might need without requesting any other files. CSS and JavaScript are easy, because there are <script> and <style> tags. Images and fonts (and pretty much whatever other kind of asset) aren’t too hard because Data URLs exist. See Terence’s post for an extra-tricky final version including .zip files.

Reminds me of a couple of other tricks…

Direct Link to Article — Permalink

The post You don’t need external assets in an HTML file appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.

CSS-Tricks

, , , , ,
[Top]

Tabs in HTML?

Posted on August 17, 2021 in Design

You know what tabs are, Brian.

I mean… You use them every day, on every OS. Everybody knows they exist in every toolbox. All that’s left is to “just pave the cowpaths!” But when you get right down to it, it’s a lot more complicated than that.

Brian Kardell shares a bit about the progress of bringing “Tabs” to HTML. We kinda think we know what they are, but you have to be really specific when dealing with specs and defining them. It’s tricky. Then, even if you settle on a solid definition, an HTML expression of that isn’t exactly clear. There are all kinds of expressions of tabs that all make sense in their own way. Imagine marking up tabs where you put all the tabs as a row of links or buttons up top, and then a bunch of panels below that. They call that a “Table of Contents” style of markup, and it makes some kind of logical sense (“the markup looks like tabs already”). But it also has some problems, and it looks like sections-with-headers is more practical (“If you have the heading, you can build the TOC, but not vice-versa”). Spicy sections are a totally different pattern. And that’s just one problem they are facing.

I don’t envy the work, but I look forward to the progress in no small part because authoring tabs is tricky business. Not hard to do, but very hard to do right. I’ve talked in the past about how I’ve built tabs many times in jQuery where just a click handler on a row of links hides or shows some matching divs below. That “works” if you ignore accessibility entirely (e.g. how you navigate between tabs, focus management, ARIA expectations, etc).

Here’s the ShopTalk discussion and here’s a different perspective in a chat I had with Stephen on CodePen Radio where we get into our <Tabs /> React component on CodePen.

Direct Link to Article — Permalink

The post Tabs in HTML? appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.

CSS-Tricks

,
[Top]

HTML is Not a Programming Language?

Posted on August 16, 2021 in Design

HTML is not a programming language.

I’ve heard that sentence so many times and it’s tiring. Normally, it is followed by something like, It doesn’t have logic, or, It is not Turing complete,.so… obviously it is not a programming language. Like it’s case-closed and should be the end of the conversation.

Should it be, though?

I want to look at typical arguments I hear used to belittle HTML and offer my own rebuttals to show how those claims are not completely correct.

My goal is not to prove that HTML is or is not a programming language, but to show that the three main arguments used for claiming it is not are flawed or incorrect, thus invalidating the conclusion from a logical point of view.

“HTML is a markup language, not a programming language”

This statement, by itself, sounds great… but it is wrong: markup languages can be programming languages. Not all of them are (most are not) but they can be. If we drew a Venn diagram of programming languages and markup languages, it would not be two separate circles, but two circles that slightly intersect:

A markup language that operates with variables, has control structures, loops, etc., would also be a programming language. They are not mutually exclusive concepts.

TeX and LaTeX are examples of markup languages that are also considered programming languages. It may not be practical to develop with them, but it is possible. And we can find examples online, like a BASIC interpreter or a Mars Rover controller (which won the Judges’ prize in the ICFP 2008 programming contest).

While some markup languages might be considered programming languages, I’m not saying that HTML is one of them. The point is that the original statement is wrong: markup languages can be programming languages. Therefore, saying that HTML is not a programming language because it is a markup language is based on a false statement, and whatever conclusion you arrive at from that premise will be categorically wrong.

“HTML doesn’t have logic”

This claim demands that we clarify what “logic” means because the definition might just surprise you.

As with Turing-completeness (which we’ll definitely get to), those who bring this argument to the table seem to misunderstand what it is exactly. I’ve asked people to tell me what they mean by “logic” and have gotten interesting answers back like:

Logic is a sensible reason or way of thinking.

That’s nice if what we’re looking for is a dictionary definition of logic. But we are talking about programming logic, not just logic as a general term. I’ve also received answers like:

Programming languages have variables, conditions, loops, etc. HTML is not a programming language because you can’t use variables or conditions. It has no logic.

This is fine (and definitely better than getting into true/false/AND/OR/etc.), but also incorrect. HTML does have variables — in the form of attributes — and there are control structures that can be used along with those variables/attributes to determine what is displayed.

But how do you control those variables? You need JavaScript!

Wrong again. There are some HTML elements that have internal control logic and don’t require JavaScript or CSS to work. And I’m not talking about things like <link> or <noscript> – which are rudimentary control structures and have been part of the standard for decades. I’m referring to elements that will respond to the user input and perform conditional actions depending on the current state of the element and the value of a variable. Take the <details>/<summary> tuple or the <dialog> element as examples: when a user clicks on them, they will close if the open attribute is present, and they will open if it is not. No JavaScript required.

So just saying alone that HTML isn’t a programming language because it lacks logic is misleading. We know that HTML is indeed capable of making decisions based on user input. HTML has logic, but it is inherently different from the logic of other languages that are designed to manipulate data. We’re going to need a stronger argument than that to prove that HTML isn’t a form of programming.

“HTML is not ‘Turing complete’”

OK, this is the one we see most often in this debate. It’s technically correct (the best kind of correct) to say HTML is not Turing complete, but it should spark a bigger debate than just using it as a case-closing statement.

I’m not going to get into the weeds on what it means to be Turing complete because there are plenty of resources on the topic. In fact, Lara Schenck summarizes it nicely in a post where she argues that CSS is Turning complete:

In the simplest terms, for a language or machine to be Turing complete, it means that it is capable of doing what a Turing machine could do: perform any calculation, a.k.a. universal computation. After all, programming was invented to do math although we do a lot more with it now, of course!

Because most modern programming languages are Turing complete, people use that as the definition of a programming language. But Turing-completeness is not that. It is a criterion to identify if a system (or its ruleset) can simulate a Turing machine. It can be used to classify programming languages; it doesn’t define them. It doesn’t even apply exclusively to programming languages. Take, for example, the game Minecraft (which meets that criterion) or the card game Magic: The Gathering (which also meets the criterion). Both are Turing complete but I doubt anyone would classify them as programming languages.

Turing-completeness is fashionable right now the same way that some in the past considered the difference between compiled vs. interpreted languages to be good criteria. Yes. We don’t have to make a big memory effort to remember when developers (mainly back-end) downplayed front-end programming (including JavaScript and PHP) as not “real programming.” You still hear it sometimes, although now faded, mumbled, and muttered.

The definition of what programming is (or is not) changes with time. I bet someone sorting through punched cards complained about how typing code in assembly was not real programming. There’s nothing universal or written in stone. There’s no actual definition.

Turing-completeness is a fair standard, I must say, but one that is biased and subjective — not in its form but in the way it is picked. Why is it that a language capable of generating a Turing Complete Machine gets riveted as a “programming language” while another capable of generating a Finite State Machine is not? It is subjective. It is an excuse like any other to differentiate between “real developers” (the ones making the claim) and those inferior to them.

To add insult to injury, it is obvious that many of the people parroting the “HTML is not Turing complete” mantra don’t even know or understand what Turing-completeness means. It is not an award or a seal of quality. It is not a badge of honor. It is just a way to categorize programming languages — to group them, not define them. A programming language could be Turing complete or not in the same way that it could be interpreted or compiled, imperative or declarative, procedural or object-oriented.

So, is HTML a programming language?

If we can debase the main arguments claiming that HTML is not a programming language, does that actually mean that HTML is a programming language? No, it doesn’t. And so, the debate will live on until the HTML standard evolves or the “current definition” of programming language changes.

But as developers, we must be wary of this question as, in many cases, it is not used to spark a serious debate but to stir controversy while hiding ulterior motives: from getting easy Internet reactions, to dangerously diminishing the contribution of a group of people to the development ecosystem.

Or, as Ashley Kolodziej beautifully sums it up in her ode to HTML:

They say you’re not a real programming language like the others, that you’re just markup, and technically speaking, I suppose that’s right. Technically speaking, JavaScript and PHP are scripting languages. I remember when it wasn’t cool to know JavaScript, when it wasn’t a “real” language too. Sometimes, I feel like these distinctions are meaningless, like we built a vocabulary to hold you (and by extension, ourselves as developers) back. You, as a markup language, have your own unique value and strengths. Knowing how to work with you best is a true expertise, one that is too often overlooked.

Independent of the stance that we take on the “HTML is/isn’t a programming language” discussion, let’s celebrate it and not deny its importance: HTML is the backbone of the Internet. It’s a beautiful language with vast documentation and extensive syntax, yet so simple that it can be learned in an afternoon, and so complex that it takes years to master. Programming language or not, what really matters is that we have HTML in the first place.

The post HTML is Not a Programming Language? appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.

CSS-Tricks

, ,
[Top]

Detect Unused Classes in… HTML

Posted on June 16, 2021 in Design

Usually, when “unused” comes up in conversation regarding CSS, it’s about removing chunks of CSS that are not used in your site or, at least, the styles not currently in use on a specific page. The minimal amount of CSS is best! I’ve written about how this is a hard problem in the past. In JavaScript-land, the equivalent is tree shaking (removing unusued JavaScript).

But what about the other way around, detecting classes in HTML that aren’t used in your CSS? If you knew this for sure, you could clean up your markup, removing classes that don’t do anything.

I saw Robert Kieffer post a Gist the other day with an interesting solution. The idea is to load up document.styleSheets and find all the rules (the ones that are classes). Then, use a MutationObserver to watch the DOM for all HTML, and check the classList of each node to see if it matches any from any stylesheet. If the HTML has a class not found in a stylesheet, report it.

I gave it a quick whirl and got it working and correctly reporting unused classes:

Your mileage may vary. For one thing, this script is set up as an ES Module. That means if you just import it and run it on a regular ol’ HTML document, it won’t find anything because your <script type="module"> is deferred and the MutationObserver won’t pick anything up. I just un-moduled it and put it in the <head> to make my demo work.

I Netlify Dropped the site online in case you wanna dig into it and check it out. I would have used CodePen, but CodePen doesn’t link up your styles as <link>ed stylesheets (by default, but you could use external resources to do that). I just thought it would be more clear as a deployed site.

Careful now.

Just like unused CSS is a hard problem because of how hard it is to know for sure know if a ruleset is unused, this approach may be an even harder problem. For one thing, classes might be used as a JavaScript hook for things. Styles might get injected onto the page in <style> blocks, which this script wouldn’t check. Heck, you might have integration tests that run in CI that use classes to do testing-related things.

I’d say this kind of thing is a useful tool for havin’ a looksie at classes that you have a hunch might be unused. But I wouldn’t say there’s a permission slip to run this thing and then yank out every reported class without further investigation.

The post Detect Unused Classes in… HTML appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

CSS-Tricks

, , , ,
[Top]

VS Code Extensions for HTML

Posted on June 7, 2021 in Design

Let’s look at some extensions for VS Code that make writing and editing HTML (and languages that are basically HTML with extra powers) better. You may not like all of them. Maybe some of them don’t appeal to you, solve a problem you don’t have, or feel like more clutter than you need. That’s OK. These are just a handful that I’ve tried and liked to some degree.

I’d start with Emmet here, even thought it’s not technically an extension1 for VS Code. It’s built right in. You should know about it though because it’s very useful. It does “HTML Expansions” like this, which I use pretty much every day of my life:

HTML End Tag Labels

I heard about this one from Stefan Judis who blogged about it the other day and inspired this post idea.

The whole idea is that rather than you leaving comments in your HTML to indicate what HTML element it is closing (a somewhat common practice, especially for partials that close elements that might not be opened in the same document).

<div class="main">   </div> <!-- / div.main -->  <?php /* / div.main */ ?> <?php /* Sometimes I'd do it in a server side language so it didn't go over the wire. */ ?>

This extension shows you UI about what HTML is being closed:

Auto Close Tag

As soon as you type the > in an HTML element, like the last bracket in <div>, the closing tag is automatically created for you.

It can be configured to only auto close after you’ve typed the </ to indicate you’re about to close a tag, which is a default in Sublime Text 3. Speaking of which, if you install the Sublime Text Keymap, you’d get that automatically, plus a handful of other fancy key commands.

There is also Close HTML/XML tag, but it only works via key command. With Auto Close Tag you can configure it either way, and it has far more installs for whatever reason.

Highlight Matching Tag

Here’s the GIF from their docs:

I was going to do my own video, but I discovered that even if I have this extension off, something else in my VS Code is highlighting matching tags anyway. I’m not entirely sure what it is, which leads me to believe it might be a built-in feature now.

What I see without this extension on: a border around the matching tags.

Not specific to HTML, but if like this sort of help with matching things, you might give Bracket Pair Colorizer 2 a try, which can be quite nice for CSS and JavaScript.

Auto Rename Tag

I find this one quite useful!

I believe this functionality is actually built into the canonical Emmet, but again, VS Code doesn’t use canonical Emmet so this feature isn’t there, hence the need for this extra plugin.

Better Comments

I leave code comments fairly liberally, especially when dev’ing out new things. A convention I like is when a comment is prefixed (e.g. TODO) that it is extra important and needs attention. Better Comments allows those to look visually different.

Code Spell Checker

There is no spell-checking in VS code. I don’t love that. To me this plugin is a must-have, especially for HTML, because HTML typically has content in it, like words, that should be spelled correctly. And just like a linter, this plugin gives you squiggles when something is wrong and a menu to attempt to fix it.

Indent Rainbow

Bask in this glorious rainbow created by deepening indents:

The point is that it gives you some visual cues to what level you’re currently looking/working at. In that sense it’s kinda like the Highlight Matching Tag, but I like them both honestly. It’s most useful when you need to scroll up or down to find where the matching tag is.

Prettier

Prettier does work on HTML, but I’d almost call it a smidge controversial. For example, it breaks HTML attributes onto single lines which feels a lot like a JSX thing but less common to see in raw HTML. But sometimes there are literal side effects. Like if you type <ul><li></li><li></li></ul> on purpose like that (no whitespace) because you’re going to set all the list items inline, Prettier will break them onto their own lines, inserting whitespace, and changing the layout of what you intend. You can always fix it with a comment for Prettier to leave it alone (e.g. {/* prettier-ignore */}), but I could see it rubbing people the wrong way. There are even settings for it under HTML Whitespace Sensitivity, but it could never be perfect.

I actually got Prettier for HTML working just for this blog post so I think I’ll keep it for a while and see if I like it. I already know I like Prettier for JSX. I’m generally for as much autoformatting as possible.

Snippet

I gotta imagine there are lots of snippet plugins, but this is the only one I’ve tried and it works fine. I like how you make snippets right from existing files.

Tabnine

I heard about this one from Kyle Simpson who I think was doing some paid consulting with them or something. The point of it is that it does fancy AI-powered autocomplete suggestions, even in HTML. Check out it guessing at some attributes:

This looks like a pretty commercial product with features that push you toward paid plans for teams. I don’t really feel like getting all into that; it was just interesting to see a tool like this work with HTML.

axe Accessibility Linter

This lints your HTML for accessibility problems right in the editor. There are a bunch of rules it checks for.

  1. Did you know even though VS Code has Emmet baked right in, there is no communication between Emmet’s creator and the VS Code team? I’ve tried to facilitate that connection in the past, but failed. Point being: Emmet in VS Code would probably be better if it wasn’t just jacked in but integrated from the official packages. Emmet has new things that VS Code could use, like expansion previews. ⮑

The post VS Code Extensions for HTML appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

CSS-Tricks

, ,
[Top]

A Love Letter to HTML & CSS

Posted on May 17, 2021 in Design

Ashley Kolodziej — May 2021

Dear HTML & CSS

I see you.

In the back there, behind JavaScript and React and PHP and all those “real” programming languages, I see you. And I appreciate you.

I’ve seen the YouTube videos. You’ve been condensed down to a sixty-second blip on the path to bigger and better things, a one-trick div pony at the back of the race. You’re a support character. Everyone knows HTML these days. Even if that’s not the case, it’s not hard to learn, they say.

I know it’s not true.

You are the foundation of the Internet. You are the bridge between humans and information. When we say HTML isn’t an expertise in and of itself, when we take you for granted, we leave behind the people and systems who access that information using web crawlers and accessibility technology.

They say you’re not a real programming language like the others, that you’re just markup, and technically speaking, I suppose that’s right. Technically speaking, JavaScript and PHP are scripting languages. I remember when it wasn’t cool to know JavaScript, when it wasn’t a “real” language too. Sometimes, I feel like these distinctions are meaningless, like we built a vocabulary to hold you (and by extension, ourselves as developers) back. You, as a markup language, have your own unique value and strengths. Knowing how to work with you best is a true expertise, one that is too often overlooked.

Markup requires systematic thinking. What structure is the best match for this content? How can we make this content easier to discover and parse in the right order? What tags do we need to ensure a screen reader will parse your information correctly? I want you to know I know how important you are, and I still ask these questions.

I think of you every time I test a website in VoiceOver and discover it is completely unusable, with my keyboard’s focus jumping away to places I can’t actually interact with and no clear sectioning and headings to help navigate.

And to my longtime friend, CSS. I want you to know I understand you are so much more than just a pretty face. Sure, your main job is to, well, style markup. But why should that be any less celebrated than the other languages? You are the visual translation of information. What good is all the information in the world if we can’t easily understand it? You hold the keys to hierarchy and contrast and layout, the keys to visual communication.

Your language is an art. I recognize your importance, the balance of performance in rendering and specificity and predicting when and where other systems or designers might want to override something. Sure, you style, and you style well. But what the world forgets sometimes is you are, at heart, a planner: the cascading part of Cascading Style Sheets. Oh, to be JavaScript where you can do whatever you want, whenever you want, and change markup and styles on the fly. Don’t they know inline styles are some of the most specific styles around?

I know, and I respect that. There is a time and place for specificity, and I cherish your ability to manage that. I love your system of overrides, of thinking ahead to what should and shouldn’t be modifiable by another developer easily. I find the appreciation of specificity and !important and contrast and all the beautiful little things you do well increasingly lost in the pursuit of the newest and shiniest frameworks.

But I am still here for you, HTML and CSS. And I will continue to show everyone I can how much you both have to offer. Because without that foundational care and expertise, we wouldn’t be able to communicate this information at all. You are the languages at the core of equitable information distribution, and I want you to know that even if you aren’t in the spotlight right now, I remember that.

Even if it sometimes feels I’m the only person out there who still does.

With love, Ashley Kolodziej

The post A Love Letter to HTML & CSS appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

CSS-Tricks

, ,
[Top]

HTML Boilerplates

Posted on May 14, 2021 in Design

Manuel Matuzović goes line-by-line through a boilerplate HTML document. I like it. It’s a good reference and has a lot of the same type of stuff I tend to put in the main HTML template. It makes me think about how opinionated this kind of thing can be. Dang near every line! Not the DOCTYPE, not the <title>, but nearly everything else.

The HTML 
<!DOCTYPE html> <html lang="en" class="no-js"> <head>   <meta charset="UTF-8">   <meta name="viewport" content="width=device-width">    <title>Unique page title - My Site</title>    <script type="module">     document.documentElement.classList.remove('no-js');     document.documentElement.classList.add('js');   </script>    <link rel="stylesheet" href="/assets/css/styles.css">   <link rel="stylesheet" href="/assets/css/print.css" media="print">    <meta name="description" content="Page description">   <meta property="og:title" content="Unique page title - My Site">   <meta property="og:description" content="Page description">   <meta property="og:image" content="https://www.mywebsite.com/image.jpg">   <meta property="og:image:alt" content="Image description">   <meta property="og:locale" content="en_GB">   <meta property="og:type" content="website">   <meta name="twitter:card" content="summary_large_image">   <meta property="og:url" content="https://www.mywebsite.com/page">   <link rel="canonical" href="https://www.mywebsite.com/page">    <link rel="icon" href="/favicon.ico">   <link rel="icon" href="/favicon.svg" type="image/svg+xml">   <link rel="apple-touch-icon" href="/apple-touch-icon.png">   <link rel="manifest" href="/my.webmanifest">   <meta name="theme-color" content="#FF00FF"> </head>  <body>   <!-- Content -->   <script src="/assets/js/xy-polyfill.js" nomodule></script>   <script src="/assets/js/script.js" type="module"></script> </body> </html>

Maybe my site doesn’t use any JavaScript or have no-JavaScript fallbacks so I don’t need any of the class name dancing. Maybe my site doesn’t need print styles, but I do need link prefetching. Maybe I don’t care about social images, but I do want critical CSS in the head. It’s a boilerplate, not a prescription — it’s meant to be changed.

There was a time when HTML5 Boilerplate was a huge project in this space. It has a whole GitHub Org! The boilerplate has 50,000 stars! Personally, I feel like the project lost its way when it started to have a src and dist folder and a 200-line Gulp build process, ya know? It worked best as a reference for what stuff any given web project might need, but now I feel like it is intimidating in a way it doesn’t need to be. The boilerplate index file is also quite opinionated. It assumes Normalize and Modernizr, which are certainly not deprecated projects, but also not things I see developers reaching for much anymore. It even assumes Google Analytics usage!

I have no problem with people having and sharing boilerplate documents, but considering how unavoidable being opinionated it is with them, I also like the reference guide approach. Just show me every possible thing that can go in the <head> (a lot of the value of these boilerplates), and I’ll pick and choose what I need (or may have forgotten). To that end, Josh Buchea’s HEAD project is pretty cool.

The post HTML Boilerplates appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

CSS-Tricks

,
[Top]