demosthenes.info

A blog by Dudley Storey on , , , , , , and anything else that strikes his fancy.

featured articles

popular favourites

Czech Republic, The Prague Orloj

Changing The PHP Default Timezone

Every installation of PHP makes an assumption about where it is on planet Earth. PHP does not read the location information from the computer it is installed on: that would be the role of JavaScript. Instead, every web server installation defaults to a pre-determined timezone. It is likely that this default won’t match the actual physical location of the server. For example, if you’ve downloaded and installed XAMPP, the server assumes its local timezone is Berlin, Germany.

This can be confusing, especially when using the date() function on a PHP page – date("Y") will obviously provide the right year 99.99% of the time, but date('l’) (a lowercase L, to generate the name of the day) will sometimes be right for your location (when Germany happens to be in the same day) and sometimes not (when Germany is one day ahead of you)*.

While you can look through the php.ini file or phpinfo() to locate the default timezone information, most people will probably find it easier to display it on a PHP page with a temporary line of code:

  1. <?php echo date_default_timezone_get(); ?>

This will provide you with the geographical area that PHP assumes it is located in. Note that this information is provided in the format city/region. If "America" is referred to, it includes the entire continent, from the frozen north of Nunavut to Tierra del Fuego. Also note that the city location references the primary or capital city of the area, and does not recognize inter-city or national rivalries, so (for example) the correct timezone for Alberta is Edmonton, America.

If the timezone displayed on this test page is not correct, you can try editing the server’s php.ini file, but this may not be possible in a hosted web environment. Most people will find it easier to correct the timezone on the PHP page itself, before you calculate a date or time.

For any PHP5 script that needs to reference the exact local time on a server with an incorrect timezone, before you use any date or time functions, write:

  1. <?php date_default_timezone_set('America/Edmonton'); ?>

(php.net has a complete list of PHP timezone values: find the one nearest and most relevant to you, replacing 'America/Edmonton' with the appropriate location).

If you follow this line with echo date_default_timezone_get() you’ll find that the timezone is now correct, as are all calculated dates. You just have to remember to start any page that uses PHP-generated time or date values with this line. It’s not unusual to ensure this by making it part of an include for every page:

  1. <? date_default_timezone_set('America/Edmonton'); ?>
  2. <!DOCTYPE html>
  3. <head>

With this in place, confusing time results in PHP should be a thing of the past.

*this, of course, assumes you are not in Germany

The Way Of Light

Curved Dropshadows With Pure CSS, Method 2

While I indicated that the last Curved Dropshadows With Pure CSS article was the final in the “” series three weeks ago, I realized today that there was one other method for creating the impression of curved shadows under elements.

While this technique uses much the same idea as the previous two examples – relatively positioned pseudo-elements aligned to an absolutely positioned HTML element – it generates the “shadows” via a different method: rather than using the box-shadow property, it creates the appearance of a curved shadow by using a radial gradient under a photograph by Bobby Bong, used with permission.

A brief explanation: the box for each pseudo-element in this example is 170 pixels wide by 18 pixels tall. The radial gradient starts from the bottom right corner of each box (100% from the left, and 100% from the top) as completely transparent (represented by an rgba value), a transparency that continues all the way to 66% of the distance to the opposite corner, where it starts to become visible. The box is pushed down and under the div (we can't place :before and :after on images, as they are replaced elements). The right shadow is simply the same style declaration flipped horizontally using a CSS3 scale transformation.

The entire CSS, for Webkit:

  1. div.curved-shadow { position: relative; }
  2. div.curved-shadow:before, div.curved-shadow:after { content: " ";
  3. width: 170px; height: 18px; position: absolute;
  4. bottom: -14px; left: 20px;
  5. background-image: -webkit-radial-gradient(100% 100%, ellipse farthest-corner,
  6. rgba(0,0,0,0) 0%, rgba(0,0,0,0) 66%, rgba(0, 0, 0, 0.53) 100%);
  7. z-index: -2;  }
  8. div.curved-shadow:after { left: 485px; -webkit-transform: scaleX(-1); }
ScreenQueries

Free Responsive Design Testing Tools

While applications designed to test your web pages under different viewing conditions and devices are growing in popularity, there are times that you simply want to test how your existing site looks at different sizes without firing up some software or fiddling with the lower right-hand corner of the browser window. In that case, the following responsive design testing suites – all free – can be very useful.

responsive.is by Typecast and Chris Armstrong’s RZG have essentially the same idea: enter any site URL and choose from a set of typical device orientations and sizes to see how the sites responds. Both have a neat "cut off" feature to show you where content will stop appearing on the chosen display.

Matt Kersley’s RWD testing tool – also featured at the site of StudioPress – takes a different approach: given a URL, take the page and show it in various states and sizes side-by-side. The ResponsinatorResponsinator, shown to the left, has the same idea, but displays the site within the screen display of several popular devices.

Responsivepx takes a local or remote web site and play with the visible size of an iframe pixel by pixel, which can be useful in determining exact breakpoints for a site.

Screenqueries is the best hybrid approach I’m aware of: not only does it have an array of device profiles, but it uses an editable ruler system familiar to anyone who has used an Adobe product to gauge and limit screen sizes.

While it’s not an online resource per se, ProtoFluidProtoFluid looks very powerful: a single free JavaScript file included in your site allows you to preview any page in the browser to 99 different settings.

There are also simpler and less graphical options, often available as bookmarklets: resizemybrowser.com, Responsive by Victor Coulon, Resizer by William Golden and an editable RWD bookmarklet by Benjamin Keen.

Finally, Chris Pederick is also working responsive layout presets into the next version of the Web Developer toolbar, currently in beta for Firefox.

(Thanks to Snook and the many @ replies to his RWD tool question on Twitter for inspiring this article)

Crafting A Basic Responsive Page

One of the tenents of is that you can now create different layouts for your site depending to how wide the browser is, dynamically changing the appearance of your pages as the browser is resized.

Let’s say we have a site for the fictional company “Ray’s Flowers”. Most pages in the site feature three divs (#col1, #col2, and #col3) presented side-by-side for most desktop screens using display: table-cell

Ray's Flowers, Wide FormatThis design is fluid, so the columns of text become difficult to read when the browser is less than 1000 pixels wide. The changes in appearance between “wider than 1000px” and “less than 1000px” are minimal, so rather than creating a separate style sheet, we could make the new styles part of our main :

  1. body { margin: 0; font-family: Cambria; }
  2. h1 { background: #000; margin-top: 0; }
  3. div#col1, div#col2, div#col3 { display: table-cell; padding: 1em;
  4. padding-top: 0; }
  5. /*
  6. standard CSS rules applicable to everything up to this point
  7. */
  8. @media screen and (max-width: 1000px) {
  9. div#col1, div#col2, div#col3 { display: table-row; }
  10. }

Ray's Flowers, Narrow FormatNow if the browser is more than 1000px wide, the columns display vertically; less than 1000px, they are horizontal.

Returning to handheld devices, you can even switch the presentation of the page based on the orientation of the device (technically, this could also work on desktop monitors that can be rotated upright or horizontal, as this rule is also supported in the latest desktop versions of browsers);

  1. @media screen and (orientation:portrait) {
  2. /* appearance rules effective during vertical orientation of the screen */
  3. }
  4. @media screen and (orientation:landscape) {
  5. /* appearance rules for horizontal orientation of the screen */
  6. }

It should be noted that it is also possible to animate the transition between these @media query states (discussed in an upcoming article), or target page size for printing:

  1. @media print and (width: 210mm) {
  2. /*rules for printing on an A4-size page */
  3. }

Introduction to Responsive Design

“Responsive Design”; is a buzzword that has reached peak popularity: we now have books and entire seminars devoted to the subject. Before starting into the topic here, it would be wise to define it.

Calgary Transit Web Site Redesign on iPhoneResponsive design is perhaps contrasted with what came before it: in the past, sites designed for mobile devices were entirely separate works, often maintained under a .mobi domain name. Due to bandwidth issues and the limitations of devices then in service, mobile sites were often pale shadows of their fully-fledged desktop cousins.

As the capabilities, speed and resolution of mobile devices improved, it became obvious that the browsers that came with them were constrained only by size, interaction mode, and bandwidth; otherwise, they were just as capable as their desktop brethren. Smartphone users began to expect the same experience of a site on their mobile device as when they were at home on their desktop computer, if not an enhanced experience of the site on their smartphones.

In the bad old days of web development, the major sin was “this site only works in x browser”;. Now, the sin is “this site is only usable at y resolution”;.

Responsive design attempts to eliminate the distinction between screens, devices, and resolution: every visitor sees just one site, in different forms that are optimized for their device and experience. This means developers create just one codebase for a site, eliminating duplication and redundancy… and potentially, weeks of extra work.

Developing a responsive design can be tricky, as it is akin to designing three or more pages in one: for every page of your site, you have to make a series of decisions, based on window size, bandwidth, and interaction mode:

  1. What page features are needed for this configuration? How should they be changed? (for example, a long list of options changing into a drop-down menu as the screen narrows, or using geolocation services on a mobile device to suggest a nearby retail location rather than asking for a postal code).

  2. Should the design alter in respect to bandwidth constraints?

  3. Should font and image sizes change for smaller screens?

  4. How should the remaining elements of the page be displayed as a result of these changes?

  5. Given all these decisions, what is the optimum layout for the page?

Responsive design is not one suite of technologies or techniques. media queries play a part, but have limitations as they are currently written. In a fully responsive site @media queries are usually joined by , and server-side languages such as to create a complete solution.

Unless you attend one of my classes, I can"t tell you how a web page should be designed for all devices, orientations and uses. What I will provide here is a series of technical approaches for making any site responsive; it will be up to you to determine how to use the techniques in your endeavors.

The CSS3 resize property

One of the lesser-appreciated properties, resize does exactly what it says: it allows a user to resize almost any element it is applied to. The property itself is something of a misnomer: it does not make content larger or smaller, and is perhaps more akin to a user-modifiable clip property.

resize can take four values, in addition to inherit:

none

The element cannot be resized. This is the default for the majority of elements in most browser’s UA stylesheets.

horizontal

The element may be resized by the user, but only horizontally.

vertical    

The element is restricted to vertical resizing only

both

The element may be resized both horizontally and vertically

resize does not apply to block elements in which overflow has been set to visible, nor is it supported on .

The first example of resize I’ll provide is usually terrible from a UI perspective, but useful in illustrating the property: given a div with some content, we’ll apply resize: both, producing the following:

Try resizing this div element from the bottom right corner. Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

On a more practical level, browsers that currently support resize apply it to textarea by default. While this is a good idea – a user should be able to resize a textarea box to get more room for what they are typing – unrestricted resizing can spoil some page designs. In most cases, it is better to rewrite the rule to restrict resize of the textarea to one direction only:

  1. textarea { resize: vertical; }

To this end, I have added the declaration to my suggested CSS3 reset and boilerplate code.

Validating SVG

As an XML-based language, SVG can be validated just as HTML is. The primary tool for this is the W3C validation service, although others are available. In order to ensure their SVG-infused pages still validate, developers need to be careful in how SVG is added to their code:

SVG Integrated Into HTML5

Perhaps the ideal case, at least in terms of clarity. Simply place your SVG code directly in the body of the HTML5 document:

  1. <!DOCTYPE html>
  2. <head>
  3. <title>SVG</title>
  4. <meta charset=utf-8>
  5. </head>
  6. <body>
  7. <h1>HTML5 SVG Test</h1>
  8. <svg height="200" xmlns="http://www.w3.org/2000/svg">
  9. <circle id="redcircle" cx="50" cy="50" r="50" fill="red" />
  10. </svg>
  11. </body>
  12. </html>

The code above will validate as HTML5, while the SVG will appear as a red circle on the page.

Validating A Standalone SVG Document

The next most common scenario: you have a separate .svg file, with SVG integrated into your web page via CSS or an <img>, <object>, <iframe> or <embed> tag. In that case, the DOCTYPE for the SVG page should be:

  1. <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
  2. "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
  3. <!-- SVG code proceeds from this point -->
  4. <svg … >
  5. </svg>

An XML prolog is optional for the SVG file, but it’s a good idea to include one; doing so allows us to declare a character encoding:

  1. <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  2. <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
  3. "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
  4. <!-- SVG code proceeds from this point -->
  5. <svg … >
  6. </svg>

Feeding a SVG document formatted in this manner to the W3C Markup Validation service will result in a valid page, assuming that SVG code has been used correctly.

There is a rather technical argument for dropping the DOCTYPE in SVG documents. If you do so, the namespace should be declared in the <svg> element itself. The SVG document would then start with the following:

  1. <svg version="1.1" baseProfile="full"
  2.      xmlns="http://www.w3.org/2000/svg"
  3.      xmlns:xlink="http://www.w3.org/1999/xlink"
  4.      xmlns:ev="http://www.w3.org/2001/xml-events">

The one downside to this last approach is that the SVG document will no longer validate as SVG, but as XML. This isn’t wrong, but it’s possibly less useful.

Validating An XHTML Page With Integrated SVG

Things get a lot trickier if you’ve placed SVG code directly in an XHTML page. I’ve been stymied in my experiments: it appears you can put SVG on an XHTML page and have it appear in the browser, but have the W3C claim it is invalid, or craft XML namespaces for the SVG in your code: making the page valid, but preventing the SVG from appearing correctly in the browser (at least in the versions of Firefox and Chrome I’ve tested). For right now, I would recommend integrating SVG into an XHTML page as an image, avoiding the problem entirely… but I shall return to this vexing issue soon.

web developer guide

featured comment

by JoelB in Goodbye, JQuery Validation: HTML5 Form Errors With CSS3

what i'm reading

A Storm of Swords: A Song of Ice and Fire: Book Three
A Storm of Swords: A Song of Ice and Fire: Book Three

what i'm watching

Californication: The Third Season
Californication: The Third Season

what i'm playing

Mass Effect 3 Collector's Edition
Mass Effect 3 Collector's Edition

what i'm hearing

Dub FX
Dub FX

blogs

podcasts

no ads ever

This blog is free of advertising, and always will be.

creative commons licensed

The content of this blog is free to use in whatever way you wish under the Creative Commons license.