mixed markup on site…
…but there's a system to the apparent madness
As mentioned a couple of times in a previous article, documents are being served on at least three types of markup on my site. Not that it should matter to the average visitor, as look/feel should be more or less the same no matter what markup I serve them on.
There are of course weighty reasons behind my decision to forge ahead in
accordance with whatever HTML
standard (or non‐standard)
I choose at the moment, instead of porting all content onto one platform.
main reasons are as follows…
- As web developer I like to test how things work in minute details, and isolated test cases can only reveal so much. In a real environment like this on the other hand, all differences between standards, and potential problems related to using one or the other, will show up.
- There is more to web design than “look/feel”, and varying / improving standards and browser support can, and should, be utilized to enhance overall user experience. Working across standards and browser versions, reveals lots about how much enhancement we can successfully get through to the other end.
- Same stylesheets are behind all markup variants, which means I can test
out “
CSS
forking” across markup standard. This includes “minor” details like specificity, and how to solve selector‐chain clashes and conflicts when they occur.
markup types in regular use…
- XHTML 1.0 Strict (served as
HTML
). - HTML 5.n, a mix with mainly
XHTML
markup. -
HTML 5.n, with
HTML5
markup.
All valid markup AFAIK, except when I in special cases decide that 100% validity can be ignored for the sake of testing.
HTML5
markup contains a few more ID
s
than are strictly needed. These simplify styling for slightly older browser
versions.
less regularly I also work with…
- XHTML 1.0 Transitional (served as
HTML
). - Quirks Mode = no
DOCTYPE
– with standard and/or non‐standard markup.
Some “irregular” pages are found amongst the regular pages, while others are kept in back‐spaces on site. Depends on what, and who, they are launched for.
professional troubleshooter
Yes, that's me, and I can in most cases best figure out what potential problems are all about by pushing whatever the object is to near destruction, or beyond. That approach most definitely also work for web designs.
On my own site the worst case scenario is that I break my own design in the process, which is what I actually try to do anyway – all the time – even when there are no real problems with it.
Designing web sites is a bit like “building castles in the air”, with the obvious difference that people can actually see our attempts – also when they break.
Oh, well … show me a web design that survives all conditions it gets exposed to at the user‐end, and I will show you how little it really takes to break it – within the range of normal user‐options of course.
I may not be interested in fixing flaws in my own work before having studied everything about them in depth. But, being the first to know when some of ones own work doesn't hold up, is good when you, like me, call yourself a web designer.
sincerely
Hageland 07.nov.2013
16.feb.2014 - adding HTML5 "marking".
24.sep.2016 - updated "SSR break-point" in side-notes.
29.aug.2023 - updated "SSR break-point" in side-notes.
last rev: 29.aug.2023