[ Empty Spaces ]Wandering through, a journey withintag:emps.l-c-n.com,2005:16aac28d294345a6de82c1a14ba2b582Textpattern2018-05-23T03:13:36ZPhilippe Wittenberghhttps://emps.l-c-n.com/Philippe Wittenbergh2018-05-15T12:07:03Z2018-05-15T12:07:03Zphw_sandSpace, a theme for the Textpattern CMS back-endtag:emps.l-c-n.com,2009-10-01:16aac28d294345a6de82c1a14ba2b582/2029c57e3422464eb6e263637bfde730“Sand space” is a theme for the administrative backend of Textpattern CMS 4.6 and Textpattern 4.7 beta. Delicate shades of grey and touches of pale yellow are used to make the controls as un-intrusive as possible and let the user concentrate to the main task of creating stellar content. This theme is optimized to work on any device from small screen iPod Touch and mobile phones, to iPads, laptops, HiDPI portable computers and large screen desktop computers.

Screenshot:

Textpattern’s Write panel with Sand Space theme (version 4.7).

This theme is compatible with a modern browser, including IE 11, Edge 14, Firefox 52ESR, Safari 10, etc running on devices from iPod Touch to HDPI laptops and desktop computers. It may work on older browsers …

Installation and usage

Unzip and upload to your textpattern/admin-theme folder. Login and select the theme from the Preference panel > Admin sub-tab. You need to reload or switch between panes to see the changes. Alternatively, this theme is fully compatible with Stef Dawson’s smd_admin_themes plugin.

]]>A Textpattern CMS back-end theme in grey and sand colours.]]>Philippe Wittenbergh2016-12-06T05:51:14Z2017-12-22T08:13:59ZUsing SVG files as content images with Textpatterntag:emps.l-c-n.com,2016-12-05:16aac28d294345a6de82c1a14ba2b582/06a2669119d1c4002895a08a5932483cTextpattern of course has no provision so far to upload and manage those SVG files through the image panel. My first thought was to FTP the files to the server, but that is far from ideal (authors wouldn’t be able to do it themselves…), and there is that little issue of managing meta data about those images (caption, alt text,…). That would have to happen very manually, not great at all. In a moment of less insanity (perhaps something with the music I was listening to… thanks Kaja and Susana1) , I then had the idea to use the Files panel. That works, sort of.

In the generated HTML, the PNG file is used in the src attribute, the SVG file is loaded in the srcset attribute. works!

Problems / Issues / Limitations

The file name of the PNG image and the SVG image must match, as it is the only hook I found to connect the two files together – using the <txp:image_info type="name" /> tag. Is there a better way?

If the SVG file goes missing, or if the file name does’t match exactly no image at all is displayed (missing image) in modern browsers.

I use the rah_replace plugin to strip the file-extension from the PNG file (<txp:image_info type="name" /> generates something like name.png) and replace it with an svg extension. An issue I have here is that sometimes author upload jpeg files instead of png. I can find a way to have the from attribute in rah_replace to use either png OR jpg. Is there any other magic trick that can do that substitution ?

Do authors have enough privileges for this workflow? I think yes – I’m mostly concerned about “Staff writer” and “Copy editor”. At least in list view they can see the necessary meta data, even if they didn’t upload the files / images themselves (if they want to reference images used in other articles).

Working around the limitations.

Discussing this in the forums, the ever helpful Jacob suggested a workaround for issue 3, by using a different plugin: pax_grep. In the above code, in the figcaption line, substitute <txp:pax_grep from="/jpe?g/,/png/" to="svg"><txp:image_info type="name" /></txp:pax_grep>.

He further suggested using one of his own plugins, jcr_image_custom, which would resolve the first 3 issues mentioned above. This plugins adds a custom field to the Edit Image panel, allowing to store the ID of the uploaded SVG file together with the meta data for the PNG image. And indeed it does. The modified SVG-image form file looks like this:

Make sure its type is set to File. Added bonus, the same form can be reused, even if the PNG of JPG image does not have a matching SVG image.

Final little snag

Textpattern ships with a disabled.htaccess file in the /files/ folder; it contains a rule to inhibit all direct file downloads. If enabled, it of course prevents the display of the SVG files. It is easy to workaround that: wrap the rule in a <FilesMatch>…</Filesmatch> block, for example: <FilesMatch "\.(pdf|txt|zip)$">.

An example

Below, you should see the image of a green square (the SVG image). Older browsers, sorry IE 11, will see a grey square (the PNG image).

A green square or a grey square? Depending on the browser you might see either one.

]]>Textpattern tip: using SVG images embedded in the content of an article.]]>Philippe Wittenbergh2013-06-01T04:22:36Z2016-04-27T05:47:30ZGoodbye, old friendtag:emps.l-c-n.com,2013-05-31:16aac28d294345a6de82c1a14ba2b582/9e2f95c8c9d81457a78ec58ec3c1113a Camino is no more. The website now only displays a brief message: After a decade-long run, Camino is no longer being developed …

