My coworker blew my mind this morning. Anyone working with secure sites knows that there's often security flags thrown if you're referencing a file via
http:// when the site is under
https://. To avoid these, in the past I have always done an if/else in whatever language the site was written. For example:
/* pseudocode */
<link href="https://fonts.googleapis.com/css?family=Cabin&v1" rel="stylesheet" type="text/css" />
<link href="http://fonts.googleapis.com/css?family=Cabin&v1" rel="stylesheet" type="text/css" />
In debugging some code on our site, I noticed that the aforementioned stylesheet was only linked in the Secure check, and forgotten in the else.
Lo and behold, you can avoid these confusions by including your external references without the protocol included. That's right, drop off the
http: and just leave two slashes and the link, as follows:
<link href="//fonts.googleapis.com/css?family=Cabin&v1" rel="stylesheet" type="text/css" />
It works perfectly and you can simplify your server code. C'est magnifique! I'm not sure about older browsers, so if you run into an issue, leave a comment and I'll note my post accordingly.
UX Movement wrote an excellent post on why links should never read "click here".
I've always known this for reasons of SEO. You're really minimizing your SEO by attaching the link to a bunch of "Click Here!" text. Search phrases are tied to link text throughout the web and you engender greater value through your link text for future searches. A thought I had not considered lies in the disconnect of content by pulling users out to "click here". "Read the article at neatlysliced.com" ties the user to the content and flows him to the next step. On the contrary, "Click here to read the article" pulls the user out of the article and reminds him of the hardware interface he's using to read.
Not to mention, it's semantically incorrect for iPad, iPhone, and other touch interface users.
There are many other examples in their blog post. I highly encourage that you read "Why Your Links Should Never Say 'Click Here'"!
In the new company I work for, a customer can generate a sales report and convert to PDF for download. To accomplish this, we take the valid HTML page (valid XHTML) which we read as XML to process to create our PDF.
This works well except in the instance where a user has activated the Skype Firefox Extension.
What is the Skype Firefox Extension? Skype is a messaging tool that also allows users to make phone calls over the web through your computer. The Firefox extension is a tool that visually highlights the phone numbers on the webpage (from what I can tell Firefox has soft-disabled the add-on for now but all of our users had previously installed it and/or re-enabled it). You can then click on the phone numbers and call them with Skype. Pretty handy, right? Yeah! So what's the problem?
Well, the issues vary per site. To accomplish the highlight, the plugin injects some HTML around the phone number with inline styles to alter background color to highlight. For our case, the faulty injected syntax breaks the valid XHTML - inputting a
tabIndex=-1 (without valid attribute markers) which breaks our XML conversion to PDF.
According to Skype's Program Manager:
[T]here is a tag that you could use to make sure that the toolbar does not parse your web page for phone numbers.
Please insert this tag and no numbers will be highlighted.
<meta name="SKYPE_TOOLBAR" content="SKYPE_TOOLBAR_PARSER_COMPATIBLE" />
The meta tag works for some but not for others. In our case it did not work (the code was still injected) and we had to manually search for those class names and strip them out prior to export for the PDF builder. Following the manual stripping, it returned the DOM to valid XML and the conversion proceeded without fanfare.
Many of us know that HTML5 sections allow the programmer to restart headings at H1 and still keep proper HTML outline format. What I did not realize is how problematic this can become to style in an active and growing site.
Covering all of your bases develops quite the headache.
Stubbornella develops a brilliant heading class naming convention to handle this new development in front end writing. Typically, I disapprove of classitis in headings. However, with this growth in HTML regarding sections and headings, my opinion must evolve in like manner.
For future reference for myself, in case Stubbornella disappears before I do, the class suggestions are as follows:
Which is implemented as:
Me on the web...</h1>
My Twitter Feed</h1>
More stuff on the web</a></p>
Please visit Stubbornella and read the whole article. It developed my thinking to a more complete view.
In testing a site, I found some interesting quirky behaviors with IE. The CSS was syntatically correct and it confounded me why the visual flubs were smattering my site. Upon closer examination, I found that the site had no doctype.
Just a note, dear reader, that I came into this project after it was already written and was trying to eliminate some bugs as I was finding them.
So, there was no doctype. Interestingly, IE will throw the document into Quirks mode if no doctype is found. Did you know that? I sure didn't.
What is Quirks mode?
Quirks mode refers to a technique used by some web browsers for the sake of maintaining backward compatibility with web pages designed for older browsers, instead of strictly complying with W3C and IETF standards in standards mode.
To sum up, it will make all versions of IE start to behave like IE5.5. Yikes, right? That's what I thought. That's actually the intended behavior, though. Just in case they had problems, developers could omit the doctype and thus have their tried & true version of IE. QuirksMode.org thoroughly explains it and tells us the rationale behind these decisions. It's also called "DOCTYPE switching".
Apparently all of this was already developed by the time I started learning web development, and so this was all new to me. Perhaps this will help you on a headachy night if you have to work on some code that relies on Quirks mode!
All references I found useful in learning about this matter:
Luke Wroblewski recently wrote about the new sign-in screen for Backcheck. In this latest rev, a user needs only to type in their name and a ajax search reply returns a listing of users matching what you've typed.
In addition, once you've selected your name, you can see whether you can log in via Facebook, Twitter, or default Bagcheck credentials.
Although I recognize the usability of this method, I also pause in trepidation. Users concerned with privacy may grow wary. All I have to do is type in a name, and I have a listing of potential users I can hack. I just have to click on names and try some commonly used passwords and I may have easily logged into another user's account. Who knows what ill acts malicious users may have planned.
I like the added piece of security of needing to type in my username. This way people can't browse my name wondering if I have an account there, and discover that I'm using Twitter as my login key. Please don't simplify it for hackers to "stumble upon" my username, thus making it easy to try a password to break in to my account.
I'd like to acknowledge that Bagcheck is not a web application storing critical personal information, and those Bagcheck login credentials are not as "important", per se, as Amazon or eBay or others of that ilk. Luke Wroblewski made reference to this fact in his comments on the aforelinked post, and Sam in the comments noted that most online applications share your publicly displayed username with your login name.
I do give reason for pause in seeing my real, full name in print without authorization, for other users to peruse. I feel a sense of security signing in with an email address or a username, along with my secure password.
I will echo a question that I proposed on twitter: Am I too paranoid for worrying about this?
As a consumer, I love Groupon. I get deals to some of my favorite places. The other week I got 50% off one of our favorite (but expensive) restaurants.
The deals are fabulous for the consumer, but we've often wondered - how can this be good for the business providing their services for Groupon? I get 50% off, and Groupon takes their cut… what profit can be gained for the business?
Nine Rubies, a knitting store in San Francisco, recently blogged about their experience with Groupon. To sum up: It's a bad deal financially, but it's a marketing investment.
There are quite a few repeat customers for the sampling that we looked at. More than that, people who had not visited our store were somewhat jolted into coming to our store again. I think this is all good news. For what I would call minimal amount of work, we got a lot of new customers.
Read the whole story - including sales statistics - at site.ninerubies.com.