Kwebble blog

There's a discussion about a change to the CSS syntax to include nesting, and we can help. But it is already decided that we won't get the most desirable syntax we want, which apparently is the syntax used by Sass. This is the reason why:

Everyone wishes CSS nesting could use the same kind of simple syntax that Sass does. That’s impossible, however, because of the way browser parsing engines work. If they see a sequence like element:pseudo, they’ll parse the entire style rule as if it were a property: value declaration.

But we are writing new specs. We should not be limited by the current syntax that the parser of the apple browser can process (the post is published on the WebKit site, apple's browser engine). Sass is prior art. Designers/frontenders/developers know it, use it and like it. Make it easy for them. Change the software to do what the users want, not the other way around!

The fact that a browser cannot handle the Sass syntax at this moment is irrelevant. Whatever the new syntax will be, that software will have to change. And it has been proven that it is possible to parse the Sass syntax. IT IS WHAT SASS DOES. And has, for quite some time. Just look at the source code. Even more, that source code is freely available for reuse under the MIT license.

What do I prefer? I prefer simplicity. Personally, I find over time CSS has gotten more and more frustrating to use. There are so many properties and layout options, all with minute nuances that make it hard to combine them in a predictable manner. In fact, I think CSS no longer is a programming language for humans. It seems more like a machine-readable serialization format for design specifications, Only without proper design tools that know how to handle those small details and can present a convenient user interface to manipulate all of them.

The final syntax will probably be more difficult than it needs to be. So for those that need to implement large CSS based systems I suggest you stick with Sass and not worry about the code fed into the browser.

Pfff, just had to get that out of my system.</rant>

While building a PHP tool today an error occurred when executing a prepared SQL statement with PDO:

Warning: PDOStatement::execute(): SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''0', '10'' at line 5...

An old answer helped to solve the problem. After changing PDO setting PDO::ATTR_EMULATE_PREPARES to FALSE the code ran fine.

Note: As it turns out, the technique described here is pretty useless. Nearly no browser supports text-justify and when it does it's not certain the text will be spread across the full width of the block. And that isn't considered a bug.

For a site I'm working on I want to create a layout with two lines of text that have the same width, something like this:

To justifiy a single line of text with CSS text-align together with text-justify doesn't work. Look at this example:

<p style="background-color  : #369;
          color             : #fff;
          text-align        : justify;
          text-justify      : inter-character;
          width             : 20ch">
     Some text
</p>

Result:

Some text

The text is justified to the right and not spread across the complete box. The reason is that text-align does not apply to the last line. If there is only one line, it also is the last, so the property does not apply.

Justification for the last line is set with the text-align-last property:

<p style="background-color  : #369;
          color             : #fff;
          text-align-last   : justify;
          text-justify      : inter-character;
          width             : 20ch">
     Some text
</p>

Result:

Some text

The type of justification is determined by text-justify, but that also sets the justification of the other lines in the text. So you can change the alignment of the last line, but not the type of justification.

In case where there is only one line, which is what I needed, this is not a problem. And using different types of justification probably does not provide a very consistent layout.

The PHP method PDOStatment::errorInfo() retrieves information about the last operation on the statement. But when the result of PDOStatment::execute() is FALSE it may not return much useful information:

Array (
    [0] => 00000
    [1] =>
    [2] =>
)

To get more data, check the value of PDO::ATTR_ERRMODE. The default value is PDO::ERRMODE_SILENT but that silences errors during PDO execution. During development it can help to change it to PDO::ERRMODE_WARNING to emit an E_WARNING when an error occurs.

$pdo = new PDO(...);
$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_WARNING);

To get the details of the prepared statement use PDOStatment::debugDumpParams(). It will output the query and the passed values.

This is mainly for my own future reference. You can configure Firefox to use a light theme, but that doesn't actually mean the configuration pages are shown as dark text on a light background.

Why? Probably because the color settings of the operating system overrule a manual setting in the application. Looks like a bug to me.

To fix this a setting is required. Open about:config (more info about that) and find the setting ui.systemUsesDarkTheme. Change the value to 0 (zero).

Now this setting is so advanced it may not even exist in about:config, like on my installation. In that case create it with a the type Number. Set the value to 0.

Value 0 forces Firefox to always use Light theme mode.
Value 1 forces Dark theme mode.

Source

CSS can create striped backgrounds with the repeating-linear-gradient() property.

Dave Winer asked about simplifying such JavaScript code, used a lot for callbacks:

if (callback !== undefined) {
    callback ();
}

Here's a suggestion. Processing could be moved to a helper function, shortening the call:

function callbackIf (
    cb
) {
    if (cb !== undefined) cb()
}

// Usage
callbackIf(callback)

To pass data to the callback I would extend the helper to accept a variable number of arguments and pass them through:

function callbackIf (
       cb,
    ...args
) {
    if (cb !== undefined) cb(...args)
}

// Usage
callbackIf(callback)
callbackIf(callback, 'Hi', 'there')

In Firefox handling colors defined in CSS differs between properties. Here's an example that uses the same values for a linear gradient and fixed background color:

The color of the second block should match the color at the bottom of first block. On my monitor they don't. The gradient ends in a bright blue. The second block is some kind of purple.

Here is an image showing the the way it looks on my computer:

The actual colors on your screen are almost certain different from mine, but I hope this shows you there's a difference.

Checking the colors with a colorpicker shows the color values. Both should be #0066FF. The gradient ends with color #0065FD, which is almost correct. The second block has color #4854FA, which is quite wrong.

The colors were determined outside the browsers, with Instant Eyedropper. I used this tool to be independent from implementation of the browser tools.

After some investigation I found that it depends on the Firefox setting gfx.color_management.mode. The value on my system is 1. That should instruct Firefox to manage colors based on the color profile of my computer.

With the setting gfx.color_management.mode set at 2, the default value, the second block is blue, matching the gradient. But I want it set to 1 to view the photo's using the correct color profile.

The solution for now is to also set the color of the second block as a gradient, but using two equal colors. Visually it's a single color, but by using background-image property the browser uses the same algorithm to set the color as for the first block.

background-image: linear-gradient(to bottom, #06f, #06f)

Chromium

In Chromium at least the displayed colors are equal. That means there is no visible color difference at the seam of the two blocks.

The problem here is that the displayed color looks like the bottom block in Firefox. More a purple than blue. The color value is #4754FB.

Handling color in browsers is notoriously difficult, because of differences in support for color profiles, browser settings and image metadata. Here you see that even in a single browser, two CSS properties are treated differently.

Future

Work is in progress with CSS Color Module Level 4 to improve CSS color support by adding a way to define colors outside the sRGB color space. The lab() and lch() should provide us a means to define colors based on the Lab and LCH color spaces.

When I saw the Star Wars Spoiler Generator on xkcd I knew making a working actual generator for this text would be easy. This is a perfect match for Durcruq, my own software for text generation.

So, here are some spoilers:

Regenerate spoilers

Text by Randall Munroe (CC BY-NC 2.5), font by the ipython community (CC BY-NC 3.0)

Interested in programming a ray tracer? The book series Ray Tracing in One Weekend is now available for free.

When I first heard about ray tracing, it took hours to generate anything interesting on my computer. The software I used then was the Persistence of Vision Raytracer. It's still available.