
👋 Oi, mga repapips, Brian Dys here! I love music, photography, and creative stuff like UX design and art. This is a place where I collect my thoughts and works. Apart all these, I’m Jaycelle’s better half and Bryce’s dad. 🥰
Hey, remember that time when you switched from the table layout to div layout?
This is the time to be “out with the old and in with the new”.
We’ll be leaving behind the contraption that alleviate the pains of the CSS box model.
Just to refer to that contraption, familiar with this?
[code]
<div class="module">
<div class="module-container">
<div class="module-content">
Content
</div>
</div>
</div>
[/code]
To not worry about computing widths, we apply it to module-container and the paddings, borders, and margins to module-content.
[code]
.module-container {width:75%;}
.module-content {
margin:1em;
padding:1em;
border:1px solid red;
[/code]
This way, we know that 75% is 75% and no additional values from the other parameters.
But to get rid of module-container and module-content in the HTML markup, we simply apply a border-box:box-sizing style to module.
[code]
<div class="module">Content</div>
[/code]
[code]
.module {border-box:box-sizing;}
[/code]
This will make sure that the box follows the exact width you specify no matter how many paddings and borders you apply to the same element.
For detailed readings, read Paul Irish’s * { Box-sizing: Border-box } FTW.
You have a paragraph with a URL in it–chances are the boundaries might wrap or cut your URL into two lines.
Notice that it is an actual URL in the form of http://[address] and not just a linked bunch of text.
[code lang=”html” gutter=”false”]<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut nisi ante, hendrerit sed pretium id, fermentum sed tellus. Integer venenatis, turpis in tempus cursus, odio sapien tincidunt mi, in iaculis nibh nisl eget metus. Proin ultrices elit non nisl vehicula suscipit <a href="#">http://www.double-u-double-u-double-u-dot-wawawa.com</a>. Suspendisse interdum nisl ac risus consectetur ut hendrerit tellus aliquam.</p>[/code]
Why don’t we like that? Because it’s supposed to be in one unit.
So, add a class to the anchor tag:
[code]
<a class="url" href=""#">[URL]</a>
[/code]
and tell CSS to:
[code lang=”css”]
.url {white-space:nowrap;}
[/code]
That should put the whole URL link in one line.
Say you want to center your navigation on the page:
[code lang=”html”]
<ul>
<li><a href="#">Home</a></li>
<li><a href="#">About</a></li>
<li><a href="#">Contact</a></li>
</ul>
[/code]
Simply tell CSS to:
[code lang=”css”]
ul {text-align:center;}
li {display:inline-block;}
[/code]
And don’t forget to remove any float on those elements, if any.
I’m being confounded about an article I’ve read about your logo being an image (and not a background image). You would notice about the differences between the two wherein img
puts your actual image on the page and h1
replaces the text with a background image of your logo.
You may be using one method over the other — and to calm your nerves down, Facebook and WordPress use h1
approach while Google and Firefox use img
approach (and a whole lot of different combinations for other sites out there).
Now, I won’t go into details about both methods because I’m sure you’re already using one — even different from the two mentioned. What’s important is the answer to “why are we using what we use?”
The answer lies on your priorities.
If you’ve answered the former, then most likely you’re using h1
approach and the latter, img
approach.
Personally, the way I test if I’m writing a web document properly is I strip it off everything — images and CSS — and see if it still makes sense from having semantic HTML elements to its document outline. And one of the natural steps in this test is having a heading on top of your document — usually the title of the site — it could be a logo or an photograph with an inscription — but what it represents is more important.
There are lots of combinations in putting up a logo on your webpage — just be conscious of why you’re choosing one approach over the other.
We’ve been following Yahoo!’s Best Practices for Speeding Up Your Web Site for quite a while now and have been fine in following some of the tips — that we’ve forgotten to extend out our antennas to hear about what’s going on out there in the world of website page load performance.
This one isn’t really that technical but a “perceived performance” — it’s making your JPEGs progressive (basically if it larger than 10k in file size).
There is also an interlaced “Progressive JPEG” format, in which data is compressed in multiple passes of progressively higher detail. This is ideal for large images that will be displayed while downloading over a slow connection, allowing a reasonable preview after receiving only a portion of the data.
Instead of waiting for that JPEG image load line per line, what you would see at first is a pixelated version of the image in full size and it improves its quality as it downloads.
Read more about it in Progressive jpegs: a new best practice by Ann Robson
In a quest to streamline and improve our HTML markup, I’m looking at how the page would appear to a person using an assistive device such as a screen reader.
I’ve installed Fangs – a Firefox extension that “helps developers find accessibility issues in web pages and managers to understand how their website may appear to a person using an assistive device.”
In Fangs preferences, switch the output style to “Sectioned” to have an overview of the sectioning of the HTML document — this is related to checking the outline.