For 'full' benefit, HTML (v5, these days, specifically seems to be the job market's request for skills in) must be combined with CSS (v3) and
some form of actual programming behind it, whether that be javascript or similar in the page, embedded 'programmed' objects (with some of the new HTML5 features superseding things like flash objects), or (as I tend to do) program the back-end engine to dynamically present a differently laid out 'static' page. (That's one of my major Perl uses. I basically write a CMS, or adapt and add to a previous one that I have used. Relies on the server doing a lot more effort, but it generally works for me.) Anyway, I think this complexity might well also be a valid "putting off" factor. Although laying out static pages (with any CSS being inline, at first, maybe later farmed out to a central definition .css file) is probably good practice.
I get around "browser interpretation" deficiencies by keeping the formatting simple, not having pages that require 'pixel perfect' placement to get certain effects and tend to test on
some of the different browsers I have available to me to see what happens to pages if reducing the height/width of the window to much shorter/narrower than might be reasonable, plus seeing what happens if I use different zoom levels (50% or 200%, say) to see how
horribly I can break it. If it doesn't survive without some gross reshuffling occurring then I'm not using that layout. I
could add javascript or other code to cater for such things, but it always seems like a bit of a cheat, and probably an indicator that I'm trying to be too complex. Anyway, this is yet
another reason for disillusionment, if one's expecting a totally consistent output under all circumstances and realising not all browsers (thank goodness!) support the <BLINK> tag...
(I've had serious arguments with someone who designed a web-page by laying out a single
image of their entire page, and setting a clickable map on top of it to do the job of the bits of the image that would normally have been represented by text and <A>-tags. And I never even got around to arguing about
accessibility issues. Another version was done in a WYSIWYG editor that set absolute coordinates for various <SPAN>s and <DIV>s, but internally defined them in such a higgeldy-piggledy pattern that "tabbing" between links on the page just jumped all round the page... I tend to think that (unless you're deliberately trying to be obtuse, with your source markup) you should have a nicely ordered and indented and otherwise white-spaced page source that is almost as easy to navigate (by the HTML-aware end-user) as the page itself.)