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 IDs 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 georg; sign

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

same old design

I like my present design a lot, so whatever markup is used the design will stay the same. No reason to change a good thing, is there?

Trends in web design don't affect my views on what my site should look like and how it should work. Trends come and go, and if I should redesign all the time to follow them, my site would lose its identity, and I would run out of time better spent at studying serious web design matters.

Keeping a web design as is through times of shifting trends and improvements in design techniques and tools, is actually harder than it sounds. Every time I feel the urge to overhaul my design, I have to focus on something else for a while.

Of course I cannot let the chance pass to style in a few minor markup‐dependent deviations, but they are introduced after I have assured myself of the stability of my design across various markup templates.

mainly valid markup

No “valid anything” badges on display around here, as I don't have time to check on their continued validity. I do check validity of markup when in doubt about causes for failures in a browser, but not otherwise.

To me “valid” means that some code is “technically correct”. It does not tell if the code is functional and/or semantic in its setting, or just crap. Consequently there is no point in flagging validity‐status.

I may include a short “validity” note in single documents if I think it really matters to the target audience. Otherwise it is a non‐issue.

Quality at all levels is what matters. As I set the standards my work has to live up to, I also decide if any of it meets same standards. So far not much has passed with top grades, but most of it is found acceptable for release.

HTMLTidy is watching my back when it comes to markup errors and typos. This application is good at cleaning up XHTML markup, and is also coming around quite well for HTML5 markup.

multi‐design process

Totally separate designs for screens above and below 642 in width. No styles shared across that break-point.

This means almost total freedom in designing for small screens versus larger screens, versus other media, but also a bit more work for me if/when I make major design changes across the board.