To disable that annoying highlight via CSS:
* { -webkit-user-select: none; }
To disable that annoying highlight via CSS:
* { -webkit-user-select: none; }
While dojo toolkit’s dijit.Dialog is a great tool to use, it’s a bit confusing as to how it can be reused as a function. For example, to replace the common JavaScript function confirm() you can use this code:
var c = confirm(
"Please confirm deleting this item"
);
alert( "you picked: " + c)
While not exactly the prettiest or the most elegant solution – it is the quickest. Why spend time creating HTML and writing large routines when you can fall back onto one of the few synchronous functions available for browsers?

Well, this might be why. Kind of an eye-sore.
While this can be done with toolkits, such as Dojo, it can be cumbersome. You have to create some HTML for each dialog and write routines to make it work.

Worse yet – toolkits, much like rest of JavaScript, are asynchronous – meaning that you can’t pause execution of code until the user responds. Thus, you’d probably have to revise your code execution workflow to get prettier dialogs.
Luckily and thanks to the foresight of the Dojo guys, you can easily reuse the dialog and make a generic and reusable JavaScript function to use dijit.Dialog. You just have to alter your way of thinking a tiny bit.
First, some HTML:
<div id="id_dialog" dojoType="dijit.Dialog" title="fidget">
<div style="width:300px; height:150px">
<div id="id_dialog_text"></div>
</div>
<div class="dijitDialogPaneActionBar">
<button
dojoType="dijit.form.Button"
type="submit"
id="id_dialog_button_1"
>Yes</button>
<button
dojoType="dijit.form.Button"
type="button"
onClick="dijit.byId('id_dialog').onCancel();"
id="id_dialog_button_2"
>Cancel</button>
</div>
</div>
Now, this is a gross-oversimplification, but you’ll get the idea. To see examples of how to implement dijit.Dialog in its entirety (note this example uses declarative widget creation instead of programmatic), see http://docs.dojocampus.org/dijit/Dialog
<script type="text/javascript">
dojo.require("dijit.Dialog");
dojo.require("dojo.parser");
function fancy_confirm(title, message, onYes, onNo) {
dijit.byId('id_dialog_button_1').attr("style", "color:crimson;font-weight:bold");
dijit.byId('id_dialog_button_1').attr("label", "Yes, Delete");
var p = dijit.byId('id_dialog');
p.attr( "title", title );
dojo.byId('id_dialog_text').innerHTML = message;
p.execute = dojo.hitch( p, function() {
if( dojo.isObject( arguments ) ) {
onYes();
} else {
onNo();
}
});
p.show();
}
</script>
To use this generic function, you simply wrap your follow-up code inside a function:
fancy_confirm(
"Please Confirm deleting",
"Are you sure you want to delete this pretty thing? <html goes here />",
function() {
alert( "sadly, you picked yes" );
},
function() {
alert( "hooray, this content item lives on" );
}
);

This Friday was my last day working for The Baltimore Sun. Before I moved onto my next adventure in life, I snuck onto the 6th floor of the Sun building and took some photos with my trusty iPhone camera. Though I entertained thoughts of rollerblading up here before, fact of the matter is that by the time I got up here I was already all out of breath. Sure, it’s only stairs, but I’m way out of shape.

But, of course. How silly of me.
Come to think of it, that’s not really a false statement.
It’s just that the poor overworked spell check button can’t find any – it doesn’t state that they are not there.
wp_insert_post() is an awesome function, but, it seems to filter HTML to unauthenticated users by calling sanitize_post(). So, if you’re logged in as an admin / editor – the function seems to operate fine. However, if you’re a random user who is not logged in, the function seems to filter all ‘unsafe’ HTML out.
Some uses for wp_insert_post() are for batch importing records, CSV data, etc. Other uses are for extending or developing UGC tools.
In my case, I was making an oEmbed submitter; therefore, it’s assumed that the oEmbed returned safe code (from youtube, soundcloud, etc). However, wp_insert_post() kept stripping the <object> and <embed> tags out of the post content.
I googled these terms trying to stop it from happening, but got nothing:
As a last resort, I looked through the wordpress source code and discovered a little trick. Though this isn’t documented – you can apparently trick sanitize_post() into thinking that the post has already been filtered.
$post_id = wp_insert_post(
'post_title' => $my_post_title,
'post_content' => $my_unfiltered_html,
'post_status' => 'publish',
'post_category' => array( get_cat_ID('lolcat') ),
'post_date' => date("Y-m-d H:i:s", strtotime("-24 hour")),
'post_date_gmt' => date("Y-m-d H:i:s", strtotime("-20 hour")),
'filter' => true
);
And that wraps it up; the code (at least as of 2.9.2) only checks whether the “filter” key is set (isset($post->filter)) and setting that lets you bypass sanitization routines.
Recently I tried best of the iPhone apps that can take panoramic photos and I’ve been disappointed with their performance. Main issue is that (presuming due to memory and CPU speed restrictions) the final photo resolutions are pitiful.
So, I do my panoramic photos the old fashioned way – stitching via Hugin.