Progressive enhancement -- design from the inside out.

kk5st Prominent Member

Messages:: 3,497

Likes Received:: 376

Best Answers:: 29

Trophy Points:: 335

#21

Unless I went cross-eyed, I think you missed opening a paragraph, here:


<p>
This page is being built to show how to create a simple page layout using progressive enhancement.
</p>
Phasellus id euismod lectus, non tristique dolor. Aliquam maximus lectus vitae nunc fringilla, sit amet blandit dui commodo. Suspendisse potenti. Suspendisse vitae dictum nibh, vel egestas sem. Sed aliquam sapien a odio sodales ornare. Vivamus ultricies hendrerit quam, vitae pretium mauris faucibus id. Phasellus tristique eros sed arcu consequat, eget interdum erat porttitor. Nulla posuere sit amet nibh sed aliquet. Proin eleifend egestas augue vitae efficitur. Suspendisse in tristique dolor, at ornare libero. Nulla ac justo id libero lacinia semper. Nunc semper eget eros non porta. Maecenas aliquet risus ac nibh gravida dictum.
</p><p>

Code (markup):

//Edit: I'm not a fan of your style of formatting, but having a sane format for source code makes syntax errors pop out. That's a Good Thing. ~g

cheers,

gary

Last edited: Jul 18, 2015

kk5st, Jul 18, 2015 IP

deathshadow Acclaimed Member

Messages:: 9,732

Likes Received:: 1,998

Best Answers:: 253

Trophy Points:: 515

#22

Stage 3 -- Layout

This is the completed "layout" stage:
http://www.cutcodedown.com/progressive/stage3_layout/template.html

In the style at this point I don't go nuts with colours, corners or any of that. I use simple greyscale and defaults to make it so I can see my various layout elements, and that's about it. We want to get the layout working BEFORE we dive for the presentational graphics, otherwise how can we even know what the presentational graphics need to do?!? That's a detail the PSD jockeys often forget when they make fixed height background images that are invariably broken the moment you want to add text that doesn't fit their magical perfect height. That's why so many of the very pretty but ultimately useless "off the shelf templates" are broken.

I'm going to breakdown the HTML and CSS separately as trying to flip back and forth between them can drive you nuts if you aren't properly set up for it. I HIGHLY suggest the use of an editor (like Flo's notepad2 or Crimson Editor) that allows you to have multiple separate windows open side-by-side when writing your HTML and CSS so you can work with both files at once.

For now though, follow along with this text source of the markup:

http://www.cutcodedown.com/progressive/stage3_layout/template.txt

You'll notice I put the DOCTYPE, HTML, HEAD and charset META all on the same line. Further into the document you'll see I do the same with </head><body> and </body></html> -- I don't do this to save space so much as it is a reminder that NOTHING should go between those tags, and that it's a REALLY good idea to get the character set declaration as soon as possible so that IF the http header is missing, you can start using extended characters without forcing a reflow or having them misinterpreted/skipped.

Far too often you'll see people blindly paste stuff between </head> and <body> or before the doctype, this at least TRIES to reduce the odds of that.

Also pay attention to my formatting style and comments. If you use MEANINGFUL VERBOSE classes and ID's, with semantic markup, you shouldn't have to use comments like " since that's what <div id="content"> means. It IS however handy with </div> to know what's being closed, but you don't need to say "end", that's what </div> MEANS. Instead I put what's being closed in there using what the CSS notation for that element would be. I put all closing comments BEFORE the closing tag for a reason -- comments between sibling level elements can cause rendering bugs in older versions of IE and every other blasted build of FF if any of those elements recieve positioning, and sometimes margin collapse and other events can trigger these bugs. The worst of which are called "disappearing content" and "double render" -- I've seen people throw endless hacks at thier CSS to try and prevent/workaround these issues, when all that really needed to be done was delete pointless comments and move the useful comments placement.

Yes, COMMENTS, those things browsers are SUPPOSED to ignore... can trip rendering bugs as they ARE treated as DOM elements. Did we mention it's a IE thing?

At this point we need to add the viewport META to tell browsers we know what the hell we are doing. The values I set, width, height and initial-scale are the only ones you should really be playing with. Trying to set a maximum-scale, minimum-scale or worse, disabiling user-scaleable qualifies as some of the dumbest garbage you can do! That's disabling the users ability to pan and zoom!!! You might as well put giant text at the top of the screen that says "**** YOU!" as the welcome to visitors at that point. The three I use are the only three that 99.99% of responsive layouts have ANY business setting!

We also need to LINK in the external stylesheet. Again if you are using the STYLE tag, you're doing it wrong, and in all but the smallest of corner cases the same goes for using STYLE as an attribute. That crap has NO business in the markup since your magical screen appearance may not be your ONLY appearance! It also means if you put it in the markup it's not cached across pages or revisits, while CSS is. That LINK should have media targets. They JUST started with the HTML 5 validator of throwing an error if you include "projection" or "tv" despite many devices still in circulation needing those... but it's not like HTML 5's validator means jack ****. My advice, use them and ignore that, it's not like media targets have any damned business being part of the markup specification anyways! Seriously, do the ****tards working on HTML 5 even know what HTML is for? My bad, that's like asking if they ever get ot the cloud district!

At this point we have to decide what type of "outer layout" we're going with. There are really only two types -- "single wrapper" and "double-wrapped sections". Single wrapper would be a page where everything is in a single width-constrained box -- the background of the subsections don't go to the screen width. Double wrapped lets each subsection like the header, footer and content go have their backgrounds screen width, but has the semi-fluid layout inside each.

I'm going with the latter thanks to it's slightly higher complexity. Sadly it doubles the number of outer-div since you need one for style and one for width, but done properly it's still a fraction the code bloat you get out of mouth-breathing idiocy like bootcrap.

So the top area I call #top -- duh. Using ID's for major sections can be handy later on if you are going to add links like <a href="#top">Back To Top</a> -- it's just a good practice to get into. The inner DIV get called .widthWrapper; making it clear what it's for without actually saying WHAT width is being set.

Inside #top the only major markup change is moving the hypen inside SMALL and giving it a SPAN, this is a hook to let us remove the hyphen should our styling no longer need it. This SPAN could ALSO be leveraged for gilder-levin image replacement should we want a logo image instead of the text.

#callToActionBar also double-wraps. Since we have an outer div only one section inside it "needs" a DIV, and this lets us target the social media without throwing classes at the code. Normally at this point I'd be adding the actual social media links or scripts, but I'm omitting them for simplicity sake.

.columnWrapper is also a double-wrapper that we'll be using for a few different things. Contaning floats, as a flex container to force the "min-height" aka "sticky footer" type layout, etc, etc...

.contentWrapper and #content are there to allow for a "content first" multi-column layout that's easy to strip the columns off of WITHOUT resorting to flex-box. Flex inside flex is still flaky cross browser, though it will be REALLY nice when we can deploy that approach with impunity. For now this method is proven and works all the way back to IE 5.5, so we'll stick with it.

All the various .contentBox are there for styling of the various subsections of content in sidebars and the content column in a uniform manner.

#recentBlogEntries, the first of our .contentBox remains mostly unchanged in terms of content. It's broken into various .subSection, and the H3 get some span to allow us to format that text easily. The nested span can be used to remove the hyphen, while the outer span can be used to swap the date or title if desired. As dates are usually a fairly uniform size, I prefer to target that instead of the title which could be any size. Again by leveraging the parent #recentBlogEntries and using semantic tags like H3, with proper nesting orders we can skip several classes most people would be throwing in there for no good reason.

After we close out the content area we have sibling to .contentWrapper our #extras subsection. I further divide #extras into a DIV.firstSection and DIV.secondSection so that we can either treat #extras as a single column, or split it into two columns. Each .contentBox gets a div as the presentational hook and a unique ID for direct targeting. I put an empty italic tag to show a "skyscraper" advert sized box, but apart from that the actual semantic markup remains unchanged despite the wrappers added to it.

Closing out #extras and the .columnWrapper, we just have the footer. It retains that HR to be clear it's NOT part of <h2>Advertisement</h2>, and really there's not enough of a complete thought there to warrant the use of paragraph tags or even any extra semantic tags.

... So that's the HTML, on to the CSS; follow along with:

http://www.cutcodedown.com/progressive/stage3_layout/screen.css

When I build my first screen layout I like to start with the lowest common denominator. A LOT of people think that's mobile because "ooh, tiny!" -- but we can target small screen devices with media queries; or at least any that we actually care about. The big concern is devices that LACK media queries, which is why my initial layout is typically a mid-screen size friendly non-media query layout. I make it semi-fluid for IE7/newer, and shove a fixed width at IE6/earlier. (you'll see a comment about the last of those in the code).

