Hand-crafted logo letters

[mxdvl]

Why are we doing this?

By carefully creating the paths for the CSS letters in the logo, we:

• get aligned caps, like @chriskirknielsen’s version
• remove the need for contributor to acquire expensive design software
• stop relying on external fonts
• ensure the SVG has an accessible title
• achieve minimal file size out-of-the box
• can create stylistic variants programatically
• use the platform!

This comes at the cost of better understanding of the SVG internals, which is mitigated by:

• the excellent MDN documentation for d
• detailed visual explanation of the functions used
• an interactive version to play with parameter values

What does this change?

• Adds a script used to draw the CSS logo as an SVG
• Document what each parameter for drawing each shape
• Adjust the parameters so the logo is visually satisfactory
• Handle both variants
• Link to a playground for contributors to adjust

---

Closes #35
Closes #27
Closes #14
Closes #31

[rol4nd909]

It's awesome how this works but as been said in #13

"I think it would be unfortunate if we need JavaScript to render a logo for CSS"

[mxdvl]

"I think it would be unfortunate if we need JavaScript to render a logo for CSS"

The logo will be entirely static – the JS is only doing the work that is currently done by Figma, which is generating the lines in a reproducible manner.

[rol4nd909]

Ah fair point never mind then ;)

[rol4nd909]

Is there I reason that you changed the size of 1000x1000 to 240x240? And I really think you should try to add the <title id="title"> and <desc id="description"> and the role="img" aria-labelledby="title description" and fields should be editable.

see this example:

<svg xmlns="http://www.w3.org/2000/svg" width="1000" height="1000" viewBox="0 0 1000 1000" role="img" aria-labelledby="css-dark-title css-dark-description">
  <title id="css-dark-title">CSS Logo Dark</title>
  <desc id="css-dark-description">A black square with rounded corners and the letters CSS inside in white</desc>
  <path d="M0 0h840c88 0 160 72 160 160v680c0 88-72 160-160 160H160C72 1000 0 928 0 840V0Z"/>
  <path fill="#fff" d="M816 920c-69 0-99-44-101-112h70c0 32 11 49 33 49 11 0 18-3 23-10 8-13 10-49-2-63-13-16-38-24-55-33-48-23-65-48-65-102-1-138 202-138 196 7h-67c1-11-2-24-7-34-3-8-11-12-22-12-19 0-29 12-29 35-1 24 13 38 32 45 30 12 67 31 80 54 41 71 12 181-86 176Zm-224 0c-69 0-100-42-101-112h69c1 34 12 49 33 49 11 0 19-3 23-10 9-13 10-49-2-63-12-16-37-24-55-33-47-23-64-48-65-102-1-139 204-137 197 7h-67c0-11-2-24-7-34-4-8-11-12-22-12-20 0-30 12-30 35-1 24 13 38 33 45 29 12 66 31 80 54 40 71 12 181-86 176Zm-234 0c-64 0-104-36-103-102V650c0-33 10-59 29-76 71-56 187-25 181 82h-74c0-19-4-32-18-40-13-6-32-1-38 10-5 12-7 24-6 37v145c0 30 10 46 32 46 10 0 17-3 22-11 7-10 9-22 8-35h74c4 67-42 114-107 112Z"/>
</svg>

[romainmenke]

I kinda get this change but I also wonder if it will make it harder to approach the logo from a designer perspective.

Having Figma as a source of truth is a good thing I think.

[itsjavi]

I appreciate all this work but I think it will make it harder to maintain and to make design changes. I agree with @romainmenke here.

Also one of the original requests for a new CSS logo was that it is easily reproducible in HTML/CSS only. Modifying the font curves implies we can no longer use an external font, therefore we can only use SVG in the HTML/CSS version.

I still think we should have a master css.svg file as the source of truth, and just use JS to create the other ones (square, black, white) changing fills like I said in #31

[mxdvl]

Absolutely understand if this is not a desirable change. Having felt firsthand as a designer the stronghold of proprietary software being used to generate assets I try to offer alternatives especially if they can be of public benefit. Feel free to close this PR or react with a 👎 if it is not a step in the right direction for the CSS logo.

I doubt you'll find a way to consistently create accessible SVG files from Figma, Illustrator or even Inkscape, but I would also love to be proved wrong so if you find an elegant solution to this conenendrum please share it here so I can get notified 🙇

[romainmenke]

I doubt you'll find a way to consistently create accessible SVG files from Figma, Illustrator or even Inkscape, but I would also love to be proved wrong so if you find an elegant solution to this conenendrum please share it here so I can get notified

Maybe this is something that can be done with post processing with something like post-html?

[itsjavi]

Figma export was done only once, and further changes can be done in any software supporting SVG. After the changes and exporting the file we can use tools like SVGOMG and then add the missing A11Y data to the XML.

I don't think we will need to change it often after we solve the font problems.

Also, having a single SVG file as source of truth (and the rest generated from it) it helps with the maintenance.

After all your effort, I'd rather wait to see what other contributors think before closing this PR or not

Voting the original post can help

[mxdvl]

@rol4nd909

Is there I reason that you changed the size of 1000x1000 to 240x240?

I initially thought 240 was a more easily divisible number, but for the sake of consistency I’ve kept it as 1000 × 1000 in 7487d07

