creating polygon shapes

… the easy way.

Tools to draw polygons exist, but I prefer to carve out and tune those shapes where they belong – inside my regular layout, with all other relevant and irrelevant styles applied. Less chance for line-up failures that way.

First I form the actual shapes, surrounded by dummy content in the form of a dot raster.

Images go here…

Partial screenshot provided for those who cannot see the live line-up…
The image used is found elsewhere, where it has been retrofitted with the shapes shown here.
Polygon styles are found in the page head.

The font-size for the dot raster is 16px and the line-height is only 0.3vw, and text-justify is used. This tight raster provides clear content-edges next to the created shapes.

The floating picture is pulled over the edge of the container by its right margin in %, causing it to reposition itself horizontally to make the most out of available window width. It also gets resized by max-width to fit in on narrow windows.
The polygon shape is declared in %, and follows the image itself during resizing. Applied margins can cause problems with line-up variations in responsive layouts, and the same goes for relative offsets.
I have made slight modification to shape-margin to make line-up adjust to changes in overall styling when the one-column design kicks in on very narrow windows / screens.

reality check

Next step is to test with regularly styled text on the page.

Images go here…

Screenshot of left float with text line-up…
Polygon shapes are styled pretty tight on the image, but as line-height controls how paragraph lines butt up against the more horizontal polygon shapes, the text will naturally keep its distance along the slope declared for upper part of this image.

Proper testing with text in the flow, makes it a lot clearer what can work and what won't work, than a raster or polygon-lines do.
For instance: the dummy-text above is left-aligned, which makes line-up against the polygon shapes on right-floating image more “accidental” and jagged – same as for real text in a page. Justifying the text does not always help much on the overall line-up.

early days for shapes

Both standards and support for shapes are at an early stage, but shapes can nevertheless provide some welcome progressive enhancement in supporting browsers.

Testing new features at an early stage, is of course important. I have already discovered that current implementations of shapes are restricting, and in some cases break, normal content-flow in unexpected ways. These apparent bugs1 are worth some real-world investigations.

As usual I have tailored some simple tools to help in manual shaping and testing of shapes and whatever other features I might like to include on web sites. Armed with these tools I can easily sort out what works and what doesn't work where, and separate browser bugs from my very own designer bugs2 in the process.

Why I prefer this direct approach over existing tools and solutions to the creation of shapes, has to do with the simple fact that I have been “carving out” web sites for a long time4, and have usually found the simplest and most “locally invented” solutions to work best and cover most cases in the long run.

Tiptoe'ing around potentially problematic areas in web design, has never been my style, and I see no reason to change my approach now. Browser vendors will keep on talking and writing about how fast and powerful their products are in certain areas, and they are more than welcome to do so.
I am more into revealing the same browsers' weaknesses by challenging them in every area that is of any interest to me, with the goal of making browsers work, for me. All in the name of progress…

sincerely georg; sign

Hageland 14.sep.2016
last rev: 19.jan.2021

side notes.

feature support.

At the time of writing, support isn't all that great.
– Chrome and Opera support shapes on floats. – Safari support shapes with prefixes3. – Firefox and MS Edge have shapes “under consideration”.
No browser shows complete and flawless support as of now.

(update 19.jan.2021) Four years later we see the expected improvements in support for shapes. I have noticed that there (still) are some minor differences in handling of shapes between browsers on the Chromium and those on the Gecko engines, but these differences cause no real problems.

As lack of support for shapes in a browser does not in itself lead to any failures – square elements remain square, shapes can be used anywhere as long as the final rendering is not made dependent on support.

I do not use polyfills or hack browsers5 to create “the same experience” across browser-land. What browsers don't support they don't support, and that's it as far as I'm concerned.

considerations.

Styles for shapes used on single pages, are best placed in the page head style block. Alternatively generate these styles on-the-fly with the page. Site-wide stylesheets will soon get oversized if they have to carry lots of code used only once on a single page, and a polygon shapes declaration will only go with one image.

Additional styling like margin, padding, border, relative offsets etc., on the floating elements shapes are applied to, will of course affect line-up around those elements. The line-height on surrounding text-carrying elements does of course also affect line-up.
I recommend re-check of line-up with complete styling applied to the individual element and its surroundings, once it is placed on the actual page.

examples.

Above is what it might look like on a narrow window, with justify declared on the flowing text. Not too bad in this example, but varying word-length will affect line-up and create more ugly white “rivers” down the text area on some window widths.
Tests like this tell me that justify doesn't work well in such cases. Manual hyphenation may be the solution in some cases, but isn't always an option.

I use techniques like on this page to prepare shapes directly in their intended environments, with styles in the page-head. That way I can make sure these shapes work reasonable well in the fluid / responsive layout used on this site.

The “dot raster” and “dummy text” used here, is generated content6 that resides in a stylesheet that I link to while I'm working on defining shapes of any kind in a page, or when I simply need to debug some tricky line-ups. No need to carry all that dummy-stuff along with regular pages once they are debugged.

additional notes

1 A “browser bug” can be classified as a real bug when a browser's implementation of a feature deviates from definitions in standards in such ways that a property / value or combinations of properties / values results in serious deviations from how the majority of browsers handle the exact same code.

Remember: Individual features become recommended parts of standards only when two or more browsers have released reasonable identical and flawless implementations of them. Until then they are just work in progress.

2 A “designer bug” is a coding flaw or mistake of any kind that creates problems in a web design, introduced in or via HTML, CSS or script.

Note to self: “Designer bugs” are far more frequent than all bugs and flaws found in major browsers put together. I should know…

3 As a general rule I do not apply CSS prefixes for browsers that do not support the unprefixed and standardized forms of CSS features. A few well-formed exceptions can be found in site-wide stylesheets, where I ran out of options.

Note: CSS prefixed features are fine for early testing, and not much else. Prefixes are however being used for “necessary” and permanent styling on sites, which is something they were not intended for.
This misuse of “feature tests” is probably why most browsers are dropping most prefixes and have switched to the use of “internal flags” to turn features on/off.

4 I started designing with CSS in year 2002, after a brief dip into table based design a few years earlier.
What was a job once, is now pretty much just a hobby that pays for itself.

5 Yes, I do hack individual browsers in rare cases, if they are too far off from base-line. I do not hack individual browser versions … unless the version in question is obsolete and the hack is safe so it can not come back to haunt me later. Hacking is otherwise something I play with where it does no harm.
As a rule I prefer to ignore old and obsolete browser versions, as there is absolutely no need for them in the wild anymore, and their very existence hamper progress.

6 Generated content introduced via ::before and ::after, can be quite useful. Not only can it be used for decorative purposes – to add loads of images for instance, but also to add large amounts of visual content – like I have done on this page.
Visual population of entire pages can be done this way, although I do have to recommend against such a practice.

Caution: Use of generated content is not without its potential pitfalls, as one can not be certain that the visual content remains purely visual and will not be read out by screenreaders and Assistive Technology (AT) software.
What some screenreader/AT combinations read out and others don't, seems to depend very much on what elements the generated content is attached to. Generated content attached to non-text carrying elements – outer containers, seem to be left alone by all screen readers.