I always start out with a reset. Resets exist because the HTML specification does NOT say what the default appearance of any tag should be, NOR SHOULD IT. The ENTIRE reason HTML exists is to say what things are, or would be in a professionally written document, so that the user-agent (all browsers are user-agents, but not all user-agents are browsers) can best determine how to show that content! Like anything else where it's not explicitly said in the spec, the browser makers went and each did their own thing in terms of margins, paddings and borders. A reset adjusts for that without having to say it each and every blasted time you want to use an element.

There are smaller resets like the so called 'universal' one of "* { margin:0; padding:0; }" but that can wreak havoc with the sizes of form elements between IE, FF and "everyone else". There are larger resets like Eric Meyers "reset reloaded", but that fat bloated mess borders on being a framework unto itself. It wastes time changing values that don't need to be rest, initializes values you are highly likely to change anyways, and is just too blasted big. Most of the time you encounter people saying "don't use resets" it's because all they can think of is massive bloated ones like that.

The one I use was developed by Dan Schulz shortly before he passed away, and at a quarter K isn't so big that it has any meaningful impact on load time. It resets JUST what's inconsistent across browser engines and removes most all the headaches common to styling a page. It's a nice safe middle-ground.

HR -- I hide all the HR since they are there for semantics and "non-screen user agents", NOT for "drawing a line across the screen". With our screen media layout we'll have plenty of other ways to convey that meaning.

-text-size-adjust -- a handful of older mobile browsers with small displays will STILL try to screw with the default font size ignoring the viewport META. Thankfully it's only small display units that take vendor prefixes, so we just hit the two that need it. Sadly if you send it to desktop Safari, the -webkit-text-size-adjust will break zooming (see my ranting and raving up above) so I put them in a media query. It's VERY unlikely that desktop safari would ever be on a 480px wide display.

html, body -- I set the width AND height of these to 100%... Height is so that we can use BODY as a flexbox container for the min-height/sticky footer. The Width deals with that IE10 and 11 can be a real jackass about flex, shrinking BODY to the max-width of the .widthWrapper DIV for christmas only knows what reason. (Oh wait, it's IE, like it needs a reason to do something stupid!)

Remember that you cannot set percentage height on an element where it's parent doesn't have a height; it will be ignored. The only exception being the top-most element which is USUALLY HTML (some old browsers use body). This is why we have to send this to both BODY and HTML, so that in 'normal' browsers BODY can get it from HTML, and in crappy browsers BODY just works.

body -- First I set it up as my flexbox container. Flex allows our content to stretch to fill the parent. If we set up .columnWrapper as the element allowed to stretch, the footer will be pushed to the bottom. I set min-width on body so the whole layout is nabbed in one fell swoop. I like to set the font used across most of the document on body. Experience has taught me that for MOST (but not all) sans fonts 85% is the ideal size.

If you change the fonts-size, you should ALWAYS change the line-height. You CANNOT trust it to inherit properly, particularly if declaring % or EM font sizes, MORE so once you start testing on systems with that different default font size. There is a LIE being perpetrated/parroted/defended on another forums with "point" in it's name that if you omit the metric and just say "line-height:1.5;" that it will inherit properly -- don't believe it. Fails miserably across multiple browser and default font size combinations.

... and since by the time you say "font-size:85%; line-height:150%;" you're within spitting distance of using the entire condesnsed font declaration, I just go ahead and use the full condensed declaration EVERY time I change the font-size. (with one minor corner-case IE hack exception that won't come up in this example)

For flow text I find that taller line-heights aid in legibility. The 110-130% that HTML suggests is fine for "times new roman" at 16px if you need to cram a bunch of text into a small display, but it isn't the best. There's a reason back when people had to use things called "typewriters" to write papers for school the teacher told us to double-space, and it wasn't JUST to have room for them to cram comments in between lines. (though that is a handy side-effect, particularly when editing). Really you have to base this on the font being used; just look at this picture I made years ago:

http://www.cutcodedown.com/images/faceCompare.png

All the fonts are declared in the same size of 1EM / 100%... top is at 96dpi/16px default, bottom is at 120dpi/20px default. "same size" my backside. Arial is significantly larger at the same declared "size" than TNR, "DejaVu Serif" and "courier new" are outright honking HUGE. Something people designing the front end need to learn and test for.

I set the #EEE background color so that I can make the content areas white and see them. This is more of a layout aid than planned style. Again don't fret about pretty colours and backgrounds at this point, make the layout work FIRST... that way you can design your graphics to the layout instead of the other way around.

#top,
#callToActionBar,
#footer -- Technically these elements should default to this flex-shrink behavior, but IE is once again painfully stupid. You omit this, and the footer won't go to the bottom of the page if the content is too short to push it there.

.widthWrapper -- first I set up float and margin wrapping behavior since we'll want to contain such things as much as possible. The max-width prevents long lines of flow text from getting hard to read, the padding makes it 'pretty' when smaller than the max-width so some background shows through, and the auto-margin centers it.

Whenever possible I use EM for my margins, paddings, etc. Based on the size of the font multiple of it most always look good regardless of the actual font-size. This takes a BIT of work to deal with as if you scale the font, you need to scale your values. Theoretically you could use REM instead of EM, but browser support for that is a bit wonky.

* html .widthWrapper -- see the comment. This is for legacy IE, you could probably remove it if you wanted and tell IE6/earlier users to go plow themselves; but it's so tiny and simple there's no harm in at least TRYING to make the page useful for grandma on her Win98 box even if it doesn't get all the bells and whistles. Again, graceful degradation -- it doesn't have to work perfect, it just has to be usable.

Really once you take the attitude, "is it usable" instead of "does it perfectly match in every old browser like it does the modern ones" life becomes SO much easier.

h1 -- floated so the menu can go next to it, nice big font size. The uneven padding is there to deal with that many sans-serif fonts do NOT put the distance between caps-line and base-line in the proper spots -- some don't even make their caps reach the declared caps-line. (which is just herpafreakingderp). Worse there's also a bit of optical illusion with the small text below the big text that has to be accounted for. I also made it all caps.

h1 small -- making it block pushes it to it's own line, I adjusted the font-size until it was the same width as the parent text, and got rid of the force to upper-case.

h1 small span -- get rid of the hyphen, we don't need it for screen layout.