I really think you should try to add the <title id="title"> and <desc id="description"> and the role="img" aria-labelledby="title description" and fields should be editable.

Agreed, added in efc7c30 & 9f38efc3

---

@itsjavi

I appreciate all this work but I think it will make it harder to maintain and to make design changes

Is this assessment based on having tried the interactive version? Would it help if that version had interactive bezier handles to enable manually modifying the control points?

I don't think we will need to change it often after we solve the font problems.

Agreed – this proposal being one approach that leads to solving the font problem, while also addressing some design issues raised in #14.

After all your effort, I'd rather wait to see what other contributors think before closing this PR or not

I’ve enjoyed doing this and do not consider it to be a waste of my time even if it ends up being rejected.

[argyleink]

Lovely thread y'all, so nice to see healthy contributors and community working together towards a healthy repo ❤️

I agree with Javi and Roland here

Figma export was done only once, and further changes can be done in any software supporting SVG. After the changes and exporting the file we can use tools like SVGOMG and then add the missing A11Y data to the XML.

I don't think we will need to change it often after we solve the font problems.

The SVG file, one that people can read and reason with, while it's not the DRYest solution out there, it does strike the healthy balance if approachability and maintainability.

This work @mxdvl is very coo, and I bet (i'd also read and share it) you could write a super fun blog post on what you did and share it for anyone else that wants to learn from it or use the output you create from it. That way the great work can continue to live on.

I'm going to close this for now, as the community group discussed this today and decided to continue maintaining the sources as SVG. Thanks again for the kind contributor dialog and sharing this super cool work with us.

[mxdvl]

Thank you for the feedback, I’ll definitely write about it, as this is not the first time I’ve proposed hand-crafted logo.

decided to continue maintaining the sources as SVG

Would this mean that you’d consider a PR that uses the output of this function directly to the SVG files, similar to mxdvl#1?

<svg xmlns="http://www.w3.org/2000/svg" width="1000" height="1000" viewBox="0 0 1000 1000" fill="none" role="img" aria-labelledby="css-title css-description">
  <title id="css-dark-title">CSS Logo</title>
  <desc id="css-dark-description">A purple square with rounded corners and the letters CSS inside in white</desc>
  <path d="M0,0H840A 160 160 0 0 1 1000 160V840A 160 160 0 0 1 840 1000H160A 160 160 0 0 1 0 840Z" fill="rebeccapurple"></path>
  <g class="CSS" stroke-width="72" stroke="white" transform="translate(820 730)">
    <path class="C" transform="translate(-470 0)" d="M 65,-75C 65,-107 54,-155 0,-155C -54,-155 -65,-107 -65,-75L -65,75C -65,107 -54,155 0,155C 54,155 65,107 65,75"></path>
    <path class="S" transform="translate(-235 0)" d="M 65,-75C 65,-107 54,-155 0,-155C -54,-155 -65,-107 -65,-75C -65,19 65,-19 65,75C 65,107 54,155 0,155C -54,155 -65,107 -65,75"></path>
    <path class="S" transform="translate(-0 0)" d="M 65,-75C 65,-107 54,-155 0,-155C -54,-155 -65,-107 -65,-75C -65,19 65,-19 65,75C 65,107 54,155 0,155C -54,155 -65,107 -65,75"></path>
  </g>
</svg>

I’m only asking as your comments make no mention of visual fidelity and wanted to make sure that it was understood that I would still consider the SVG as the source of truth :)

[itsjavi]

Tbh, I prefer the current one because it uses curves instead of strokes for the text (some tools to create fonts out of SVGs require converting/expanding strokes to curves), and arcs instead of bezier curves (#29) which are more precise. SVG transforms also seem to have partial browser support currently.

What I like is that the paths for the text are more compact. Is there a way to do the same with expanded stroke, as only curves?

Also, it might be some missing fill and the view box, but this is what I see when opening it on Affinity Designer 2:

[mxdvl]

Tbh, I prefer the current one because it uses curves instead of strokes for the text (some tools to create fonts out of SVGs require converting/expanding strokes to curves),

Fair!

and arcs instead of bezier curves (#29) which are more precise.

This one does too, see the A being used in the first path, here expanded out:

 M 0,0
 H 840
 A 160 160 0 0 1 1000 160
 V 840
 A 160 160 0 0 1 840 1000
 H 160
 A 160 160 0 0 1 0 840Z

SVG transforms also seem to have partial browser support currently.

Not really, transform is supported by every browser since Dec 2010. The transform attribute of SVG element is not the same thing as the transform CSS property.

What I like is that the paths for the text are more compact. Is there a way to do the same with expanded stroke, as only curves?

I doubt it, as you’ll need to trace the “inner” and “outer” lines of the SVG, so you’ll end up with something close to the current version even if you nudge the paths ever so slightly. The whole point of this proposal is to use strokes instead of fills 😁

Also, it might be some missing fill and the view box, but this is what I see when opening it on Affinity Designer 2:

I’ve updated my post above to include an explicit height & width attribute, which should help!

[itsjavi]

thank you @mxdvl ! I am learning a lot about SVG syntax thanks to you.

I wouldn't mind using strokes very much (at the end you can just expand them in vector tools), but the only problem I see is that the design varies from the original font, making it complex for designers to use "the CSS font" for other purposes (e.g. banners, etc). Looks very similar though.

Screen.Recording.2024-11-19.at.21.17.19.mov