UnluckyNinja

@wednesdayco #105
1. 如果你有在用 vite ，对于 vue 就像#103 所说的用 vite-plugin-vue-inspector/unplugin-vue-inspector （这俩是同一个），如果是 react 可以用 https://github.com/hunghg255/vite-plugin-reactjs-inspector ，svelte https://github.com/sveltejs/vite-plugin-svelte/tree/main/packages/vite-plugin-svelte-inspector ，以此类推。

如果你没有用 vite ，但是有用 vue/react 等，可以用相关 devtools 查看组件树，然后用定位功能定位组件，相比上面的方法，多了几次交互，精度到文件。

如果你没有用 ui 框架，但你页面内容和文件组织结构比较相似，那按目录直接找应该不是太大问题。如果文件很乱，还看不出单独组件，或者你觉得麻烦，那估计只能是搜类了。就像你用 scss 时搜单个类，tailwind 你可以直接搜整个 class 属性，本地 vscode 检索很快的，记得把 node_modules 等目录排除。

2. 生僻感觉大致分两种情况，

第一种你不知道想要的样式需要什么类名/属性，这种可以直接去 tailwind 上搜索关键词就行了，如果 tailwind 不能满足再去 mdn ，例如自定义的 grid 排列方式，这种我知道 tailwind 没有，也就知道该去哪查文档了。

第二种你不知道 tailwind 类名如何影响元素（这种装了 vscode 插件可以直接悬浮显示 css 属性，或者直接去浏览器看元素样式也不是不行），也是先去 tailwind 看属性看效果样例，如果不了解属性值/没有例子，才是去 mdn 查属性值。

一般都是先查 tailwind 再查 mdn ，等大致了解了 tailwind 能做什么不能做什么，也就不用跑两边了。

3. 关于 hot reload ，最差情况是你需要刷新网页来刷新状态，但多数情况 vite 及 ui 插框架件已经帮你处理好了，很少会遇到不能用的情况。不过和查找元素的一样，不是决定用不用 tailwind 的因素，其本身就是对前端开发体验的极大增强。

总而言之，能直接用 utility class 省事太多了，个人习惯是可以适应和改变的，但 utility class 减少的工作量是实打实的，所以才会流行。

cf worker+自定义域名，反代套个壳试试

> 看着满屏的样式写在 html 上就头疼
对于重复的、长的 class 属性，你完全可以抽离出来放到 css 类里并使用 apply ，就如同#51 Pipecraft 截图那样，或者放到 js 里作为字符串，对于 vue 单文件组件或者 jsx 来说就是前后脚的事。
此外，utility class 与 css 不是互斥的，只是 css 的特化，如果你不喜欢它写出来的样子，你完全可以很方便地转换成更原始的方式，例如用各种 tailwind to css 工具或者 unocss 的 compile mode 转换成 css 。
不过很少人这么做，因为 tailwind 的主要优点之一就是非常适合快速原型开发，后面我举个例子你就懂了。

> 点开 devtools element 想找个节点都难找
我将工具方式写在 #103 了，不过一般用这个工具是因为定位元素源码本身就是一个独立需求，而不是受用不用 utility class 影响。（以及以防你说的是在 devtools 自身面板里找不到对应元素，不是定位元素点一下就找到了嘛，除非你嵌套了 N 层元素还不加间距。）
此外用 tailwind 都是直接在源码上修改并看效果的，很少会去 devtools 里看元素，一般都是因为 UI 组件库增加了额外嵌套元素导致 flex grid 等失效需要 debug ，或者不熟悉的属性快速尝试所有可能选项时才会检视元素，所以不太清楚为什么这一点成为了阻止你使用 utility class 的原因。

> 生僻一点的样式就还得去翻下文档
熟悉了就好了，很少会用到的是要查，但生僻的 css 属性不也是该查还得查，不知道你在哪里查 css 属性，但至少和 MDN 比，tailwind 的文档还是更好查的。

我举一个极端的例子，假设一个父元素 div 有 4 个子元素 div 。
然后按照以下步骤修改：
1. 父元素 grid 布局分 10 列，子元素分别占 2 、2 、3 、3 列，
2. 对于子元素，占 2 列和占 3 列的，把各自其中一个元素设置为背景绿色，另一个元素背景红色。
3. 对占 2 列的绿色背景元素，设置鼠标悬浮时背景变为白色，红色背景的悬浮时变为黑色。占 3 列的反过来。
4. 给占 3 列绿色背景的元素添加边框。
5. 删除红色背景元素的悬浮样式。
6. 删除占 2 列的元素并剔除无效样式。
过程上：
- 如果是 utility class ，我所有的更改都在对应元素上完成，批量修改时基本上用一下垂直选择或者 ctrl+D 即可，不用考虑给类起名，不用考虑拆分选择器，不用担心变更样式时会影响到外部元素，只需要在当前行查找对应类名并修改，不用考虑类的前后/层级作用关系以及选择器优先级。
- 如果是原生 css 或各种预处理器，假设你还想尽可能地降低重复内容，你每一步可能都要考虑如何写类/选择器，各自包含哪些属性，在修改时你可能需要在 html 和 css 中反复检索来避免影响到其它元素，在这个过程中你可能要起很多次类名/选择器才能适配每一个变化
结果上：
- utility class 没有样式文件，就是类列表可能比较长。
- 原生 css/预处理器，最后对 css 代码精简，最直观的结果可能有两种：
1. 每个元素对应一个类，类名失去复用性，每个类都包含很多属性，
2. 每个选择器只包含一个属性，需要对应属性的元素复用相应的选择器。
前者相当于 apply 写法，但要赘余很多。
后者就是 utility class 。

@wednesdayco #102
tailwind 流行的原因还有一点就是恰逢前端组件框架兴起，组件框架发展同时迭代了工具链。
就比如 vue ，安装 vite-plugin-vue-inspector 插件（如果用的 Nuxt ，内置 Devtools 自带），使用定位元素功能可以直接在 vscode 中跳转到对应源码位置。
不过用 utility class 时，元素的 class 本身就很少会很相似，比如开头单词、整体长短等，比较容易对应上。

@UnluckyNinja #4 也怪谷歌给 auth 更新改了运作方式，突然离线不显示绑定的密保了，联网成功才显示。第一次打开新版给我吓坏了，否则我不能想着去看看备份/迁移什么样导致误操作

前不久不小心误操作把谷歌 auth 清空了（谷歌那个验证器你点了迁移，绑定多的话会依次显示好几个二维码，右下角按钮是“下一步”“下一步”“确定”，然后确定那里是个选项，问是否移除当前全部绑定，默认是“是”……我只是想看看迁移什么样按快了直接全清空了）
然后就正常解绑重绑，可以用恢复码，也可以用手机上的 github app 验证，方式其实挺多的，印象中十年前绑定时提示是 2FA 丢失就无法找回帐号了，还好虚惊一场

之前遇到个强制中文的问题，即中文版美式键盘就是会在 uwp 和 win 系统 ui 下输入中文，感觉微软认为这是 feature 不是 bug 所以不给关。微软拼音这个也是积重难返。
于是就换成英文美式键盘+小狼毫了，至少这么多年相安无事

尽可能简单那就是 codepen/jsfiddle 嵌入，最简单最省事。

css 图标没加载出来时就这样，检查你的代理规则，switchomega 或者 f12 看一下就知道了