#mainMenu -- kill the bullets, float it ot the opposite side, align the text to that side since we'll be using inline and inline-block inside it (otherwise there would be a extra "space width" gap on the right), and pad the top to push it even with the heading. I set a max-width to force it to two rows of three columns.

#mainMenu li -- It's FAR easier to just set these to inline than it is to play with float or that legacy IE can't make block-level tags display as inline-block. This avoids al sorts of bugs like IE8's "staircase effect" and on the whole just makes life simpler. WHEN POSSIBLE on a menu, style the anchors, NOT the LI.

#mainMenu a -- inline-block makes it so top and bottom padding is obeyed on these. I fix the width to make them look nice but do so elastic, so as to fit the differnet font size if any. A "space width" is typically 0.3 to 0.4em depending on the font, and we end up with a space between inline and inline-block siblings. The 0.2em margin ends up making roughly 0.5em so the space between these elements to the left and below looks mostly the same without playing any "games" to try and remove that whitespace behavior. I only really coloured these so we can clearly see them in the layout.

#callToActionBar -- top and bottom padding, background so we can see it.

#callToactionBar div div -- float the social media part, and margin it so that it won't run flat against the "news" text. YAWN.

h2 -- at 125% font enlargement 0.8em == 1 REM. Using sizes like 125%, 150% and 200% make the EM math so simple you don't really 'need' to resort to REM. (Which WILL someday be handy, but we're not there yet)

p -- rather than try and use margins I pad the bottom. Means no margin collapse headaches and is just 'simpler' to work with. You want space above it, pad the element before it.

.columnWrapper -- I clear just to be sure since #top and #callToActionBar have floats -- the .widthWrappers inside them SHOULD be float containing, but IE can still drop the ball on that once flex is in the mix. Setting flex to "1 0 auto" means that "1" this element should grow to fit as much space as possible, "0" it should NOT shrink to fit the screen forcing a scrollbar, and "auto" it should be dynamic instead of a relational or fixed height. By making this element grow, the footer will be at the bottom of the screen if the content is too short to push it there, or off the bottom of the screen if the content is tall enough to force scrolling.

.contentWrapper -- the magic column layout begins. If we float this left but force the width to 100%, there is 0px free on the left for a float to fit into. REMEMBER THIS for when we get to #extras below!

#content -- The padding is there to push the content subsections away from the sidebar and stuff above it. The margin is set to the width of our sidebar #extra to make room for it to be displayed OVER. We could just say margin-right:19em and lose the side padding, but I find it easier to not have to do the math separate. It's also handy to keep them separate should you find yourself having to mix metrics like pixels and EM's at the same time.

#extras, #extras.firstSection, #extras.sectionSection -- I make these relative positioned as throughout the different screen layoutS we want them to depth sort over .contentWrapper and #content, and we may end up sliding them around as well.

#extras -- floated left I set the width to 18em and a negative margin equal to that width. Negative margins are fascinating in that they change the size of the container in "flow" -- aka how big other elements THINK it is, but does not change the size at which it "renders", aka how it's drawn. By using a negative left margin equal to it's width it becomes 0px wide in 'flow', letting it fit into that zero-width gap next to .contentWrapper! Boom, the whole section rides up into that gap rendering OVER that side margin on #content.

Using this technique we could do three column, four column, no column layouts.

It DOES mean we need to declare a fixed or elastic width instead of a percentage one, but honestly trying to do things like "25% columns" on a website sidebar is most always a disaster that breaks somewhere. It's far easier and reliable to use an elastic sidebar with a fully fluid content column.

.contentBox -- padding, bottom margin to space them apart, background so we can see them; nothing to write home about.

#recentBlogEntries .subSection -- pad them, add a border at the top to divide them. Simple.

#recentBlogEntries h3 -- I like to make the screen target version put the date on the right, and the text on the left with a gap between them, with the text able to flow below the date should wrapping kick in. That just means float the span with the time in it, so we need to add float wrapping behavior. Bigger font, pad the bottom, pretty simple.

#recentBlogEntries h3 span -- float it right, pad it so the time won't sit flush against the title. Simple.

#recentBlogEntries h3 span span -- kill the hyphen, we don't need it for screen media.

#featuredArticles ul -- kill bullets, yawn.

#featuredArticles li -- pad them apart. 1EM felt like too much, 0.5 like too little. 0.75 was just right.

#featuredArticles a -- setting it to block increases the target area that hover and clicking can hit. Ever notice how sometimes anchors only work if you are over the rendered text or a specific line, but not the whole element? This fixes that. I also kill off the underscores.

#featuredArticles a strong -- force these to their own line for our screen layout.

#advertisement h2 -- since this is NOT real content of the page I don't like making it look like a major heading, so I drop it in size to normal text, make it italic, and grey it out slightly.

#advertisement i -- our dummy advert box. 160x600 is a fairly common "skyscraper" size. Background-color so we can see it.

#footer -- padding, alignment, YAWN.

... and that gives us a two column intermediate desktop layout that should work all the way back to IE 6. (and with two or three extra lines could be made to work all the way back to IE 5.x if desired). NO significant extra effort.

It's semi-fluid and elastic, leaving just one more need: RESPONSIVE.

Responsive layout just means using media queries to change out things in the layout to make it fit different displays. It's not "hard", it's not rocket science, and it sure as shine-ola doesn't need some idiotic massive framework much less arbitrary "grid" asshattery to pull it off!

In keeping with our theme of working "from the inside out" I'm going to make a query that on large displays turns our two column layout into three... then have a query that turns our two columns into one column at the top with to columns below it, and then finally at the smallest size go to a single column.

These media query widths were determined by resizing the window and figuring out what worked according to the needs of the CONTENT, as opposed to trying to shoe-horn things into some arbitrary grid nonsense.

@media (min-width:64em) -- if the display is bigger than 64em wide, up the maximum width to make more room, then pad/margin the opposite side of #content to make room for another column on that side. We strip the float/column behavior off #extras and instead add that behavior to .firstSection and .secondSection.

.firstSection gets margin-right which pushes it right, then slid left 100% putting it on that side of #content. .secondSection just gets the same left negative margin behavior as we had on #extras as our two column design.

REALLY simple.

@media (max-width:46em) -- if the display is smaller than this size, we first let the body go down to 192px as the minumum. That min-width on BODY was for non-media query capable browsers, since we KNOW we can run media queries at this point, we can remove that limitation.

The content area has it's margins and side padding stripped off removing the sidebar space. Likewise we strip the column behaivor off #extras, but pad it's right side to make room for .secondSection to be a sidebar.

Floating .firstSection at 100% width allows .firstSection to be fluid width, whilst we can put that same negative margin float behavior onto .secondSection to make it a narrow elastic column on the right.

@media (max-width:40em) -- at this point the menu alongside the h1 breaks, so we want to strip the float behaviors off these and just center them. Sicne displays this small are pretty much guaranteed to be touch devices I enlarge the menu anchor sizes to make them "finger-sized" (something google actually checks for now!). I also up the max-width to a ridiculous amount on #mainMenu so they can display as a single line. Likewise the float behavior gets removed from #callToActionBar and we kill the padding on #content and #extras. In all side paddings are removed or reduced to make better use of the rapidly dwindling available screen space, and once again we strip off ALL columnar behaviors from #extras. I add a bottom border to the .contentBox so we can clearly see divisions between them, then pull the top border (if any) off #footer so there's no conflict there.

