As a front end developer, it can be really annoying when a .NET server control changes your textbox id from something like txtFirstName to, say, MainContent_AccountInformation_pnlAnotherLevel_txtFirstName. How can I remember that?! What if I move the control out of the container? Then my ID will change!
Here comes the attribute ClientIDMode to the rescue. Simply stating ClientIDMode="Static" tells .NET to keep the id to what we assigned it. Front end developers, rejoice!
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 */
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:
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.
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.
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 issuesvaryper 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.
[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.
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.
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.
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:
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?