[css-paint][css-images] Named Hatching Patterns

[Crissov]

Named Fills

• CSS Paint Level 3?
• CSS Color Level 4+
• CSS Images Level 3
• CSS Images Level 4

Solid colors, gradients and custom patterns are nice and all, but in some cases it would be nice to have a named fill that renders as either a solid color (or image or gradient) on a capable screen but as a hatching pattern on a monochrome print-out – without having to specify it manually and without Media Queries. This is of interest where consistent semantics of the fill are more important than the actual looks, e.g. for physical materials in technical drawings or tinctures in heraldry.

Since the fill shorthand in SVG/CSS-Paint gets its valid values from, among others, fill-color and fill-image, which basically use <color> and <image>, respectively, it would be nice if either one of these value types or fill itself would accept some predefined keywords.

Tinctures

Heraldic tinctures traditionally use somewhat French names in English and there are only few and except for rare orange they do not clash with existing CSS color keywords, so they could be used as they are: or (yellow/gold), argent (white/silver), gules (red), azure (blue), vert (green), sable (black), purpure (purple/violet). Today, the Petra Sancta system is widely accepted and followed for hatching (but also extended).

File:Complete Guide to Heraldry Fig036.png

There are also metals, furs and some other materials that have canonical representations in classic European heraldry.

Materials

There are several standards for technical drawings depending on the actual field (i.e. architecture vs. engineering etc.) that define hatching patterns, e.g. ISO 81714-1 section 6.9 and IEC 81714-2 annex H, ISO 128-50 section 5, DIN 201. I really do not know enough about this to recommend anything.

CSS Definitions

fill-color = <color>
fill-image = [ none | <image> ]#
fill = <background>
/**/ = <'fill-color'> || <'fill-image'> […]

image() = image( [ [ <image> | <string> ]? , <color>? ]! )
<image> = <url> | <image()> | <image-set()> | <cross-fade()> | <gradient>

background = <bg-layer># , <final-bg-layer>
<bg-layer> = <bg-image> || <position> [ / <bg-size> ]? || <repeat-style> || <attachment> || <box> || <box>
<final-bg-layer> =  <'background-color'> || <bg-image> || <position> [ / <bg-size> ]? || <repeat-style> || <attachment> || <box> || <box>

[SebastianZ]

For reference, SVG 2 introduced a <hatch> element allowing to define hatch patterns.

Maybe both approached could be merged somehow.

Also, back in 2014 I already came up with the idea of allowing to create custom patterns via an @pattern rule in combination with text decoration and envisioned a broader use for it.

So, maybe the keywords for the Heraldic tinctures may later be defined using the @pattern rule. But I imagine those patterns can also be expressed via Houdini's CSS Painting API.

Sebastian

[fantasai]

Closing as wontfix, as this can be handled by referencing SVG paint servers.

[Crissov]

@fantasai The request was specifically about named, predefined patterns "where consistent semantics of the fill are more important than the actual looks".

[svgeesus]

Agree with closing; too specialized and domain-specific a use case.

Yes, these can be used in technical drawing etc but in those cases, the format (like CGM for example) has a registry of named hatch patterns. In SVG we went with a more web-like approach, no registry, use urls to link to a paint server.

[tabatkins]

In particular, the "no MQs" requirement makes this pretty niche. Why avoid MQs? We don't generally design features specifically to allow you to avoid using other features, unless there's a heavy convenience factor involved.

Here, it's just a matter of setting some variables to colors, and in an @media (monochrome) {...} block, setting them to paint servers for hatching instead. That's quite simple and convenient, and extends to anything else you might want to do (like adjust the colors for low-light or saturated-lighting conditions).

It also lets you use whatever patterns you want, rather than baking some in. Heraldry might have some common color/pattern associations, but there's no particular reason to assume that is a desirable mapping in general for other use-cases.

[Crissov]

Does this mean you would also shoot down an alternative proposal to add named hatching patterns without any reference to a tincture or material?

[astearns]

Probably. I'd prefer to see evidence that a set of hatching names was seeing wide use in a library or preprocessor before considering whether we should bake it in to CSS.

[Crissov]

I meant something generic like

• ▤ horizontal-pattern or horizontal-lines
• ▥ vertical-pattern or vertical-lines
• ▦ square-pattern or cross-hatch
• ▧ ???-diagonal-pattern
• ▨ ???-diagonal-pattern
• ▩ diamond-pattern

[tabatkins]

@astearns' comment still stands - need to see wide usage (or convincing proof that they would take up wide usage were they provided) before adding to the language.