@media (max-width:34em) -- way down here at this tiny size I put the max-width back on #mainMenu to force it to two even rows as having just the last one or two menu items below four or five items just looked like ass. I also kill the line-break in the footer since how it was wrapping wasn't entire attractive either.

@media (max-width:20em) -- our final query just adjust the size of the H1 text down smaller so that it actually fits the screen.

... and that's the layout step. Have to stuff my face first, but then I'll give it a "paintover" for stage 4 -- aka, "Make it pretty".

deathshadow, Jul 18, 2015 IP

deathshadow Acclaimed Member

Messages:: 9,732

Likes Received:: 1,998

Best Answers:: 253

Trophy Points:: 515

#23

kk5st said: ↑

Unless I went cross-eyed, I think you missed opening a paragraph, here:
Click to expand...

Yeah, I caught that during layout. I've updated the files to not have that error.

kk5st said: ↑

I'm not a fan of your style of formatting, but having a sane format for source code makes syntax errors pop out. That's a Good Thing. ~g
Click to expand...

... I wasn't wild about it at first either (Dan forced it on me) but it quickly became apparent the advantages at, well... finding things like syntax errors. They still slip through which is why validation is a good idea, even if there are some things you're going to dismiss (like them tossing an error now about "projection,tv"), it will point out glaring errors like that one.

Sometimes it feels wasteful in bytes, or taking up too many separate lines, but it can make it easier to find errors and prevent you from making errors in the first place... so the advantages typically outweigh the negatives.

Ok, time to make a pizza from scratch, then I'll make it purty for stage 4.

deathshadow, Jul 18, 2015 IP

Matthew Sayle Prominent Member

Messages:: 3,325

Likes Received:: 464

Best Answers:: 1

Trophy Points:: 385

#24

deathshadow said: ↑

Ok, time to make a pizza from scratch, then I'll make it purty for stage 4.
Click to expand...

.anchovies {
display:none;
}

Matthew Sayle, Jul 18, 2015 IP

deathshadow likes this.

deathshadow Acclaimed Member

Messages:: 9,732

Likes Received:: 1,998

Best Answers:: 253

Trophy Points:: 515

#25

Ok, pizza in the oven (dough finally finished rising)... and this part should take less time than that takes to cook.

Stage 4, style

Now that we have a working layout we can worry about things like colours, backgrounds, borders, shadows, etc, etc... Having the content, semantics and layout in place means we know how big things are, what range of sizes they might take, and a whole host of other things that dicking around in pixel measurements in some goofy paint program like Photoshop is relatively incapable of.

In the markup, there's only a handful of changes. I added a LINK to the favicon, and one SPAN inside the H1 so that I could change the color of the word "CODE".

The end result being this:

http://www.cutcodedown.com/progressive/stage4_style/template.html

The CSS:
http://www.cutcodedown.com/progressive/stage3_layout/screen.css

Does't make too many major changes either nor should there be a whole lot I need to explain. The background color was changed to the header and footer area color so that when min-height flex fails in older browsers (IE9/earlier) the shrunken format at least stretches the footer color. 99% of it is just the application of rounded corners, background-colors, a few borders between elements, and anchor styling. Simple stuff that shouldn't need a complete breakdown.

I do use a lot of box-shadow where most people would use gradients. It's just faster, easier and more reliable. I'm also REALLY digging that the only browser we need vendor prefixes for at this point is Safari -- the laugh being that Safari really is aging like milk since Google forked off "blink" and took most if not all the talent with them.

I went with a simple set of blues akin to many stock templates for existing CMS. All the colour contrasts meet WCAG 2.0 AAA minimums. It's clean, it's simple, and it's fully accessible.

The only major thing I think needs explanation on this stage is the addition of the logo next to the text. As presentation I applied it by simply padding one side of the h1 and adding it as a background image. When the screen gets to that narrow width where there's no room for it, I just remove the background image and that padding in the media query.

But really that's the whole process apart from the optional stage 5 "enhancing the page with scripting".

It's not rocket science, it's not hard, and the result is compact, easy to edit, easy to maintain, load quickly, and best of all be highly unlikely to alienate any potential users since it gracefully degrades images off, CSS off, visuals off, and even back to simple text-only browsers like lynx.

Which is pretty much why Tim Berners-Lee created HTML in the first blasted place!

There's a few page anaylsis stuff I'll be tossing into a subdirectory there as well after dinner, like a screencap of the page load time, document outline, etc, etc... and some other things I just feel should be added to this thread.

deathshadow, Jul 18, 2015 IP

deathshadow Acclaimed Member

Messages:: 9,732

Likes Received:: 1,998

Best Answers:: 253

Trophy Points:: 515

#26

qwikad.com said: ↑

@malky66 Don't be an idiot. I put him in my ignore list loooooong before I said anything negative about his posts. I put him in my ignore list maybe 6 mo ago, then I un-ignored him, then I put him back there again two mo ago or so (got tired of stumbling across his verbal diarrhea)..
Click to expand...

Then why, much less HOW the **** are you even responding to this?!? HERPA! FREAKING! DERP!

Though all this talk about the "ignore" feature made me wonder if I've ever bothered using it -- since "OHS NOEZ, SOMESBODIES MIGTHZ DIZAGRES WIDS MYES" really isn't reason enough to ever use that... Usually I'd reserve that for spammers, and we have a REPORT button for that.

... to find that I did in fact use it... sometime on or before 2008... twice. Once for a user that seems to be banned, once for a user that's not logged on in 7 years, and in both cases neither has any posts anymore on these forums.

Kind of an interesting thing to look at.

deathshadow, Jul 18, 2015 IP

ketting00 Well-Known Member

Messages:: 772

Likes Received:: 27

Best Answers:: 3

Trophy Points:: 128

#27

deathshadow said: ↑

At this point we have to decide what type of "outer layout" we're going with. There are really only two types -- "single wrapper" and "double-wrapped sections". Single wrapper would be a page where everything is in a single width-constrained box -- the background of the subsections don't go to the screen width. Double wrapped lets each subsection like the header, footer and content go have their backgrounds screen width, but has the semi-fluid layout inside each.
Click to expand...

Now that I believe I see what I'm looking for. Maybe that's what makes me always wonder how your site can have a behavior the way it works. Correct me if I wrong, I'm going to dig deep into this.

Thanks for sharing.

deathshadow said: ↑

Kind of an interesting thing to look at.
Click to expand...

That's not a good idea.

ketting00, Jul 18, 2015 IP

kk5st Prominent Member

Messages:: 3,497

Likes Received:: 376

Best Answers:: 29

Trophy Points:: 335

#28

Matthew Sayle said: ↑

.anchovies {
display:none;
}
Click to expand...

Heathen!

kk5st, Jul 18, 2015 IP

PoPSiCLe Illustrious Member

Messages:: 4,623

Likes Received:: 725

Best Answers:: 152

Trophy Points:: 470

#29

There are a few things that does not belong on a pizza, among them are brown cheese, anchovies and pineapple. Personally I would like to add canned mushroom, sprouts, corn and blue cheese. And, lets just ban vegetarian pizza alltogether, please. If most of the toppings didn't have at least two legs and were slaughtered to be on the pizza, what's the point!

PoPSiCLe, Jul 18, 2015 IP

Matthew Sayle likes this.

deathshadow Acclaimed Member

Messages:: 9,732

Likes Received:: 1,998

Best Answers:: 253

Trophy Points:: 515

#30

