… and inaccessible.
What would happen if I populated regular pages like this? I guess most visitors would be none the wiser.
Have I ever mentioned that messing up web pages just for the fun of it, is not recommended?
bad ideas can be fun … in moderation…
“Just because I can”, is not always a good excuse for doing anything in web design, although it can be fun to go a little crazy at times. Good to know where the border-lines are, before deciding when, where and how to cross the same border-lines in order to get particular jobs done.
On this page I have intentionally gone a little overboard, and pushed the visual design well into what may turn out to be serious accessibility issues for some visitors. It is of course all done in accordance with the latest web design standards, but that doesn't help much for the stricken few. Just this time they will have to excuse me…
how NOT to put together a web page…
The main headlines and the first paragraph in this article, are put together with a mix of real text and
generated content. Those are followed by an element styled as a paragraph, that contains absolutely nothing.
This is of course a recipe for disaster, as generated content is supposed to be a purely visual,
feature. The generated content isn't in the source-code, and may or may not be accessible.
In this page's Addendum, all text is generated content. So although it may look quite normal to most visitors, in reality there is hardly any content there. A really, really bad idea.
This page is more of a demo for bad practices, and luckily such practices are rarely applied on live web sites. Knowing how generated content can but should not be used, may be of use to someone.
There are of course cases when text in the form of generated content works just fine. That is when whether the text shows up or not isn't a showbreaker. It is however not a reliable way to deliver vital information or functionality.
I have implemented moving objects in the main design across the site, but they are intentionally styled not to catch attention. On this page there's a little more movement though, all in good fun.
I prefer to watch a video if/when I want movement on screens, but some light object-transformations cannot hurt all that much, me thinks.
In my book the trick is to avoid overdoing it with excessive object movements at too high a speed. Everything that
moves can become distractions from more important matters on a page.
Another point is to make the movement serve a purpose. Not necessarily a serious one, but at least one that
fit the main
subjects on a page.
The movement should also ideally fit the object, like the rocking wheelchair symbol on top that emulates a rockingchair with the center of movement offset at the bottom. Same with the check-mark carrying figure in the headline just above here, which should have its feet solidly planted on the page even if it shows some unsteadiness.
I tailor the various parameters for each moving object as a local style-set in the pagehead, as they are normally used
only once in their exact form – for one object on one page. The
@keyframes definition the continuous movement
relies on has its place in a regular stylesheet, as it will be used again and again.
playing it safe near the edge…
In most new browsers we can “negotiate” via @support,
before serving them potentially problematic
CSS combos and hope all goes well.
One example is the almost white headlines I use, which won't be very visible on the almost white background without the dark
text-shadows I've given them. So, all headlines are initially styled a very visible dark blue, and then
text-shadow is checked in the browser before changing headlines to almost white.
Now, IE10 and IE11 support
text-shadow but not
@support, so no use negotiating about anything
with those. I chose to hack in separate stylesheets for these two IE versions, so I could provide them with white
headlines and some other “goodies” older IE versions cannot make any use of. Hacking old IE is no big deal.
Other browsers of any age will have to take what they get depending on their level of support for
@support, so not all
will get the full headline styling even if they support
text-shadow. Headlines will be clearly visible in all browsers though,
and that's the main thing.
NOTE that a positive
@support response does not always mean complete and flawless
support. Some browsers do lie…
we have the freedom…
… but I think we can agree that not everything we can come up with in web design and site population makes equal sense everywhere. Moderation rarely ever hurts our designs or visitors' experience.
Pays to keep in mind that “what we see is not what everyone gets”, and try to make sure the structure behind our visual creations is up to the task also when it has to deliver content and services on its own.
The world wide web is an interesting playground, where we all can express ourselves more or less as we please. Hope it will stay that way.
28.sep.2016 - minor revision.
29.sep.2016 - turned the original page into a BUG page. THIS is a revised page without the bug-trigger.
29.sep.2016 - minor revision.
last rev: 29.sep.2016