CSS rule to target only Firefox

I just found (via enure.net) a CSS rule using proprietary Mozilla filter that would allow one to specifically target Mozilla.

I'm not a huge fan of CSS hacks like that, I usually restrain them to the bare minimum of IE conditional comments. But in some edge cases, it is sometimes useful, if you really don't have other options.

I'd like to find the equivalent rules (using proprietary rules, no parser bug) for Safari, Chrome and Opera

@-moz-document url-prefix() {
  p { color: red; }
}

Updated CSSTidy files

CSSTidy allows you to optimize your CSS files by aggregating them in one unique file, removing useless spaces and comments as well as running some other optimizations on multiple declarations and shorthand notations.

But if, like me, you're still using the 1.3 version available on the official website, you may have run into issues when dealing with the latest CSS3 goodies.

I've been hacking this library in the last year, adding support for @font- face and for proprietary prefixed properties values, but today I was faced with some other issues that I wasn't able to resolve.

CSSTidy does not use regexp to parse the file, it reads it one char at a time and does its optimization at the same time, and it is sometimes quite hard to follow.

Anyway, I just discovered that the Sourceforge page of the project is still up and running and that a commit was added today, so the project is not dead ! I also posted two bug reports and one (dummy) patch.

Here's the link, you got a download link at the bottom : http://csstidy.svn.sourceforge.net/viewvc/csstidy/trunk/

-webkit-box-shadow inset value

Webkit browsers (Safari and Chrome) have the -webkit-box-shadow property defined to add shadows to elements. Shadow can either be outside the box, or inside it (using the inset parameter).

Unfortunatly, only the latest Webkit nightlies have the inset parameter functionnal, Safari 4 does not.

Chrome does indeed have the inset parameter, but it also have a bug when used in conjunction with the -webkit-border-radius property : the inset shadow is visible "behind" the element where the borders are rounded.

This bug does not occur on Mac, but as I have no way to target a certain OS when writing CSS rules, I decided to remove inset box-shadow for webkit browsers on my actual projects, I may re-insert them later when both issues will be fixed.

cakePHP i18n extract and plugins

Cake has a lot of wonderful tools in its console. One of them is the i18n extract task that reads every file of your app, and extract strings that should be translated (used with __(), __d(), etc).

With cake 1.3 RC3 it even stored each domain string in its own .pot file.

But, as far as I know (I've posted on the google group about that, maybe someone will show me where I'm wrong), the console task is limited when dealing with plugins.

Let's say I have a plugin in my app. I'm using __d('plugin_name', 'My plugin string') in my plugin and __('My app string') in the main app.

If I run the cake i18n extract in my plugin directory, it will correctly generate the .potfile in my plugin locale/ folder.

But if I run it in the main app, it will scan every plugin file and thus finding any plugin string and save them in the default.pot or in its own plugin_name.pot file (depending on the value of the merge option).

I don't need the plugin_name.pot files in app/locale, I already have them in app/plugins/plugin_name/locale. I know it's no big deal, I just have to delete the useless files created every time I run the cake i18n extract on the main app but it is kind of irritating.

So I updated the cake/console/libs/tasks to add a new option to the task, named 'plugins' (value : yes/no. Default to no).

If set to no, the extract task will skip every plugin directory when extracting files. This way, I have no more clutter, it only extract string that are in the app.

All I had to do was updating the execute() method, and replacing the end of the method (from line 152) with this one :

$this->params['plugins'] = isset($this->params['plugins']) ? $this->params['plugins'] : 'no';
if (empty($this->__files)) {
  if ($this->params['plugins']=='yes') {
    $this->__searchFiles();
  } else {
    $this->__searchFilesExcludePlugins();
  }
}

And then add this method to the class :

function __searchFilesExcludePlugins() {
  foreach ($this->__paths as $path) {
    $Folder = new Folder($path);
    $filelist = $Folder->tree($path);
    foreach($filelist[1] as &$file) {
      // We discard plugins
      if (strpos(str_replace($path, '', $file), DS.'plugins')===0) continue;
      // We keep those that match the pattern
      if (!preg_match('/^.*\.(php|ctp|thtml|inc|tpl)$/i', $file)) continue;
      $this->__files[]= $file;
    }
  }
}

Generating salt values

Wordpress made available a nice tool to generate fairly complicated strings, perfectly usable as salt value for all your password hashing process.

As I'm often heading to this page to generate new ones on new projects I thougt I may share the link with you :

https://api.wordpress.org/secret-key/1.1/bbpress/