Camino has been my first choice for browsing the web for a very long time. Some time after the release of Firefox 1.0, as I realised that the Mozilla project would never make Firefox a real Mac OS X citizen, the choices were rather limited. There was the early Safari, iCab or Omniweb. For various reasons, Omniweb never fitted in my workflows, neither did iCab. Back then, Safari still had many shortcomings in rendering webpages, and – major sin amongst all sins – it sported a brushed metal UI. Camino it was, then. It was the browser for the “rest of us” (to paraphrase Smokey Ardisson), fast, lightweight, build for OS X from the ground up, with an impressive pédigré – Former Camino developers have helped build … Chrome, Firefox, and Safari. Gradually I got involved in helping out with support requests and debugging, later taking up the challenge of massaging pixels and colours to look pretty on icons and helping to fix myriads of small and bigger issues on the website.

But over the years, due to a dwindling number of contributors (the rise of iOS can partly be blamed for this…) and the increasing complexity of building a web browser, this all-volunteers project had a hard time keeping up with a competition that could rely on a large pool of paid developers. Then came the death knell with the Mozilla project announcing the end of Gecko embedding. Unfortunately, an attempt to use the WebKit rendering engine didn’t pan out.

Volunteering with the Camino community, working with the project leads and all the other contributors has always been a great experience. Even though the development has ended, Camino has succeeded in it’s purposes: from providing a great web browsing experience on Mac OS X when there was very little choice, to putting in motion the development of the many browsers available today. Thank you for this and that.

]]>seasonal greetings, with typography, css transforms and an image.]]>Philippe Wittenbergh2010-12-12T12:06:07Z2016-04-26T08:39:07ZWorkflow for a nearly Flash-less online life with Caminotag:emps.l-c-n.com,2010-12-12:16aac28d294345a6de82c1a14ba2b582/ca1d0976edfcdc5d33b02b98039a5e82Already documented by others from the perspective of a Safari user, it is possible to live a (mostly) Flash free online life. It only takes a few steps to set up. Gand (aka Carlo Gandolfi), member of FreeSMUG, has documented how to handle this when you are a Camino user. He authored a short applescript to ease & automate the process of opening the current Camino page in Chrome, for those few moments when the page really needs Flash to make sense.

As I prefer to use the keyboard for these kind actions, I converted Gand’s script to an Automator workflow which appears in the Services menu on OS X 10.6. This allows me to assign a keyboard shortcut using the Keyboard pane of System preferences (customise how to) – I choose ⌘⌃G (Command-Control G).

Usage:

And that is it; the workflow should appear from the Services menu when you run Camino (you might need to log out before the service is recognized though). You can then assign a keyboard shortcut.

Note(s)

I actually have a more complex workflow than described, as I use both Safari and Google Chrome. Safari is used to view Vimeo and Youtube videos (configured as described by Grubber & Frank linked above). Google Chrome is used for other sites, when Flash is required.

It is easy to add a Chrome icon to the file if desired

In the Finder navigate to Chrome and Get Info (⌘ I), copy the little icon at the top of the File Info window

Navigate to the .workflow file, Get Info again and paste the icon.

]]>Introducing an OS X 10.6 / Automator workflow to open the URL of the active Camino tab in a Google Chrome tab.]]>Philippe Wittenbergh2010-10-18T06:51:41Z2016-04-26T08:39:28ZCSS vendor prefixes and the cascadetag:emps.l-c-n.com,2010-10-17:16aac28d294345a6de82c1a14ba2b582/29cc38b7d26b0598ed909314fee0750bHaving recently seen yet another site by a high profile shop (cognition) [1] making the same mistake, this need to be repeated again and again. When using vendor-prefixed properties together with the non-prefixed property, the cascade matters. Some months ago I noted it in an email to the CSS-Discus mailing list. I’ve probably mentioned it a few times in the past. Roger Johansson noted it recently, others mention it implicitly or explicitly.

But it is worth repeating: when using vendor-prefixed properties (such as -moz-border-radius or -webkit-box-shadow or -o-transform) and the equivalent CSS properties as specified in an official spec, the CSS property should be listed last. This leverages the cascade [2]. Properties are evaluated and applied in order of their appearance in the stylesheet. Putting the official property last in your list ensures that it will be applied by browsers that support it correctly and / or completely.

Both snippets are similar on the surface, but versions of WebKit that support the un-prefixed property will not apply the correct one (border-radius) when the second code snippet is used. Instead -webkit-border-radius is used (note that the -webkit-prefixed property did not support multiple values for the border-radius shorthand and has some other minor differences). Safari 5 and recent Chrome builds support the CSS3 notation, but also support the -vendor-prefixed one (for backwards compatibility reasons, but also because a number of third-party apps or Dashboard widgets may depend on the vendor-prefixed property – WebKit being a core part of OS X is used by other applications). Similarly, Mozilla recently finished implementing support for the non-prefixed box-shadow property. In this case, the computation of the blur radius is slightly different from the prefixed -moz-box-shadow – following feedback on the relevant spec.

