其实很简单，代码补全，错误提示，自动编译、压缩，代码缩进（格式化）及保留适当的空行。
代码补全基本已经是现代编辑器必备的基本功能了。另外，快速的写代码，还需要emmet来实现。
自动编辑、压缩，这个基本靠构建工具实现，各种打包软件。
SCSS+Compass是最佳组合之一。
关于错误提示，这个就是纯粹的编辑器内置功能了。
圈内人大概都知道webstorm。
代码缩进，代码格式化，这个非常非常非常重要。
5.0?
考虑了很久，还是决定，不破坏4.0的结构，不做大范围的更正，还是以bootstrap 4为框架依赖，针对bs4去删减多余的样式定义。
然后，新增一个5.0版本，彻底移除bootstrap框架。
css-framework 4.0大概要放弃bootstrap了
今天才开始在bootstrap4.0的基础上做一个demo文档，class命名重叠倒是其次，关键，bootstrap里面给了很多的权重（!important），这就导致我自己定义的class属性被覆盖，不得已，唯有考虑放弃bootstrap框架作为依赖。
对于一些常用的bootstrap组件，我也考虑过单独提取出来，但是，总觉得有所欠缺，不够完美，不如放弃算了。
另外使用其他的插件去替代对应的需求。
简述css的vertical-align属性
直译，就是垂直居中。
通常，应用于行内元素，图片、文字、图标等。vertical-align属性，我的理解就是相对于某个元素对比而言的。
w3c有一段相关信息如下：
| Value: | baseline | sub | super | top | text-top | middle | bottom | text-bottom | <percentage> | <length> | inherit |
| Initial: | baseline |
| Applies to: | inline-level and ‘table-cell’ elements |
| Inherited: | no |
| Percentages: | refer to the ‘line-height’ of the element itself |
| Media: | visual |
| Computed value: | for <percentage> and <length> the absolute length, otherwise as specified |
可应用范围可以理解为，在行内和表格内的元素。
图片，按钮，文字和单元格 都可以使用vertical-align属性。
动了念头，想自己去画图标了……
一直以来用的font-awesome的免费图标库，虽然是足够用了，但是，想自己做一套的图标库的野心也是存在的。
起码，AI(Adobe Illustrator)软件还是会用的，sketch也行，总是觉得该试试了，今天偶然看到一个国人设计师自己实现的一套图标库，有些触动了，更想自己去试试。关键是，常用图标几乎都大同小异，创新很难，雷同甚至完全一样都很有可能，所以，就更想试试，起码，起初临摹是可以的，先熟练画图标的技巧。
其实，大概的流程是了解的。通过阿里的iconfont平台，可以上传svg文件生成iconfont，实现图标字体化。
好吧，暂时算是立下个flag，抽时间试着画一个先。
css中的!important及版本迭代的前因后果
css的!important该如何使用，何时使用，坦白说，时至今日，我也没有很深刻的认识，这个提升css属性权重的写法，在关键时候很有用，不过，需要明白的是，这个权重的提升，事实上是覆盖了其他的同名写法，提升了权限；往往，你需要提权的地方，可能只是一个唯一的，或者临时需要用到的地方。
所以，要慎重使用。
在2.0版本的框架中，我肆无忌惮的使用了!important，只是为了某些情况下的偷懒。
在2.0版本的实践中，我发现了严重的问题，往往因为这些大范围的提权的写法，导致各种场景的冲突，这说明了，css的写法及应用范围，前后排序存在严重的逻辑问题。
总的来说，3.0版本的诞生，除了优化class命名，更多的，还是修正!important的滥用。
很好，3.0版本在实践中，逐步完善了很多细节，完全可以投入到生产环境中了。虽然修正或者修改了前版的class命名冗长的问题，但，还是觉得不够简洁。再加上，忽略了flex布局，于是，决定衍生4.0版本。
4.0版本，目前处于进行时态，对于!important的使用，暂时是少于3.0版本。至少，证明了我这套css框架已经趋于成熟了。
最后，总结一下，关于!important，并非是完全不用，只是，尽可能的避免使用，一旦使用了，要保证用法的唯一性，独立性。至少不会影响后期维护。
4.0版本完善之后的计划……
在4.0框架逐步完善之后，计划之一，就是css的scss转化。
或者，可以考虑less？
另外，可能的话，还是要规划一个网站，专门把这套框架细分一下，写一个使用指南。如同大部分的框架一样，需要给这套框架一个名份，不能就这么默默无闻。
虽然一直是个人使用的框架，但还是希望能有更多人的参与进来，提供帮助，斧正错误，完善细节。
新增CSS Grid 布局
对我而言，这是个新鲜的东西，简单看了一下，很有必要在4.0版本中新增一条。
那么，grid布局和我预设的class名称grid有冲突，这个命名，在4.0版本将要改名了。
关于Python缩进和冒号
刚开始学习Python，找了一段九九乘法表的代码，自己敲出来后，发现输出结果跟示例截然不同，而代码又完全一样，没有错误。
仔细观察发现，缩进不一样，然后就查了一下Python的缩进和冒号，原来，对于Python而言，代码缩进是一种语法，Python没有像其他语言一样采用{}或者begin…end分隔代码块，而是采用代码缩进和冒号来区分代码之间的层次。
缩进的空格数量是可变的，但是所有代码块语句必须包含相同的缩进空格数量，这个必须严格执行。
hostease主机，绑定SSL后，关于自动跳转https的一些事……
hostease的附加域只能在public_html的目录下创建，即，只能在主域名的根目录下创建附加域的目录。
接下来的问题是，主域名绑定了ssl，要http自动跳转https，就需要在根目录的.htaccess添加如下：
RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R,L]这样是没啥问题了，但是，这样的重定向，是针对整个目录而言的，即，根目录下，所有子目录都会跳转到以主域名为前缀的路径。所以，对于附加域，这是完全不能接受的。
例如主域名是www.aaa.com在根目录，附加域是www.bbb.com，在根目录下ccc文件夹。
输入附加域，自动变成www.aaa.com/ccc/www.bbb.com
解决方案如下，在根目录下的.htaccess添加以下内容：
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://www.sanseistone.com/$1 [L,R=301]
</IfModule>然后在附加域的目录下的.htaccess添加以下内容：
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.html$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.html [L]
</IfModule>注意：以上index为入口文件，如果是php文件，需要把html改为php。
WordPress搬家后的500错误
换了服务器，搬家前，理所当然的打包文件，备份数据库。
然后把文件上传到新服务器，上传数据库，修改了数据库对应的配置。
然后，信心满满的打开域名……
500！
按照网上说的一些方法都没有啥用。
我解决的步骤如下：
先全新安装Wordpress，然后，把旧数据库覆盖新安装的数据库，然后把旧的文件覆盖新文件，搞定！
npm 查看版本、安装及卸载
npm list // 查看本地已安装模块清单
npm list [packageName] // 查看本地已安装模块版本
npm info [packageName] //查看模块的详细信息 包括各版本号等
npm view [packageName] version // 查看模块远程最新版本
npm view [packageName] versions // 查看模块远程所有版本
npm install [packageName] //安装模块
npm install [packageName]@xxx.xx //安装模块的指定版本
npm install [packageName] -g //全局安装模块
npm install [packageName] –save 安装好后写入package.json的dependencies中（生产环境依赖）
npm install [packageName] –save-dev 安装好后写入package.json的devDepencies中（开发环境依赖）
npm uninstall [packageName] // 删除模块
npm uninstall [packageName] -g //卸载全局模块
npm uninstall [packageName] –save // 删除模块，同时删除模块留在package.json中dependencies下的对应信息
npm uninstall [packageName] –save-dev // 删除模块，同时删除模块留在package.json中devDependencies下的对应信息
作者：少华一号
来源：CSDN
原文：https://blog.csdn.net/u012982629/article/details/80676928
版权声明：本文为博主原创文章，转载请附上博文链接！
CSS Framework第四版……
第三版，较第二版而言，主要是查漏补缺，优化了上一版中的一些class名称，把可能产生歧义的命名做了修改，同时也删除了一些重复定义的部分。
第四版的更新，有些地方似乎颠覆上版本的，比如引用的bootstrap4.0，把前几版中忽略的flex作为一个模块重新去定义。
另外，把前几版中响应式布局的优先从PC优先改为了移动端优先。
当然，这个第四版，也不一定就是全新的第四版，尝试性的简化了一些class命名，重点将要增加flex弹性布局，其他，基本沿袭上一版的内容，可以看作是一个衍生的版本。
最后，向优秀的框架学习，不断进步。
CSS Framework第三版，开始修订
终于开始了，这一次修订，主要对前面两版在实践中的各种问题的修复，去除重复定义。
事实上，第二版还没有正式发布，第二版算是个过渡版本，承接第一版，启发第三版，在不断的微调中，总结了很多问题，逐一修复。
我坚信，未来的路还远着，第三版，或许仍然是个过渡版本，但将会是一个较大修改的版本。
构建自由灵活的前端框架……
没错，我喜欢省略号多过于其他的标点符号，因为，省略号有更多的潜台词，意犹未尽。
正题，从自己有想法写一套前端css框架开始，自由和灵活这两个词就反复的在脑子里蹦跶，时刻提醒我，考虑问题要周全，预设css要完备；只有这样，构建页面时，才能做的自由灵活的组合。
预想一下，一个完成的网站，有时候需要在一个模块上调整一下样式，或者增加一点内容，而且，这个模块在其他页面也有，要不冲突的解决问题，唯一的方法可能就是在父级盒子上新增一个class名称。
这个需求是很常见的。
如果，拆分了需求，每个可能新增的需求都预置好了对应的样式，那么，只需要在需要修改的模块上，新增对应的样式即可，例如，改变颜色，改变布局等等。
以上看起来像废话，而且，也是许多框架正在或者已经实现的，但我仍然需要为自己去定制一套。
然而，只有在实际项目中，才能逐步去根据需求去完善框架，一个人的思路和精力都是有限的，多么希望多几个人参与进来，共同创造并完善一套框架。