This is the presentation of a talk about the creative use of webstandards. This document itself uses the
CSS presentation mode, at the time
of writing only supported by the Opera Browser.
If you're viewing this page with Opera, simply enter fullscreen mode (
F11) and you'll see
the presentation. Use Page Down and Page Up to navigate between the slides.
If viewed normally additional text is shown explaining the concepts outlined in the presentation.
Alternatively you can switch to the
Green Projection style. In Firefox you can switch the style
by selecting View → Page Style → Green Projection. On Opera it's Menu
→ Page → Style → Green Projection. Sorry, I was to lazy to implement a small
I held the talk at the
WebDay 2010 of the
HdM Stuttgart. If you have questions or any other
kind of feedback feel free to send me a mail.
What is this about?
Too much new stuff:
frameworks, libraries, …
Do we really
always need all of it? Goal: get stuff done with less overhead
If you're a web developer you probably have plenty to read: new versions of your favorite frameworks, new browser
versions, new libraries and plugins… and all with new features that want to be understood and
used. All of it for you to get more stuff done in less time.
In web development the trend to use frameworks has increased in the last years. They often provide an enormous
amount of features that help you in almost all the needs you'll ever have as a web developer. But this comes at a
cost: you need to learn and understand the framework as well as the underlying principals of it. Otherwise it can
happen that you will work against the framework in more complex cases and have to
bend it to your will.
Learning a framework can take quite some time and as the software changes it boils down to memorizing all the
new stuff and choose the right piece of software for the task at hand.
But do we really
always need all those features? A lot of projects are big and feature rich and therefore
will profit from the features of frameworks, but there are also quite some small and medium sized projects out there
(e.g. student projects or internal company stuff). Do these projects really need all of those features? Do we really need to
memorize all the latest and greatest of the web to build a small weblog with maybe 3 dynamic pages?
Well, ultimately this of course if a matter of preference. But the web as we know it is build on top of a whole bunch of
technologies that are always there. If you take a closer look many of them provide astonishing features by themselves out of
the box. Technologies like HTTP, HTML, CSS, different webservers and databases… to name just a few. Every developer comes
into contact with them at one point or another. If we are lucky and know what we need we can use the features of
these technologies directly to get stuff done without the need of added complexity and maintenance for frameworks or
libraries. By using the few technologies that are always there and don't change that fast it's more about creative combination
of features and technologies to get what you want instead of memorizing or searching a gigantic pool of features for just
the right thing.
Why keep it simple
Easy to understand
Less code, less bugs
Lower maintenance and overhead
But: Abstraction, complexity, many features (good for sales!), …
And: Some things just aren't simple
Keeping your code simple will make it easier for others to understand your code… or for yourself if you worked on another
project for two months and are asking yourself what your old code was supposed to do.
Focusing on the absolutely essential features will lead to less code and therefore less bugs. Programming with the the future
of your project in mind is a good thing, but don't add stuff or complexity for situations that are not important for the task at hand.
You don't need to worry much about scalability if your blog has 20 visitors a day. For the blog of Steve Jobs this might be
important but not for the average student, webdeveloper or employee.
However not all stuff can be simple. Sometimes we want abstraction for e.g. database access. We don't want to write new code
for every database our project might use as backend in the future. Therefore we create or use an abstraction and avoid duplication
of logic. On the other hand we lose the ability to use special features of some databases and have to live with added complexity.
Another reason for this, especially in commercial projects, is the need to add new features. If you want to sell your software
you need to provide some kind of benefit your customers are willing to pay for. This leads to more and more features over time,
even if they don't add much to the original purpose of your software. Who knows all the features of MS Office? Who uses all of
And sometimes there are projects that are just not simple. A thing like the Linux kernel has to do very much complex stuff and
those things just can not stay simple. At least if you want it to work with almost all computers out there.
Know your tools
The fun part
Every HTTP request usually involves more than one technology on it's way to the user. The browser sends a request via
HTTP to the server which then answers with an HTTP response. On the server side often a language like PHP, Ruby or Python
is involved to build the response and in turn these often read data from some kind of storage (e.g. a database or key-value
store). However most webservers can do much more than just pass through data to the client. They usually provide
many features we can use and don't have to implement in our application, thus keeping it more simple. After all a webserver
is always there…
On the client side several technologies are used to build the website. Some can help us building our website in a simpler
AJAX). These technologies are often have some not so well know features that can be used in uncommon but handy ways,
like presentations with HTML and CSS, interactive images with SVG or using HTML and CSS to do your office work.
What we all stand upon…
HTTP is the foundation of the internet and REST describes the principals behind HTTP. Just like object orientation
is the principal behind Java, REST is the principal behind HTTP. REST in itself is a much wider topic than shown
here but in every day practice it boils down to using the right HTTP methods and setting the right HTTP headers.
If that is done the whole internet works for you and you can profit from caching and many other advantages. If you
have been able to avoid keeping client state on your server (e.g. by storing the clients session within a cookie) you
also get scalability and load balancing for free.
How which HTTP method should behave can be found in the section
Method Definitions of the HTTP RFC. It's not very
complex and explains in a compact way what which method should be used for and what it should return.
Slavery is illegal… theoretically
Short and clean URLs are nice to look at but the rewriting process used to build them can be utilized for
much more. For example you can also use rewriting to redirect legacy URLs (e.g. map the old URL of a newsfeed
to the new URL). As a nice side effect of rewriting you also get kind of a map of you entire website in one place
(usually the virtual host configuration file). Another advantage is that clean URLs do not contain any
implementation details (e.g. the
php extension or the parameter names). This allows you to
change to a different system while using the same URLs.
If you're using the Apache webserver
contains many useful information. However mod_rewrite is very powerful and you can get lost in there very
easily. So just keep it simple for the start.
HTTP Basic auth
HTTP Digest auth
Easy and flexible configuration
Many backends: files, DBs, LDAP, …
Works well with REST
For simple projects the HTTP authentication of the webserver might be enough. It can be easily configured
and the Apache webserver features a wide variety of backends. It's worth to look into it because usually it's
quite some code needed to add authentication to a projects. With HTTP Digest the password is not transfered
in plain text and theoretically it also supports a single sign on over multiple domains. Unfortunately this is
only supported by Opera right now.
RFC 2617 (HTTP Authentication: Basic and Digest Access
Authentication) is definetly worth a look. If you want to dive in right away
mod_auth_basic show you
how. Browsers and webservers already support some fairly powerful authentication schemes so this might
spare you from programming it all over again in your project.
PHPs "template syntax"
PHP provides a nice "template like" syntax that can be used for the view logic of a website. For example
you could write the application logic of a page in one large block at the beginning of a PHP file and the view
logic with all the HTML around it after that. This provides a separation of application and view logic and still
keeps it simple for small projects. This can of course be extended in an arbitrary way, e.g. the template part
can be extracted into an extra file. However it gives you a very good starting point for free.
Streams make it very easy to work with external information like news feed or REST interfaces. And the
best part: it's already built into PHP. Not extra library needed, no increased maintenance overhead. It's also a
very flexible interface and if you set some additional HTTP header this isn't much of a problem.
Simple XML handling
SimpleXML and DOM
<?xml version="1.0" encoding="utf-8"?>
$feed = simplexml_load_file('news.xml');
Well, reading XML can hardly be easier than with SimpleXML. For more advanced stuff DOM is available and can
be used with XPath or to parse "real world" HTML code. Again no external library needed.
Atom feed reader
This is an example how Streams, SimpleXML and the template syntax of PHP can be used to write a little Atom
Atom newsfeed are simple in
their structure and well documented, RSS isn't much more complex either. For simple projects it's probably more work
to learn how to use a feedreader library.
Where did I put this…
Files! A simple hierarchical database
File browsers make management easy
Endless tools: text editor of choice, backups, version control, …
All the power of file systems:
SymLinks, TmpFS, UnionFS, EncFS, …
When webdevelopers think about storing data on the server for many the first thing that comes into mind is a
database like MySQL. For small projects however there might be a simpler way: text files. For example in a small
blog it can be easier to write the blog posts in text files and just write a small website that displays these text files
as HTML. You can use the standard file browser as "admin interface" and your favorite text editor to write and
edit posts. You don't have to maintain a database and get a vast number of tools that can be used for files: backup
is as simple as creating an archive of your text files and restoring it is also painless (everyone browses a ZIP
archive once in a while).
If you know some Linux or Unix basics you can utilize even more power of the file systems: if files are becoming
a bottleneck just put them on a RAM disk (TmpFS), add encryption with EncFS if you need it or use symbolic/hard
links to place a file in more than just one directory. The possibilities are only limited by your creativity.
Only a small but sometimes not noted improvement of the last few years: when using UTF-8 encoding for your website
you don't have to use those HTML entities any longer. UTF-8 can represent those characters directly without any trouble
and all people all over the world will see the same character.
A nice bonus of UTF-8 is its gigantic repository of characters and symbols. Want a real copyright symbol? Just use it: ©.
Need an arrow or a symbol for a keyboard? There are characters for these things too: → ⌨.
Every operating system features a character map somewhere that can be used to browse the world of Unicode and pick
the characters you like. There are also some tools available on the web like
UniView. These tools are not perfect but maybe you'll find
some characters you like.
HTML provides a wide range of tags that can be used to say what you really
mean. Writing a
headline right now? Mark it as one with an
h1-6 tag. Want to write a command the reader should
enter somewhere? Use the
kbd tag (text meant to be entered though the keyboard). HTML4 already
includes many of those tags and HTML5 adds even more. Its now possible to say that a part of your webpage is the
nav tag), a header or footer of a section (
an article (
article) and much more.
A look at the tags available in HTML4 and 5 and what they are meant to be used for can't hurt. Using proper tags for
your content will improve the accessibility of your website and make your styling in CSS easier.
HTML5 video should allow you to add videos to your website without the need for plugins or any fancy stuff.
Just drop in a
video tag and you're done. Well, unfortunately this is the theory but in practice
this topic has it's controversial spots. Namely what video format should be supported for every browser.
To insert a video that works in all modern browser you have to convert your video into two formats: Ogg
Theora (a free video format) and MPEG 4 (better quality but requires license fees from browser developers and
commercial users). This topic will hopefully be settled over time but for now this makes using HTML5 video not as
funny as it could be.
There is still quite some stuff you can do with it and if you want to dive in right now have a look at the
video chapter of
Dive Into HTML5.
Just a small feature of CSS: you can define styles that should only be used in "projection mode". That is
if a website is viewed on the beamer. This small detail enables you to actually create presentations with HTML
and CSS. If you're a webdeveloper you already use these technologies every day and now you can use them
to write your presentations. No more need for Powerpoint or Impress.
However these presentations are usual websites, just looking different on the beamer. But you can still use
key you can use the right arrow key to show the next list item on a slide. Same for the left arrow key that hides
soon as you press the p key (these small rectangles in the lower left corner slowly fading out).
As a webdevloper you can add whatever you want to a presentation. If you're really bored why not add a small
snake game using the
canvas element? A live chat so people in the internet can ask you questions
directly, a small server synchronizing your slides with the views of your presentation in the net… Again the
possibilities are only limited by your creativity.
All this however has a small downside: the presentation mode is currently only supported by Opera. In full
screen mode the browser is totally hidden and only your website is visible. You can do almost the same in other
browsers by manually switching to a different style for your presentation but a bit of the browser might still be
visible (scrollbars and such stuff).
Print media is another "mode" for which you can define different stylesheet. It's already used since several years
but only for basic stuff like hiding the navigation, header and footer because do don't want these printed. However
much more. All the features listed above allow you to built a stylesheet that does pretty
much everything you will encounter in most books. From chapter counters to footnotes, everything is just a few
CSS rules away.
Unfortunately PrinceXML is the only tool right now that supports these advanced print styles. Håkon Wium Lie
(more or less the inventor of CSS) used it to layout a whole book about micro formats.
Text and box shadows, border radius
CSS transforms and animations
Less need for graphics applications
But needs performance
The text and box shadows as well as the rounded corners simplify many aspects of webdesign that could previously only
be done with graphics applications like Photoshop, GIMP or Inkscape. Recreating a dummy website in a graphics application
has the advantage of a wide array of tools that can be used to experiment with the design. However the most common
effects used in webdesign can now be defined directly in CSS. Additionally the ability to define multiple text and box
shadows on one element allow for effects that are more difficult and time-consuming in graphics applications (for example
the glass effect used on headlines in this presentation). The article
Beautiful UI styling with CSS3 text-shadow, box-shadow, and border-radius provides a good and compact overview
of how you can achieve these effects.
In the area of interactivity CSS animations respectively transitions provide an easy way to define animations. What
CSS3 transitions and 2D transforms
is a good starting point for that.
The down side of these effects is performance. The work of the graphics applications is now done by the browser… and
this is easily noticeable with more complex effects.
If no direct links are provided in the text these sources can provide starting points for further reading. This presentation
gave just a short overview of many useful technologies but omitted at least as many details (after all it was just one hour).
I wanted to motivate webdevelopers to take a closer look at the technologies used every day. However browser
compatibility of many features needs to be taken into account
very carefully. After all this is the internet.
If you have questions of any kind or need help with some of the shown stuff feel free to
contact me. I'll gladly provide tips and help.
Thanks for listening!