Snippets

Today is Global Accessibility Awareness Day - a great day to be talking about accessibility.

[…]

Accessibility is for everyone, it’s not an edge case.

Accessibility is cumulative not binary, the more you do for accessibility the more accessible your site is.

Use semantic HTML, browsers have a lot of accessibility built in.

Make things keyboard operable by using the keyboard from time to time when you’re developing.

Finally, you don’t have to ask permission to make things accessible.

The easiest way is to ensure that the config has a dependency on your module.

dependencies:
  enforced:
    module:
      - yourmodule

Then Drupal will automatically remove that configuration and also warn in the UI that it will be removed.

The difference between a module’s install (i.e. required) config and optional config directories doesn’t seem well documented in Drupal 8, so this answer was quite informative:

• install: The folder can contain configs, like a view or any other config. All configs will be installed, if any config fails module can’t be installed.
• optional: The folder can contain configs, like a view or any other config. All configs will be installed if possible. If config has missing dependencies, it won’t be installed.

You’d be forgiven for thinking the point of this whole exercise is to shame the developers (you can always pick a name other than shame.css) but it’s really not. I am well aware of (and responsible for) hacks and quick fixes; your product owner doesn’t care if you used an !important, they just want the new feature out of the door. Hacks happen, fact.

shame.css is jokingly titled to make it a little light-hearted whilst also indicating that anything in there is a bit of a shame; a shame to have to have done, a shame to pollute the codebase with and so on…

By isolating all your hacks and bodge-jobs in their own file you can really easily keep tabs on them; isolating them isn’t to shame the developers, not at all, it’s merely to make the team aware of them and make them painfully, unmissably obvious.

The rules

Obviously you need some kind of rules and criteria:

1. If it’s a hack, it goes in shame.css.
2. Document all hacks fully:
   1. What part of the codebase does it relate to?
   2. Why was this needed?
   3. How does this fix it?
   4. How might you fix it properly, given more time?
3. Do not blame the developer; if they explained why they had to do it then their reasons are probably (hopefully) valid.
4. Try and clean shame.css up when you have some down time.
   1. Even better, get a tech-debt story in which you can dedicate actual sprint time to it.

This certainly seems like a good approach. That said, I personally prefer to have everything related to a component living with the component, but documented as a hack, possibly searchable via some sort of comment tag, like @hack <description>.

An opinionated styleguide for writing sane, maintainable and scalable Sass.

[T]he basic questions an empty state should answer are:

• What is this screen?
• Why am I seeing it?
• How can I fix this problem?

On top of this, you should aim to:

• Communicate personality. Make your app a joy to use and connect feelings with features.
• Explain the benefits. This is critical for your first-use empty states so your users know why they should care.

URI

A URI identifies a resource either by location, or a name, or both. More often than not, most of us use URIs that defines a location to a resource. The fact that a URI can identify a resources by both name and location has lead to a lot of the confusion in my opionion. A URI has two specializations known as URL and URN.

URN

A URI identifies a resource by name in a given namespace but not define how the resource maybe obtained. This type of URI is called a URN. You may see URNs used in XML Schema documents to define a namespace, usually using a syntax such as:

<xsd:schema xmlns="http://www.w3.org/2001/XMLSchema"
            xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            targetNamespace="urn:example"

Here the targetNamespace use a URN. It defines an identifier to the namespace, but it does not define a location.

URL

A URL is a specialization of URI that defines the network location of a specific resource. Unlike a URN, the URL defines how the resource can be obtained. We use URLs every day in the form of http://damnhandy.com, etc. But a URL doesn’t have to be an HTTP URL, it can be ftp://damnhandy.com, smb://damnhandy.com, etc.

The Difference Between Them

So what is the difference between URI and URL? It’s not as clear cut as I would like, but here’s my stab at it:

A URI is an identifier for some resource, but a URL gives you specific information as to obtain that resource. A URI is a URL and as one commenter pointed out, it is now considered incorrect to use URL when describing applications. Generally, if the URL describes both the location and name of a resource, the term to use is URI. Since this is generally the case most of us encounter everyday, URI is the correct term.