BlogmyQuery – BMQ

A while ago I posted Tips for creating enterprise-level HTML, CSS and JavaScript, where I mentioned a few examples from the Enterprise CSS, Enterprise HTML, and Enterprise JavaScript sites.

The examples on those sites are meant to be ironic, showing what not to do. Some readers have contacted me because they feel that the irony isn’t completely obvious and are worried that people getting started in front-end web development would misinterpret the “tips�. They do have a point, so I thought I’d bring up a few of the examles from the Enterprise CSS/HTML/JS sites and explain why I think they are bad examples.

Read full post

Posted in (X)HTML, CSS, JavaScript.

For several reasons you may want to keep the site you are working on under wraps. It could be because it contains potentially sensitive information, because your client demands it, or simply because you want to be in control.

If privacy is important to you and you want to work with WordPress, there are a number of things you need to do to prevent your development site from revealing itself by sending information to wordpress.org or other domains.

In this article I’ll list some of the options you have.

Read full post

Posted in WordPress.

At the very least checking that your site looks and works ok in a mobile browser is becoming part of the job for most web professionals. Tweaking things a bit for mobile by using Media Queries or even making a separate, “optimised�, site is also more common now than a year or two ago.

The problem is checking your work in mobile browsers. It seems like “everybody� has an iPhone and/or an iPad these days (except me), so Safari for iOS is pretty easy for most developers to check in. But what about other mobile browsers?

Read full post

Posted in Browsers, Mobile Web.

In late 2009 I wrote an article explaining that Vendor-specific extensions are invalid CSS. They are also a fact of life if you want to be able to use new CSS features, which most of us do.

As I explain in the article, the CSS Validator reporting vendor-specific extensions as errors is correct, but it does make it difficult to find any real errors (typos, syntax errors, etc.) among all the “Property -webkit-border-radius doesn't exist� and similar messages. And as we add more and more vendor-specific selectors in order to use CSS3, this situation gets worse.

I suggested that the CSS Validator could somehow let you know if the errors are caused by vendor-specific extensions or if they are actual syntax errors. Well, something similar to that will soon be possible since CSS Validation Will Soon Be More Realistic.

Read full post

Posted in CSS.

The day after the W3C unveiled the HTML5 logo, the WHATWG announced that HTML is the new HTML5 and that they will stop using version numbers for their HTML specification.

The main reason for this seems, according to the WHATWG FAQ, to be a desire to fix bugs in the specification and add new features as soon as possible, instead of having to wait for the next version.

That sounds sensible. Fixing bugs and omissions sooner rather than later is good, right? In general it is, of course. However I think it may be a bit problematic in the real world for people who author (“author� is spec writer lingo for front-end developer) websites and want to follow specifications, i.e. validate their markup and have it stay valid according to the rules that were known at the time.

Read full post

Posted in HTML 5, Web Standards.