✅ Deploy Preview for unocss ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	feed371
🔍 Latest deploy log	https://app.netlify.com/sites/unocss/deploys/66ecdde24914740008926d4d
😎 Deploy Preview	https://deploy-preview-4149--unocss.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

We keep the lowercase syntax in all regular expressions by default, and why don't you use lowercase syntax anymore?

The capitalized syntax is weird when connected after - and it doesn't follow the camelCase naming convention. The lowercase icon name is consistent with iconify.

I don't think so. First of all, the DOM's className supports uppercase characters, so there should be the freedom to use uppercase characters. Secondly, for some technical terms, uppercase characters are necessary, such as ECS, IBM, KFC, Apple, which makes it more intuitive. Thirdly, the SVG materials provided by designers also use uppercase characters, and to maintain consistency, the icons need to use uppercase characters as well.

Isn't it a better choice to gain greater freedom with just a little change?
@zyyv

“We keep the lowercase syntax in all regular expressions by default”
You can encourage such behavior, but there's no need to restrict it to only such behavior. For example, when browsing the Rust standard library, the style there is not at all in line with JavaScript conventions, yet Rust is still a successful language.

Isn't it a better choice to gain greater freedom with just a little change? @zyyv

@shenjunjian I actually don't want to see any breakthroughs in this area, as it would create an update burden, such as flex --> Flex etc... which makes UnoCSS more likely to be extracted, resulting in some invalid utilities.

We get icons from iconify, and I think we should follow the upstream naming conventions.

Hi! I'm autofix.ci, a bot that automatically fixes trivial issues such as code formatting in pull requests.

I would like to apply some automated changes to this pull request, but it looks like I don't have the necessary permissions to do so. To get this pull request into a mergeable state, please do one of the following two things:

1. Allow edits by maintainers for your pull request, and then re-trigger CI (for example by pushing a new commit).
2. Manually fix the issues identified for your pull request (see the GitHub Actions output for details on what I would like to change).

Open in Stackblitz

commit: feed371