Posts tagged with ‘web’ - page 2

Things about CSS that make me want to put my face in a blender



When you enter a margin value such as:

margin: 12% 24%;

the vertical value is taken as a percentage of the height of the parent and the horizontal value is taken as a percentage of the width of the parent. This makes sense.

If I enter the same values as padding:

padding: 12% 24%;

the vertical value is taken from the width of the element (horizontal), and the horizontal value is taken from the height of the element (vertical). This is stupid.

The only time this has ever been of any use to me whatsoever in four years of writing CSS has been when forcing the aspect ratio of an element like so:

height: 0;
padding: 0 0 50%;  /* Forces a 2:1 aspect ratio. */

You know what would be far more useful? Make the horizontal and vertical the right way around, and give us an aspect ratio property. Not only would this make aspect ratios an actualproperthing™ rather than a hack, it also allow us to finally vertically center things properly.

/* 25% of the element's height will be
    whitespace above and below its children,
    making them vertically centered (Hurrah!) */
padding: 25% 0;

/* The elements width will be double that
    of its height, which is determined by
    the flow of content. */
height: auto;
width: auto;
aspect-ratio: 1 2;

Exes and Whys?

margin: Y X;
padding: Y X;
border: Y X;
outline: Y X;
background-position: X Y;
transform: translate(X, Y);
transform: scale(X, Y);

Why, dear God, Why???

Fixed positioned elements

I set some elements at a certain size.

.parent {
  width: 50%;
    .parent .child {
      width: 30%;

.child is 30% of the width of it’s parent. Nice and easy. Then I add position: fixed; to the child.

.parent {
  width: 50%;
    .parent .child {
      width: 30%;
      position: fixed;

Boom! .child has now doubled in width. That makes sense doesn’t it? No.


I only ever use solid borders, because anything else is harder to see than a true word in the Daily Mail.

I want to write

border: blue;

and have it give me a 1px wide, solid blue border.

border: 5px blue;

gives me a 5px, solid blue border. Easy peasy.


background-position: top center;

is a nice easy way to position a background. At the moment, to absolutely position an element in this way, I have to do this:

width: 300px;
position: absolute;
top: 0;
left: 50%;
margin-left: -150px;

If the width is dynamic, the above is impossible without a javascript hack. This would be better:

position: top center;  /* Boom! */

Screenreaders and the web


Mention alt text to a room of web developers and you’ll likely start an argument. Should they be ignored for decorative images? Should they ever be left blank? And is anyone brave enough to say alt=" "?

Everyone has their own methods for implementing accessibility. Some are innovative, some are better than others, some are downright lazy. All however, are less than ideal, as every screenreader reads assets, code and content differently.

An alt attribute on an image is a prime example. If empty, some screenreaders will announce “Image” and nothing else. Some will announce the filename. Some will announce the title if one is present. Some will ignore the image altogether. And when included, an alt attribute is often a cop-out, an afterthought thrown in to please those who get angry about this sort of thing. Take a look at the below image:

Portrait of James Dinsdale

Those of you readers who are blessed with sight have just been treated to the pretty face of yours truly. However those users without sight simply heard “Portrait of James Dinsdale”. Where is the additional context that sighted readers enjoy? Where is the description, telling those who cannot deduce it by looking my age, race, approximate height, eye colour, hair colour, clothes, facial expression, surroundings. All these things are detected by sighted users in a matter of seconds, but for a user using a screenreader they will never be privy to this information, as alt text never goes into as much detail.

For textual content also, the mechanical, impersonal voices employed by screenreaders do little to convey the tone, emphasis and thought lovingly put into the article by the author. Where is the long pause after that poignant sentence? Where is the different voices and accents that we readers imagine when reading a written conversation? Where is the correct pronunciation when reading a name, or a word in a different language slipped into a paragraph?

In other forms of media, additional context is readily provided. Many books and magazines have audiobook counterparts for those users with poor or no sight; audible descriptions are provided for films and television programs; transcripts are provided for video and podcasts to assist the hard of hearing, but the web falls a long way behind these forms when it comes to providing a totally immersive experience for all, regardless of ability. Great steps have been made, no doubt, but more could be done.

What the web needs, is an audio attribute for images and content. The value of this attribute would be the path to an audio file, in which an image is described in detail by a real person, or an article is read aloud by the author, in exactly the context intended. Image alt attributes would still have a place, providing a short description allowing the user to then make a decision as to whether or not they would like to hear the full description. If they decide to hear more information, the audio file is downloaded and played in the background.

Yes, creating audio files for every body of text or image on a website would be a lot of work, but not every item would require it. An address, for example, does not need quite the same joie de vivre as an enthusiastic, thought-provoking article. But for important elements within a web page this would provide a much more personal experience to non-sighted users, something which is currently lacking.

If anyone knows where I can go to recommend this sort of thing be implemented into accessibility specifications I’d love to know about it.



There are plenty of programming languages out there. Everyone has their favourite, and many, like me, probably have a list as long as their arm of languages they’d like to learn. Every language has a selection of frameworks, designed to make them easier to build apps with. Many are incredibly useful. jQuery for instance, has taken the web design world by storm, and it’s quite rare to see a site nowadays that doesn’t make use of it. Laravel and CodeIgniter for PHP are very highly regarded, as is Rails for Ruby development.

The problem is, with many of these, it’s easier to learn and use the framework than it is to use the base language itself. I myself was guilty of this when I first started learning jQuery many years ago. It’s only within the last year that I’ve taken the time to actually learn and understand the JavaScript code underneath it. And you know what? Since doing that I’ve found that in a number of instances, where before I would have jumped straight into jQuery without thinking, I now use vanilla JavaScript as much as possible.

The same can be said for other languages. The best way to learn how to use a language is to learn the vanilla language first. With PHP, if you jump straight into Laravel or CodeIgniter, you’ll likely be lost when looking at vanilla PHP and trying to use one of the additional functions from the framework. All my PHP and Ruby development is done vanilla, no framework. I simply don’t currently work on applications on the sort of scale at which a framework would give me any benefit. That doesn’t make me a bad person.

Learn the language first, and any of the frameworks will be almost second nature, and you can choose the right tool for the job, rather than relying on a huge framework when all you need are a few simple server-side calls.

Frameworks should be a tool allowing you to do the best job you can, not a mandated starting point.