So... how do folks feel about linguica, ham, garlic, red onion and red pepper? Whole milk real mozzarella (not that low moisture crap), real parmesan (not that faux-powder crap), provolone and extra sharp vermont cheddar?

Linguica is the ultimate pizza topping, followed closely by it's second cousin Andouille... and none of that watered down California faux linguica rubbish either! There are TWO acceptable brands, Gaspars and DeCosta -- in that order! Well, Amarals will do in a pinch... OF course like an idiot I bought old Neighborhood brand a few months ago just because it was cheap; as expected it was hot dogs with paprika just like how ALL their sausages are pathetic shadows of the real thing.

I swear west coast wussies know about as much about food as... well, there's a comparison I was gonna make but I just decided the wiser.

Oh and what is this rubbish of drowning slices in red pepper flake? If you have to add that to pizza, there's something WRONG with the pizza.

deathshadow, Jul 18, 2015 IP

deathshadow Acclaimed Member

Messages:: 9,732

Likes Received:: 1,998

Best Answers:: 253

Trophy Points:: 515

#31

PoPSiCLe said: ↑

@deathshadow[/USER] is an ass
Click to expand...

"I know I'm a prima donna. I admit it! What I can't stand about Monty is, he won't admit it!" -- General George S. Patton Jr.

Ah, good old George... Honestly what he said about the common man oft feels akin to my current take on web development.

"In view of the prevalent opinion in America that soldiers are, of all persons, the least capable of discussing military matters and that their years of special training is nil compared to the innate military knowledge of lawyers, doctors, and preachers; I am probably guilty of a great heresy in daring to discuss tanks from the viewpoint of a tank officer."

In that way, daring to talk about websites from the point of view of someone who codes HTML and CSS directly mated to an understanding of accessibility issues elicits the same response when I dare to talk about how to make a website; sure listen to the people who know nothing more than how to draw pretty pictures and slap together other people's work any-old-way instead.

"No good decision was ever made from a swivel chair!"

deathshadow, Jul 19, 2015 IP

Matthew Sayle Prominent Member

Messages:: 3,325

Likes Received:: 464

Best Answers:: 1

Trophy Points:: 385

#32

PoPSiCLe said: ↑

There are a few things that does not belong on a pizza, among them are brown cheese,
Click to expand...

I am from Saint Louis and we have a specialty cheese here called 'Provel'.

https://en.wikipedia.org/wiki/Provel_cheese

Some out-of-towners don't care for it, but most people from STL (including myself) think it's absolutely amazing and put it on EVERYTHING - especially pizza.

Matthew Sayle, Jul 19, 2015 IP

Matthew Sayle Prominent Member

Messages:: 3,325

Likes Received:: 464

Best Answers:: 1

Trophy Points:: 385

#33

deathshadow said: ↑

Oh and what is this rubbish of drowning slices in red pepper flake? If you have to add that to pizza, there's something WRONG with the pizza.
Click to expand...

I think the same thing about steaks.

If you need to add steak sauce, there is something wrong with the steak.

When they ask me at a restaurant, "do you need steak sauce?"

I always reply with, "I hope not."

Matthew Sayle, Jul 19, 2015 IP

Webinator Peon

Messages:: 13

Likes Received:: 0

Best Answers:: 0

Trophy Points:: 1

#34

