Notes to follow.
Monday session:
Alright boys and girls, hold on to your hats. I have launched a new food blog at yum.neatlysliced.com. It features a shiny, pretty, and delicious design and one recipe for gingersnaps.
I’m not the best cook or baker in the world, so a lot of it will feature comical tales of my cooking attempts.
If you like food, bookmark, subscribe, laugh, and share foody goodness with a cooking newbie.
I have previously used the following to check if an element belongs to a certain CSS class:
This method fails when an element bears two or more classes (which I have been using more frequently). A better method is to use JavaScript regular expressions methods to find whether the class attribute contains your class. Visit regular-expressions.info for a crash course on regular expressions if you are unfamiliar - they are fabulous and you must learn to use them.
There are several JavaScript RegExp methods we can implement. The best for this purpose is the test() method.
With the following HTML, the aforewritten regular expression will return true. Using the JS equality operator would return false.
Shameless plug:
One of my photos was used at Home & Abroad - a travel site. It is used on the page featuring the Waikiki Shell. View the Waikiki Shell page. Rockin'.
Note: I have updated this post several times since the original publish.
At long last, the July winner is announced. Congrats.
The notes from the judges regarding my entry (I am #12) really did not extend much beyond my own observations.
Tony wrote that my .bug class is superfluous. I wholeheartedly disagree, for if the design were to change to add currently nonexistent divs that are not bugs, it will potentially complicate the code. Those elements will require classes. Then, where do you draw the line? Which divs require a class, and which do not, or should both have classes? I find it applicable to use the .bug class here, and were I to code it again, I would design the markup (for this section) in an identical manner. Plus, it makes more sense semantically when browsing the code.
JD noted that some stylistic elements were off. I know, I know, and I noticed them after I sent it in. I wrote about it in my aforelinked observations. He did not like the placement of the dots. That is a situation where, in coding the layout, I would call the designer to my desk and ask for his or her feedback. It is part of the challenge of this competition: trying to read the mind of the designer. In this practice, I inch toward the betterment of my own design skills. The variances between my mind and JD's were the downfall of this entry, but with his feedback I have a better understanding where I might improve next time.
I will refrain from comment on Ott's winning entry. It renders poorly in my Safari browser (along with the greater number of the entries), so I don't want to pursue the discussion any further, other than to elucidate the obvious problematic elements in Safari:
Ott's is a nice fluid layout, other than the Safari flaws. There's no hate, Ott, just my browser that never gets any dev love.
I'll still participate in the next contest, for my own CSS practice and article inspiration. In any vein, this contest is good because it gives me a rounded perspective of my front end dev skills, although I cannot refrain from expressing one more time my confusion over the explicit flaws of the winning entries of this competition and the previous. Okay, scratch that - they are not explicit flaws, but just... averages. The winning entries were average, not extraordinary or particulary noteworthy or clean, but just overwhelmingly normal and average. They are entries that I would see get the bronze medal - good, but better around who swoop in for the gold.
I absolutely adore the detailed notes on each entry. From skimming, I noted a few things I will give a second look (see: elastic rounded corner yellow box). I encourage all to peruse the notes.
The following remark by the CSS Off guys struck a particular chord with me:
As web programmers, our job is to translate a design to the web. That means taking into account different monitor dimensions and resolutions. And then designing the site to look good in them. A site loses trust points immediately when the design doesn’t look “finished.”
It is the mindset we ought to have, as sometimes we focus too much on the back end of a site to remember that key fact of good-looking sites reigning. The original point of the statement was to utilize the space of the screen, but I apply it in that we must to have a hand in the design nearly as much as the designer, and must keep a keener eye on our results.
And I got a good chuckle over the judges' references to my namesake (neat!). Thanks for the linklove, judges! Keep up the good work.
A design may call for the header or footer to span 100% width of a page, but the body of a design spread to a set width. Easily implement this by extracting the 100% width item from your main container div.
Easy as sliced cake!
Josh highlighted Easy Envelopes by AmbrosiaSW, and I find it so well crafted that I, too, have selected it for the widget of the week.
As Josh summarized, it is a widget to aid in printing envelopes. It integrates Address Book, using your Me card as the return address and permitting insertion of addresses in the To field.
I must admit that my favorite feature of the widget is a nuance that I wish were implemented in all widgets: minimization. With a click on the postage cancellation, the widget will shrink to a size to safely tuck away in your dashboard without filling extra space. Click anywhere on the miniaturized widget to enlarge, ready for use. Yes, the image to the left is the actual size of the mini-mail.