When using those vendor-prefixed, experimental properties, authors most certainly want to use the officially specified behaviour if available. There are cases where specifying a non-prefixed property can be detrimental. Currently, the highly experimental CSS gradients come to mind; first implemented by WebKit, it was then implemented by Gecko. This led to serious discussions about the syntax and the draft of a spec; that is certainly not yet set in stone however, and the syntax will likely evolve further in the near future. For vendor-prefixed properties that are part of relatively safe specs (such as the CSS Backgrounds and Borders Module Level 3) including the non-prefixed syntax is a must – for most part, rendering engines already support the official property in their most recent (beta) release. To make vendor-prefixed and official properties co-habit safely, make sure, as an author, to specify the official, non-prefixed property and syntax last and let the CSS cascade do its work.

notes

They are far from the only ones; there are numerous code samples, examples and demos out there making the same mistake. Even PPK does it in his rant against vendor-prefixed properties.

]]>More and more authors make use of CSS 3 vendor prefixed properties. However, a common mistake is to list the official, non-prefixed property first. To work correctly, authors should leverage the CSS cascade and list the official property or syntax last.]]>Philippe Wittenbergh2010-01-11T11:53:54Z2016-04-26T08:40:07ZHelvetica Neue, font-weight:bolder and OS X 10.6 Snow Leopardtag:emps.l-c-n.com,2010-01-11:16aac28d294345a6de82c1a14ba2b582/0e360f3882f0bcee2b5bb43348f65592One of my favourite font stacks that serves optimised fonts for each OS has long included ‘Helvetica Neue’ [1]. It has better metrics than good old Helvetica (and pretty similar to Arial both in terms of aspect–ratio and line-height), it is more optimised for on–screen display, and, as a system font, it is guaranteed available. An additional advantage is that it is available in multiple font-weights for those browsers that support it (that’s currently Gecko and WebKit). Faces available include ‘UltraLight’, Light’, ‘Regular’ and ‘Bold’ — in CSS parlance these translate to font-weight: 100, font-weight: 300, font-weight: 400 and font-weight: 700.

With the release of OS X 10.6, Apple provides one additional face: ‘Medium’, with font-weight: 500. For a web developer (and more so for the end–user of a web page…), this results in a small surprise. When viewing a page that contains <strong> or <b> elements with a Gecko based browser, those elements suddenly look much less dark or fat than they used to on OS X 10.5. This is not unexpected, as the Gecko UA stylesheet (html.css) specifies b, strong {font-weight: bolder;}. The browser looks for a face that is one weight heavier than the previous one and finds the Medium face of Helvetica Neue. Although WebKit’s UA stylesheet contain the same rule, Safari and Chrome do not exhibit the same rendering behaviour.

That is a weird and puzzling bug in WebKit, as it can use the font when specified otherwise. Only font-weight: bolder is affected, and apparently only the Medium faceBoth ‘bolder’ and ‘lighter’ can result in the incorrect face being used, e.g when the computed value should be UltraLight, it is ignored. This seems specific to Helvetica Neue… This test case (or this test case, with screenshot) illustrates the issue. I suspect a little hack that was introduced in bug 6484 to cover up a bug in OS X 10.5 comes back to bite WebKit [2].

Turns out that I was partly wrong; the issue was already documented in bug 18323.

For a stylesheet author the workaround is rather easy, simply redefine the font-weight for the affected elements. Like this:

b, strong {
font-weight: bold;
}

CSS3 Font Module proposal

The situation illustrates a deeper issue, however. In CSS 2.1:15.6 Font boldness: the ‘font-weight’ property, bolder/lighter means: select font weights that are relative to the weight inherited from the parent. This can lead to surprising, unwanted or confusing results when faced with (multiple) nested elements that make use of ‘bolder/lighter’, as summarised by this test case from David Baron. There have been a couple of extended discussions on this subject on the mailing list of the CSS WG (www-style). John Daggett, editor of the CSS3 Font Module came up with a proposal that suggests to replace the bolder / lighter definitions with a simple mapping that’s independent of the font family in use. This proposal has also been included in the editor draft of the CSS Fonts Module Level 3.

In short, with this proposal the issue noted above would simply not exist, the UA would map the font-weight of ‘bolder’ to font-weight: 700; – assuming that is that the computed font-weight of the parent is font-weight: 400;.

Updates

David Baron has now effectively implemented the above proposal in Gecko 2.0b (browsers like Firefox 4). It has also made its way in the CSS3 Fonts Module draft specification, and will soon appear in an updated text of the CSS 2.1 spec as well — see CSS 2.1:15.6 specifically. [added Nov. 29, 2010].

People using Windows builds of Firefox nightly builds who have DirectWrite enabled have mentioned seeing lots of ‘very bold’ text on the web. DirectWrite allows for using multiple weights of fonts on Windows; in this case, the ‘Arial’ font family seems affected, as the system appears to discover an extra bold weight (Arial Black, although not strictly part of the Arial font-family). Bug 550128 has some more details and a test case. Although OS X also ships with Arial Black, it is not affected in this case. [added Nov. 29, 2010].