Thanks Deathshadow for the priceless detailed example.
It took me a couple of hours to follow and understand your process and try to compare it with the process I knew already (getbootstrap.com).
I will save this thread along with all your files in my computer (actually I'm in doubt if print them all, plasticize and make a little envelope).
I'm happy and a bit confused, probably I will contact this guy (https://github.com/mdo) and I'll ask him some questions regarding his guide (https://github.com/mdo/code-guide/), for example about the use of "em" instead of "rem".
I mean your explanation and examples are so clear and simple, like if you say "The apple is a fruit" and then I say to myself "Hey..wait a second...he's right! Why I didn't think about that before!?!?".
So, thanks again and I hope for the optional stage 5 .

Webinator, Jul 19, 2015 IP

deathshadow Acclaimed Member

Messages:: 9,732

Likes Received:: 1,998

Best Answers:: 253

Trophy Points:: 515

#35

Webinator said: ↑

It took me a couple of hours to follow and understand your process and try to compare it with the process I knew already (getbootstrap.com).
Click to expand...

Uhg, bootcrap. Yeah, do yourself a favor and find a stick to scrape that off with. The ONLY thing you can learn from those asshat "frameworks" like bootcrap, YUI, blueprint, etc, etc. is how NOT to build a website! Developers are dumber for that bekaptah nonsense even existing, and I pity the shmucks DUMB ENOUGH to have been DELUDED into thinking any of them serve a legitimate purpose other than pissing all over a websites code and making you work HARDER, not smarter!

Like most framework asshattery I don't grasp how writing more CSS, that relies on more CSS in the form of the framework, that then often needs JS to do things you can do without scripting, to then write two or three times as much markup as needed is "easier" much less "better". It's like the fanboys of this crap seem to have repeated that it's "easier" so much and so often so many blasted places, it's become the equivalent of what Joseph Goebbels meant by "The big lie".

Which is why quite often the people who say things like "use bootstrap" or "use jquery" come across more as creepy cultists than legitimate developers.

Webinator said: ↑

probably I will contact this guy (https://github.com/mdo) and I'll ask him some questions regarding his guide (https://github.com/mdo/code-guide/)
Click to expand...

Interesting guide and there are some good points in there. Mostly though it's a style guide and as he says in the "golden rule" sections sidebar, choose one and enforce it in your code base -- doesn't have to be his, doesn't have to be mine, but at least develop or find one you like and STICK TO IT.

That said there's some stuff there I disagree with or would never do.

I was going to use the full URI's here, but once again the steaming pile of manure known as Xenforo with it's halfwit broken URL validation won't let me

For example under #html-syntax

I see he's one of the "two space" fanboys. I'm a hard tab fan as if you don't use spaces for tabs it's easier for most programmers to deal with as you can tell the EDITOR to set them to whatever size you prefer. Using spaces removes that choice. Some people like three space, some five. Hard tabs can be set to show however the programmer likes them -- and they take less space in the file. Even if using multi-space tabs I'd convert them to hard tabs at save-time.

He also uses the term "render" which makes me think browser rendering, not how the editor shows them... in which case it makes no sense. Browsers don't give a flying purple fish how few or how many whitespace characters you use. Tabs, spaces, carriage returns, line-feeds -- they are ALL reduced to a single space when rendering (unless you're in a PRE tag or set white-spacere. Saying "render" for that is something I'd not have done... nor would I be advising people to use spaces for tabs as to me that's just BS... but really this is an OLD debate going back to the divide between microcomputer vs. mainframe days... the laugh is sometime in the late 1990's the mainframe methodologies that had all but vanished thanks to the microcomputer revolution suddendly got a gust of wind to fill their sails, dragging us back to some of the worst of 1960's computer thinking.

But what do I know? I'm still not convinced this is a joke:
http://www.gnu.org/fun/jokes/unix-hoax.html

HTML itself also doesn't care about single or double quotes, but I agree that it would be BEST if people stuck to doubles. I see single quotes I automatically assume the code was vomited up by someone using PHP or ASP that don't know enough about the language they are using to be writing code in the first place.

#html-ie-compatibility-mode

Is some outright ignorant BULL. If you've written your HTML properly using post 1997 techniques, you should NOT need that... EVER. The only reason that META exists is to address websites with outdated code requiring LEGACY version support in newer versions of IE, meaning you did SOMETHING that is broken using modern methodology. If you have to use the "edge" declaration just to get your site to render properly, you've done something horrifyingly and terrifyingly WRONG!

The talk of includes:
#html-style-script

Is just poorly worded, but really it's talking about the TYPE attribute. This is something I still say should NOT be optional or rely on the default JUST because of legacy browser support AND for code clarity. At the same time that including TYPE on some LINK can in fact break the LINK (favicons for example) means you can't just hard-fast rule that.

The attribute order section:
#html-attribute-order

Is mostly a good idea too. I prefer my id before the classes since it's the TARGET, but as a style guide it's good to just be consistent... that said there are some attributes listed there I would NEVER use and don't think should even exist.

The "data-" attributes for example are idiotic nonsense. If it's ACUTALLY page data, why isn't it on the page as CDATA. If it's scripting only, what the *** is it doing in the markup. I say the same thing about things like the various "onevent" attributes like onmouseover or onclick, since good scripting should hook the content and the markup, NOT the other way around. It's just scripttard bull for the inept fools sleazing out the endless "JS for nothing" with zero concern for graceful degradation. I see no LEGITIMATE reason to ever use those attributes.

Same for "aria-" and "role" -- that's just content thief data scraper asshattery since there is NO values for ANY of those that ANY legitimate user agent should EVER have a need for.

#html-boolean-attributes

I agree it's time to kick XML formatting to the curb, but there's a REALLY funny little flub in the code sample. The next section being "reducing markup" makes it even more comedy since, well...
<option value="1" selected>1</option>
Code (markup):
It's a minor nitpcik. If the value of an OPTION tag is the same as it's content, you don't need to say value.
<option selected>1</option>
Code (markup):
Is functionally identical! It's the same as the nonsense you'll see the halfwits using turdpress vomit up of:
<a href="#" title="home">home</a>
Code (markup):
If the title is the same as the content, there is no legitimate reason to put a title on it. GENERALLY if you have to use the TITLE attribute, you're probably doing something wrong or there's something wrong with the content of the tag - the only real exceptions to that being tags like ABBR who's entire functionality is based on said attribute, or if you are building an accesskeys menu. (A concept now dead with the only browser that cared about accessibility, Opera, having gone and wet their own bed by slapping their logo onto Chrome any-old-way and giving a giant middle finger to it's own userbase!)

The "reducing markup" part:
#html-reducing-markup

I agree with wholeheartedly because people slap wrapping DIV and SPAN around things willy-nilly, quite often before they've even TRIED applying that style to the tags inside it. You add DIV and SPAN only when you can't do it with the existing tag. You see this with people doing <div id="menu"><ul> all the blasted time. While there ARE legitimate usage scenarios for that, generally speaking what most people use it for is just utter and complete code bloat.

His CSS syntax section:
#css-syntax

Though again the "two space" thing is rubbish, and I'm also not wild about spaces after the colon on the property. To me that's just pointless but as I've often found I'm NOT punctuation blind -- which is why things like the illegible acid trip of colour syntax highlighting is NOT something I would ever allow my editors to do.

One MAJOR thing I disagree with is the leading zero. USE IT. Omitting it is unclear, and inconsistent with many programming languages that will reject values if you don't declare it with a leading zero.

I've got the same reaction to the "lowercase hex" -- Hex values should NEVER be lowercase. Maybe that's the old-school 6502, Z80 and 8088 machine language programmer in me, but lower case hex just pisses me off as it makes me think it's sexigesimal (base 60) instead of hexadecimal (base 16). The upper case makes them stand out MORE and as to the "different shape" thing, sounds like he's just using a shitty font in his editors.

Of course, a year of having a nun thwack me with a ruler when writing code is part of what ingrained my formatting habits on things like tabs and case. ...and gave me this really creepy thing for women in habits. I say, I say, that's a joke son...

Under declaration order:
#css-declaration-order

I try to do pretty much the same thing. It makes it easier when thigns are grouped in that order to find stuff. It also helps to put visual after when you are doing visual SEPARATE from the layout -- the difference between stages 3 and 4. That "visuals last" pretty much happens automatically.

BUT -- I like to put the new CSS3 visuals and effects AFTER the normal visuals. Makes it easier to cut/paste to add the vendor prefixes and to see "what's modern" and "what pre CSS3 gets".

The "don't use @import"
#css-import

Is some of the BEST advice out there. The extra page requests thing is one of the things you'll see me constantly raging about. BUT... that said he's suggesting the idiotic mouth-breathing dumbass garbage like LESS and SASS, where if you "need" that type of garbage you're probably doing something wrong. Same goes for if you need "environments" to manage something as SIMPLE as "one or two CSS files per markup MEDIA target".

Media query placement:
#css-media-queries

I could not disagree with more as it's awkward as HELL and results in bloated code since you'll end up saying the same blasted queries over and over and over again. That's just stupid. I put them in order at the END of the stylesheet with the properties in the same order, that way I can see what I'm overriding for that query all-together instead of it being spread out all over the blasted place.

Usually as I design non-responsive desktop semi-fluid elastic FIRST, the media queries aren't big enough to take up more than a full screen-height of text each anyways.

Amongst some developers there seems to be a bit of "Oh noes, the selectors are all spread out" paranoia that I just don't understand. For me, putting them together is harder with things like media queries as then all your changes for that trigger are all over the blasted code... I think it's more of a personal preference and difference in workflow there... well, and difference in developer mentality and methodologies.

The indentation of prefixes:
#css-prefixed-properties

I don't see the need for, though it would explain the obsession with spaces over tabs. I prefer if I have values long enough to "need" that to simply put the values on their own lines tabbed in under their parent:
.selector {
	-webkit-box-shadow:
		0 1px 2px rgba(0,0,0,0.15);
	box-shadow:
		0 1px 2px rgba(0,0,0,0.15);
}
Code (markup):
Makes it easier when you have multiple values:
.selector {
	-webkit-box-shadow:
		0 -1px 2px rgba(255,255,255,0.15),
		0 1px 2px rgba(0,0,0,0.15);
	box-shadow:
		0 -1px 2px rgba(255,255,255,0.15),
		0 1px 2px rgba(0,0,0,0.15);
}
Code (markup):
... and when you edit one, it's easier to copy/paste to the others.

"single declarations":
#css-single-declarations

I rarely if ever would do. The reason being again, ease of copying values -- and consistency of code. The whole "sanity" thing over syntax errors on lines is just... what the devil is he even on about? More lines == more detail. PERIOD. That's some serious freaking herpaderp right there.

What he's saying about "shorthand notation"
#css-shorthand

Makes me want to pimp-slap whoever wrote that into orbit. More bloated confusing properties is NEVER the answer, and his "good" code example is a stunning example of developer ineptitude. Of course, I'd probably really annoy him since his "bad example" is a bit large IMHO since if I wrote that same thing, I'd end up with:
.element {
  margin:0 0 10px;
  background:red  url("image.jpg");
  border-radius:3px 3px 0 0;
}
Code (markup):
Writing more code is NEVER the answer. If you can't handle the condensed declarations, you probably have NO damned business writing CSS. Admittedly I say the same thing about the next two categories...

#css-nesting
#css-operators

Are about LESS, SASS and other such preprocesser bull. These are things I would never be using in the first place as I've NEVER seen websites built with them that were worth a flying purple fish from a coding perspective. If your CSS is so complex that you need either of those steaming piles of manure to manage it, you're doing something WRONG like using too much damned CSS, or ridiculously overthinking the solution to every problem.

But again, there's a reason I say the LARGEST CSS for an entire WEBSITE should be around 48k - whereas most of the halfwits out there vomiting up websites start out at 48k for one page that relies on some dumbass 100k "framework" garbage.

See how this fellow's guide seems to be 45k of markup to deliver 15k of plaintext... with breaking zoom on mobile, META I'd never put on a page in the first place, HTML 4 style heading orders inside HTML 5 wrappers like HEADER and SECTION, endless pointless classes for christmas only knows what, complete lack of graceful degradation, broken favicon link, lack of media targets so CSS is being sent to "all", goofy hard to read webfonts, pointless classes, cryptic classes, etc, etc...

Much less the lack of max-width on the layout so it's pretty damned hard to follow on a 2560 or wider display... the H4 with no H3 between it and the H2...

Comments:
#css-comments

I could go on for ages about this one in both markup and CSS. Generally if you use verbose enough classes and ID's you shouldn't need too many comments. Usually the only time I bother with comments is to make it clear what's being closed if it's too far away or block-wrapping (like the media queries) or if a value is being declared for a specific behavior not usually associated with it -- like IE specific 'hacks' or using things like overflow for float wrapping.

There's a EXCELLENT article on IBM's Linux dev site that talks at length about code clarity and commenting -- Even though it's meant for C developers I think anyone writing any form of code can benefit from it:

http://www.ibm.com/developerworks/library/l-clear-code/

As to his example, if you need a comment like that, then the class "modal-header" is an unclear crappy choice of a className. YMMV.

You get to class names:

#css-classes

... and I REALLY hate seeing hyphens in class names or ID's. To me that's using a character that has no damned business in a variable or other label in any programming language since in programming languages it means subtraction. That's why I personally prefer the underscore. It's also easier to read the underscore, for me at least. Hell, I don't even like seeing them in URI's. It's like putting spaces into filenames when delivering them online. Just say NO!

I also PREFER camelCase since it gives me consistency with every other programming language I write code for since, well...

ALL_UPPER_CASE == a define, global label or constant

lowerCaseFirstCamel == a user/programmer defined variable/object/method or CSS className

UpperCaseFirstCamel == an object class definition or PHP/JS object (since PHP and JS have objects shoe-horned into them any old way! Sad when they make C++ look well thought out)

Gives me a consistent namespace methodology across every programming language I use from Assembly to ZTK. Doesn't matter if it's C, C++, C#, Pascal, PHP, JavaScript, Java, Python, Perl, the above is valid within the namespace of all of them.

I do agree to avoid being needlessly cryptic, which is why I probably would say "button" instead of "btn". I take it further than he would on that.

Prefixing... can be useful. It's the only time I use the underscore on a variable/object/method/class is for prefixing, but really I think a lot of people go over the top on that. This is particularly true when one should be inheriting off a parent element.

This next part though about selectors?
#css-selectors

That's where it just goes full retard. You never go full retard...

The whole "classes over element" rubbish for "optimal rendering" is a bunch of BULL, since it just encourages people to slap classes on everything. There's nothing wrong with parent selectors, and there's a LOT wrong with just throwing classes at everything... that said it's REALLY hard to decipher his CSS examples as bad or good without the markup it's being applied to! CSS without the markup it's effecting is meaningless!

This obsession that's come into being about keeping selectors short and not using parent/inheritance seems to be 100% fiction that I fail to see where it came from, or why so many people are parroting it apart from ignorance and the tendency people have to NOT question things.

It's why we end up with idiotic mouth-breathing halfwit HTML like this:
<div id="main-menu">
	<ul class="main-menu-ul">
		<li class="main-menu-li">
			<a href="#" class="main-menu-a main-menu-home">Home</a>
		</li>
		<li class="main-menu-li">
			<a href="#" class="main-menu-a main-menu-forums">Forums</a>
		</li>
		<li class="main-menu-li">
			<a href="#" class="main-menu-a main-menu-contact">Contact Us</a>
		</li>
	</ul>
</div>
Code (markup):
Which should probably be just:
<ul id="mainMenu">
	<li class="home"><a href="#">Home</a></li>
	<li class="forums"><a href="#">Forums</a></li>
	<li class="contact"><a href="#">ContactUs</a></li>
</ul>
Code (markup):
With the CSS selector equivalents being:

#main-menu == removed as pointless redundancy

.main-menu-ul == #mainMenu

.main-menu-li == #mainMenu li

.main-menu-a == #mainMenu a

.main-menu-home == #mainMenu .home a

etc, etc...

The amount of "render time" spent applying these selector rules is negligible -- the difference in uncached bandwidth delivery? Well, that's a more than 50% markup reduction. Gee, which is going to pay bigger benefits when even a P133 doesn't bitch about applying selectors?

In many ways it reeks of the same bullshit the "never EVER use tables" halfwits come up with for excuses about a tables "render time" -- when a 386/33 could handle rendering tables in Windows 3.1 under the bloated and slow IE4, is that REALLY a legitimate excuse in the age of modern "faster" browsers with multi-ghz processors?

I think a lot of things like that is the magical ability people have to turn one simple statement into a global-reaching one that has NOTHING to do with the actual intent. See how "tables for layout is bad" got turned into the "NEVER USE TABLES" bullshit, or how "EM and STRONG have a specific meaning and so should be used instead of I and B when that meaning is appropriate" got turned into "NEVER USE <i> and <b>!!!" or worse, the halfwit claims of those tags being deprecated. (They aren't).

Hell, just look at how the XML-tards can't even grasp what the specification means by an "empty" element... since despite <div></div> having no content, that's NOT what the XHTML or HTML spec means when it says "empty".

... it's that type of thinking that led to the most ineptly coded BS of all markup, the default menu code for Wordpress:
<li id="menu-item-6" class="menu-item menu-item-type-custom menu-item-object-custom current-menu-item current_page_item menu-item-home menu-item-6">[/quote]

IF you don't know what's wrong with that, STOP MAKING WEBSITES NOW!!!

So basically, yeah, he and I wouldn't see eye to eye on a lot of things... but that's a style guide, you don't have to follow it personally, you only have to follow it if you are working on projects where the project manager says "we're using this" -- the REAL important message to take from that isn't so much the guide itself, as the importance of choosing a methodology, and sticking with it -- much less if you work on someone else's project, you either reformat it ALL to match your methodology, you work with it in your methodology then convert it back, or you learn to work how the original developer worked.

That said there's a LOT of stuff on that page that makes my right whip-up in knife-hand ready to deliver a pimp slap. After over three and a half decades of writing software, I see a lot of the "new kid BS" that seems carefully crafted to make sure code is bloated and prone to failure -- repeating many of the same mistakes we've been told for decades to avoid... but each generation seems to need to learn the hard way.

[QUOTE="Webinator, post: 19204025, member: 845114"]for example about the use of "em" instead of "rem".[/quote]
REM is new as of IE9, you want to support IE8/earlier, you can't use it. It's that simple.

I KIND-OF get why some people want it, but EM is NOT so "hard to use" if you are working semi-fluid. Near as I can tell MOST of the fools using it seem to either believe the 62.5% LIE, or generally have no idea what EM actually is or WHY we are supposed to use it. For SOME reason they seem to think it's entirely related to zoom or that it's an IE only thing - when you can make EM do their magic in ANY browser.

They are FOR auto-enlargement of text based on the OS or browser preference, WITHOUT scaling images. Since browser scaling of images is STILL in the dark ages for things like line-art or logo's and BARELY passable for photographs, it's a great way of handling accessibility if the site it built right.

SURE, [b]MOST[/b] people just go with the 16px = 1EM default, but this laptop I'm on right now is set to 20px/125%/120dpi/Win 3.x 8514/Win9x to XP "large" / Win V+ "Medium"... my media center is set to 24px/150%/144dpi/WinV+ Large.

.... and you can set this in ANY browser on ANY OS [b]separate[/b] from the zoom, not just IE:

[URL]http://www.cutcodedown.com/images/FF_defaultFontSize.jpg[/URL]
[URL]http://www.cutcodedown.com/images/Chrome_defaultFontSize.jpg[/URL]
[URL]http://www.cutcodedown.com/images/ChrOpera_defaultFontSize.jpg[/URL]

Which is how for example my site [URL]http://www.ewiusb.com[/URL] might look like this to most people:
[URL]http://www.cutcodedown.com/images/ewiUSB/ewiUsbComNormal96.jpg[/URL]

But auto-expands the text WITHOUT changing the image sizes at the 20px/old large/modern medium/120dpi/125%/whatever setting thus:
[URL]http://www.cutcodedown.com/images/ewiUSB/ewiUsbComNormal120.jpg[/URL]

Of course, I've been running the larger font size in one resolution higher than most people would since Windows 3.1 since we didn't have font smoothing and it reduced the jaggies. On a CRT where most people would have run 800x600 I'd run 1024x768 with the "large fonts" option. This continued in 9x and XP where most people would have run 1024x768 I'd be running 1280x1024 with the same setting. Text ends up the same size, but looked smoother thanks to the higher pixel density. 

This laptop I'm on right now has a bat**** nutters 1920x1080 display... ON a LAPTOP. Of COURSE I'm going to tell the OS to use a larger font if I'm going to be in a comfortable seating position with the display two feet from my face. Same goes for my workstation where the 2560x1440 27" center display is typically going to be 3 feet away, or the media center which may have a 1920x1080 52" display, but I'm seated six feet away from it!

I watch other people use their systems where they plaster their head 6" from the display, and think "doesn't that hurt?" -- Mac users in particular. Hunched forward over the keyboard, arms positioned so the elbows are behind instead of in front like Gollum with his precious? Then people wonder why they have back problems and eye strain.

But really that's why PX for fonts and layout are inaccessible rubbish. That's why the whole 62.5% bull is 100% lie as it's not true on all systems. That's why people making excuses for using PX on everything are ignorant fools who have no business making websites! It's why sites that try to do dumbass things like background-images of a fixed height behind text end up repeatedly broken.

[i]It's even why I have to use a user.css on most forums to override the default style into something accessible... Including this one![/i]
Code (markup):

Last edited: Jul 20, 2015

deathshadow, Jul 20, 2015 IP

KewL Well-Known Member

Messages:: 245

Likes Received:: 16

Best Answers:: 3

Trophy Points:: 128

#36

Great thread Deathshadow, but I really think you should add some future proofing as well though. The images look pretty terrible on higher PPI apple screens.

KewL, Jul 25, 2015 IP

deathshadow Acclaimed Member

Messages:: 9,732

Likes Received:: 1,998

Best Answers:: 253

Trophy Points:: 515

#37

KewL said: ↑

Great thread Deathshadow, but I really think you should add some future proofing as well though. The images look pretty terrible on higher PPI apple screens.
Click to expand...

SVG alternatives is an advanced topic, that I'm STILL not wild with given what a train wreck SVG is (there's a reason it's CREATORS want nothing to do with it)... particularly given what crap it looks like at smaller sizes. (I'd use a swapping method based on some form of media query)

Really though since the heading and image are pixels, they shouldn't be rescaling if not for Apple AND most site developers ignoring what pixels are supposed to mean -- and generally speaking I have little left in terms of tolerance for either apart from a pair of upraised fingers.

Admittedly, I've been saying **** crApple for 30 years, and still wonder how ANYONE is DUMB ENOUGH to throw money away on ANYTHING they make -- what with their goofy proprietary hardware vendor lock in, goofier software vendor lock in, and "You don't actually own an Apple, you're renting the experience" asshattery.

YMMV.

Last edited: Jul 26, 2015

deathshadow, Jul 26, 2015 IP

ketting00 Well-Known Member

Messages:: 772

Likes Received:: 27

Best Answers:: 3

Trophy Points:: 128

#38

I've a problem following the tutorial (building a real big website project).

When I cut column down from three to two. Text from the column right go down to under the bottom of column left if column right is longer. It isn't a problem with the column left.

Any suggestions?

ketting00, Jul 26, 2015 IP

deathshadow Acclaimed Member

Messages:: 9,732

Likes Received:: 1,998

Best Answers:: 253

Trophy Points:: 515

#39

ketting00 said: ↑

When I cut column down from three to two. Text from the column right go down to under the bottom of column left if column right is longer. It isn't a problem with the column left.
Click to expand...

Can you post up what you have so far? If you don't want to make it public yet, feel free to PM me and I'll take a look.

Not quite sure what you mean -- are you saying it's expanding below the content column (you say left right left right so much without saying which witch is which) or that it isn't? The former shouldn't happen, the latter is, well, the natural behavior which can seem off if you've got too much stuff in the sidebar and not enough content.

I'd have to see what you've done.

deathshadow, Jul 27, 2015 IP

ketting00 Well-Known Member

Messages:: 772

Likes Received:: 27

Best Answers:: 3

Trophy Points:: 128

#40

Thanks @deathshadow,
You've already answered my question. The left column is expanding to below the right column. It's not a big deal. What I need from your tutorial is the layout and the behavior when the site appears on different screens. I give priority to mobile devices.

What's enticed me the most is these three lines of code:
    -webkit-flex:1 0 auto;
    -ms-flex:1 0 auto;
    flex:1 0 auto;
Code (markup):
It overrides my previous knowledge what I know about full page height and sticky footer.

Hope you keep more tutorial comings.

ketting00, Jul 27, 2015 IP

Log in or Sign up

Advertising (learn more)

Progressive enhancement -- design from the inside out.

kk5st Prominent Member

deathshadow Acclaimed Member

deathshadow Acclaimed Member

Matthew Sayle Prominent Member

deathshadow Acclaimed Member

deathshadow Acclaimed Member

ketting00 Well-Known Member

kk5st Prominent Member

PoPSiCLe Illustrious Member

deathshadow Acclaimed Member

deathshadow Acclaimed Member

Matthew Sayle Prominent Member

Matthew Sayle Prominent Member

Webinator Peon

deathshadow Acclaimed Member

KewL Well-Known Member

deathshadow Acclaimed Member

ketting00 Well-Known Member

deathshadow Acclaimed Member

ketting00 Well-Known Member

Log in or Sign up

Advertising (learn more)

Progressive enhancement -- design from the inside out.

kk5st Prominent Member

deathshadow Acclaimed Member

deathshadow Acclaimed Member

Matthew Sayle Prominent Member

deathshadow Acclaimed Member

deathshadow Acclaimed Member

ketting00 Well-Known Member

kk5st Prominent Member

PoPSiCLe Illustrious Member

deathshadow Acclaimed Member

deathshadow Acclaimed Member

Matthew Sayle Prominent Member

Matthew Sayle Prominent Member

Webinator Peon

deathshadow Acclaimed Member

KewL Well-Known Member

deathshadow Acclaimed Member

ketting00 Well-Known Member

deathshadow Acclaimed Member

ketting00 Well-Known Member

Useful Searches