How do we move logical shorthands forward?
There are several proposals, but one major road block
We’re trying to make progress on shorthand syntax for CSS logical properties. But the path forward depends on where we hope to be a decade from now.
(None of them is the username)
The term “username” is ambiguous. When designing a user model there are several kinds of names that are useful to include.
It’s time to start a new project. You want users, so the first thing you do is add a user model with username and password fields and – whoa, hold up.
What’s that username again? Is it the user’s email address? Is it an arbitrary nickname that the user can choose? Is it an automatically generated identifier that should never change?
It’s not for nothing that they say naming things is one of the hard problems in computer science. For modeling user accounts there are three different name fields that you probably want, and for the sake of avoiding confusion let’s not call any of them the username:
You probably noticed I did not include the user’s given and family names (and middle name and maiden name and…). Avoid collecting these as separate fields unless you need to, i.e. for official or legal purposes. Keep in mind that the preferred order of these names varies in different cultures (so avoid calling them “first name” and “last name”). And keep in mind that they may change over time. Names are hard.
We like Django for building backends. There are a number of ways to
extend Django’s default user model. Here’s our custom User
model that
meets the above guidelines:
from django.db import models
from django.contrib.auth.models import PermissionsMixin
from django.contrib.auth.base_user import AbstractBaseUser
class User(AbstractBaseUser, PermissionsMixin):
email = models.EmailField("email address", unique=True)
name = models.CharField("name", max_length=30, blank=True, unique=True)
date_joined = models.DateTimeField(_("date joined"), auto_now_add=True)
is_active = models.BooleanField(_("active"), default=True)
objects = UserManager()
USERNAME_FIELD = "email"
REQUIRED_FIELDS = []
def get_full_name(self):
return self.name
def get_short_name(self):
return self.name
Like all Django models, it has a default id
field which meets our
criteria for user id. There is a single name
field which is used
when Django needs to display the user’s name via the get_full_name
and
get_short_name
methods. And it has an email
field which enforces
uniqueness and is configured as Django’s USERNAME_FIELD (which is
really the login).
(Note: This model requires a custom UserManager
– I won’t include that
here; see Vitor Freitas’ helpful How to Extend the Django User Model
article for details.)
Add this model to a new Django project (it’ll be easiest if you use it from the start), configure it using the AUTH_USER_MODEL setting, and you’ll be well on your way to never having to say the word “username” again.
Did we miss anything important? Let us know via Twitter!
There are several proposals, but one major road block
We’re trying to make progress on shorthand syntax for CSS logical properties. But the path forward depends on where we hope to be a decade from now.
Can we get this process unstuck?
The CSS Working Group recently resolved to add a size
shorthand for setting both the width
and height
of an element. Many people asked about using it to set the ‘logical’ inline-size
and block-size
properties instead. But ‘logical shorthands’ have been stalled in the working group for years. Can we…
It’s not just a shorthand for anchor()
position-area
might be my favorite part of the CSS Anchor Positioning spec, with a ton of features packed in to make things just… work. But there’s no magic here, just a few key parts that work well.