Learn-HTML-CSS

Appearance

Return to top
On this page

项目目录结构

bash
├── docs
├── src
│   ├── css
│   │   ├── login.css
│   │   ├── index.css(main.css)
│   │   └── reset.css(normalize.css)
│   ├── img
│   │   ├── background.jpg
│   │   ├── icon.svg
│   │   └── logo.png
│   ├── js
│   │   ├── login.js
│   │   └── index.js
│   ├── 404.html
│   ├── favicon.ico
│   ├── humans.txt
│   ├── index.html
│   ├── login.html
│   └── robots.txt
├── .editorconfig
├── .gitignore
├── CHANGELOG.md
├── LICENSE.txt
└── README.md

├── docs
├── src
│   ├── css
│   │   ├── login.css
│   │   ├── index.css(main.css)
│   │   └── reset.css(normalize.css)
│   ├── img
│   │   ├── background.jpg
│   │   ├── icon.svg
│   │   └── logo.png
│   ├── js
│   │   ├── login.js
│   │   └── index.js
│   ├── 404.html
│   ├── favicon.ico
│   ├── humans.txt
│   ├── index.html
│   ├── login.html
│   └── robots.txt
├── .editorconfig
├── .gitignore
├── CHANGELOG.md
├── LICENSE.txt
└── README.md
  • docs：项目的文档目录。
  • src：源代码目录。
    • src/css：应用程序的 CSS 样式表文件。
      • src/css/login.css：登录页面的 CSS 样式表文件。
      • src/css/index.css：主页面的 CSS 样式表文件。
      • src/css/reset.css：用于重置浏览器默认样式的 CSS 样式表文件（通常是 Normalize.css）。
    • src/img：应用程序的图像文件。
      • src/img/background.jpg：应用程序的背景图片文件。
      • src/img/icon.svg：应用程序的图标文件。
      • src/img/logo.png：应用程序的 Logo 文件。
    • src/js：应用程序的 JavaScript 脚本文件。
      • src/js/login.js：登录页面的 JavaScript 脚本文件。
      • src/js/index.js：主页面的 JavaScript 脚本文件。
    • src/404.html：404 错误页面文件。
    • src/favicon.ico：应用程序的图标文件（通常在浏览器标签页中显示）。The best Favicon Generator (completely free) - favicon.io
    • src/humans.txt：一个包含了应用程序相关人员信息的文本文件。
    • src/index.html：应用程序的主页面文件。
    • src/login.html：应用程序的登录页面文件。
    • src/robots.txt：规定了搜索引擎抓取工具可以访问您网站上的哪些网址。此文件主要用于避免您的网站收到过多请求；它并不是一种阻止 Google 抓取某个网页的机制。若想阻止 Google 访问某个网页，请使用 noindex 禁止将其编入索引，或使用密码保护该网页。
  • .editorconfig：用于配置不同编辑器的代码格式化规则。
  • .gitignore：用于指定应该被 Git 忽略的文件和目录，以免它们被误传到代码库中。
  • CHANGELOG.md：应用程序的版本变更历史记录。
  • LICENSE.txt：应用程序的开源协议文件。
  • README.md：应用程序的说明文档文件。

humans.txt

Docs

  1. 先创建一个名为 humans.txt 的文件（记着用小写文字），并以 UTF-8, 编码，避免出现与其他语言字符合用问题。
  2. 在文件中添加以下内容：
bash
/* TEAM */
# 你在该项目的职位：你的名字
Your title: Your name.

# 网站： 电子邮件，联系表格链接,...
Site: email, link to a contact form, etc.

# Twitter: 你的Twitter用户名称
Twitter: your Twitter username.

# 地点： 城市，社区，国家
Location: City, Country.
                        [...]

/* THANKS */
# 名称： 名称或网址
Name: name or url
                        [...]
/* SITE */
# 最后更新: 年 /月 /天
Last update: YYYY/MM/DD

# 标准： HTML5, CSS3,..
Standards: HTML5, CSS3,..

# 组件： Modernizr, jQuery, etc.
Components: Modernizr, jQuery, etc.

# 软件：用于开发网站的软件。
Software: Software used for the development

/* TEAM */
# 你在该项目的职位：你的名字
Your title: Your name.

# 网站： 电子邮件，联系表格链接,...
Site: email, link to a contact form, etc.

# Twitter: 你的Twitter用户名称
Twitter: your Twitter username.

# 地点： 城市，社区，国家
Location: City, Country.
                        [...]

/* THANKS */
# 名称： 名称或网址
Name: name or url
                        [...]
/* SITE */
# 最后更新: 年 /月 /天
Last update: YYYY/MM/DD

# 标准： HTML5, CSS3,..
Standards: HTML5, CSS3,..

# 组件： Modernizr, jQuery, etc.
Components: Modernizr, jQuery, etc.

# 软件：用于开发网站的软件。
Software: Software used for the development

robots.txt

Docs

robots.txt 文件规定了搜索引擎抓取工具可以访问您网站上的哪些网址。此文件主要用于避免您的网站收到过多请求；它并不是一种阻止 Google 抓取某个网页的机制。若想阻止 Google 访问某个网页，请使用 noindex 禁止将其编入索引，或使用密码保护该网页。

了解 robots.txt 文件的限制

在创建或修改 robots.txt 文件之前，您应了解这种网址屏蔽方法的限制。根据您的目标和具体情况，您可能需要考虑采用其他机制来确保搜索引擎无法在网络上找到您的网址。

  • 并非所有搜索引擎都支持 robots.txt 规则。 robots.txt 文件中的命令并不能强制规范抓取工具对网站采取的行为；是否遵循这些命令由抓取工具自行决定。Googlebot 和其他正规的网页抓取工具都会遵循 robots.txt 文件中的命令，但其他抓取工具未必如此。因此，如果您想确保特定信息不会被网页抓取工具抓取，我们建议您采用其他屏蔽方法，例如用密码保护服务器上的隐私文件。
  • 不同的抓取工具会以不同的方式解析语法。 虽然正规的网页抓取工具会遵循 robots.txt 文件中的规则，但每种抓取工具可能会以不同的方式解析这些规则。您需要好好了解一下适用于不同网页抓取工具的正确语法，因为有些抓取工具可能会无法理解某些命令。
  • 如果其他网站上有链接指向被 robots.txt 文件屏蔽的网页，则此网页仍可能会被编入索引。 尽管 Google 不会抓取被 robots.txt 文件屏蔽的内容或将其编入索引，但如果网络上的其他位置有链接指向被禁止访问的网址，我们仍可能会找到该网址并将其编入索引。因此，相关网址和其他公开显示的信息（如相关页面链接中的定位文字）仍可能会出现在 Google 搜索结果中。若要正确阻止您的网址出现在 Google 搜索结果中，您应为服务器上的文件设置密码保护、使用 noindex meta 标记或响应标头，或者彻底移除网页。

下面是一个包含两条规则的简单 robots.txt 文件：

yaml
User-agent: Googlebot
Disallow: /nogooglebot/

User-agent: *
Allow: /

Sitemap: https://www.example.com/sitemap.xml

User-agent: Googlebot
Disallow: /nogooglebot/

User-agent: *
Allow: /

Sitemap: https://www.example.com/sitemap.xml

以下是该 robots.txt 文件的含义：

  1. 名为 Googlebot 的用户代理不能抓取任何以 https://example.com/nogooglebot/ 开头的网址。
  2. 其他所有用户代理均可抓取整个网站。不指定这条规则也无妨，结果是一样的；默认行为是用户代理可以抓取整个网站。
  3. 该网站的站点地图文件路径为 https://www.example.com/sitemap.xml。

如需查看更多示例，请参阅语法部分。

.editorconfig

Docs

EditorConfig 是一个用于维护一致的编码风格的文件格式和插件集合。它通过在项目根目录中放置一个名为 .editorconfig 的文件来工作，该文件指定了项目中的文件应该使用的编码风格。

EditorConfig 文件包含一组键值对，每个键值对定义了一种特定类型的文件如何进行格式化。例如，你可以指定缩进方式，制表符或空格的使用，行末是否需要换行符等等。这些设置将被支持 EditorConfig 的编辑器和 IDE 自动识别并应用于项目中的文件。

EditorConfig 可以帮助团队协作时保持一致的代码风格，从而提高代码可读性和可维护性。它支持许多流行的编辑器和 IDE，包括 Visual Studio Code，Sublime Text，Atom，IntelliJ IDEA 等等。

ini
# EditorConfig is awesome: https://EditorConfig.org

# top-most EditorConfig file
root = true

# Unix-style newlines with a newline ending every file
[*]
end_of_line = lf
insert_final_newline = true

# Matches multiple files with brace expansion notation
# Set default charset
[*.{js,py}]
charset = utf-8

# 4 space indentation
[*.py]
indent_style = space
indent_size = 4

# Tab indentation (no size specified)
[Makefile]
indent_style = tab

# Indentation override for all JS under lib directory
[lib/**.js]
indent_style = space
indent_size = 2

# Matches the exact files either package.json or .travis.yml
[{package.json,.travis.yml}]
indent_style = space
indent_size = 2

# EditorConfig is awesome: https://EditorConfig.org

# top-most EditorConfig file
root = true

# Unix-style newlines with a newline ending every file
[*]
end_of_line = lf
insert_final_newline = true

# Matches multiple files with brace expansion notation
# Set default charset
[*.{js,py}]
charset = utf-8

# 4 space indentation
[*.py]
indent_style = space
indent_size = 4

# Tab indentation (no size specified)
[Makefile]
indent_style = tab

# Indentation override for all JS under lib directory
[lib/**.js]
indent_style = space
indent_size = 2

# Matches the exact files either package.json or .travis.yml
[{package.json,.travis.yml}]
indent_style = space
indent_size = 2

.gitignore

Docs

.gitignore 是一个用于指定 Git 版本控制系统应该忽略哪些文件和文件夹的配置文件。

当您向 Git 版本控制系统添加新的文件和文件夹时，Git 会默认跟踪这些变化并将它们添加到版本历史中。但是有些文件或文件夹，例如编译输出、日志文件或临时文件等，不应该被纳入版本控制，因为它们通常是临时性的或在多个开发环境中具有不同的特性，因此在每个开发环境中都需要特殊处理。

通过在项目根目录下创建一个名为 .gitignore 的文件，并将需要忽略的文件或文件夹列出来，可以告诉 Git 忽略这些文件，从而避免它们被意外添加到版本历史中。.gitignore 文件中的规则可以是精确匹配的文件名、通配符模式、目录名或正则表达式等。

bash
# exclude everything except directory foo/bar
/*
!/foo
/foo/*
!/foo/bar

# exclude everything except directory foo/bar
/*
!/foo
/foo/*
!/foo/bar

这个 .gitignore 文件的规则是：

  • /*：排除所有文件和文件夹。
  • !/foo：但是，不要排除名为 foo 的目录。
  • /foo/*：排除 foo 目录下的所有文件和文件夹。

因此，这个 .gitignore 文件的作用是只包含 foo 目录及其子目录中的文件和文件夹，而忽略所有其他内容。

CHANGELOG.md

Docs

CHANGELOG.md 是一个文件，用于记录软件项目的版本历史和变更信息。它通常以 Markdown 格式编写，以方便阅读和撰写。

CHANGELOG.md 文件记录了每个版本的发布日期、版本号、变更类型（例如“新增”、“修复”、“删除”等）、变更摘要和详细说明。通过查看 CHANGELOG.md 文件，用户可以了解软件项目的历史版本和当前版本的变更情况，以及每个变更的具体内容和目的。

CHANGELOG.md 文件是开源社区中一种常用的协作工具，它可以帮助开发者记录项目的变化，便于团队协作和用户了解软件版本的变更情况。

CHANGELOG.md 文件通常包括以下部分：

  • 版本历史：列出每个版本的发布日期、版本号和变更类型。
  • 新增功能：列出新功能和改进的特性。
  • 修复问题：列出已解决的错误和问题。
  • 删除功能：列出已删除或弃用的功能。
  • 其他变更：列出其他变更，例如性能改进、安全增强、文档更新等。

具体的变更类型可以根据项目的实际情况进行定义，但通常包括以下几种：

  • Added - For any new features that have been added since the last version was released

    添加 - 指自上一版本发布以来新增的任何新功能。

  • Changed - To note any changes to the software's existing functionality

    更改 - 指对软件现有功能所做的任何更改。

  • Deprecated - To note any features that were once stable but are no longer and have thus been removed

    弃用 - 指曾经稳定存在但现已被删除的任何功能。

  • Fixed - Any bugs or errors that have been fixed should be so noted

    修复 - 应记录任何已修复的错误或故障。

  • Removed - This notes any features that have been deleted and removed from the software

    删除 - 指已删除并从软件中移除的任何功能。

  • Security - This acts as an invitation to users who want to upgrade and avoid any software vulnerabilities

    安全性 - 这作为邀请用户升级并避免任何软件漏洞的邀请。

bash
## [0.0.4] - 2014-08-09

### Added

- Better explanation of the difference between the file ("CHANGELOG")
  and its function "the change log".

### Changed

- Refer to a "change log" instead of a "CHANGELOG" throughout the site
  to differentiate between the file and the purpose of the file — the
  logging of changes.

### Removed

- Remove empty sections from CHANGELOG, they occupy too much space and
  create too much noise in the file. People will have to assume that the
  missing sections were intentionally left out because they contained no
  notable changes.

## [0.0.3] - 2014-08-09

### Added

- "Why should I care?" section mentioning The Changelog podcast.

## [0.0.2] - 2014-07-10

### Added

- Explanation of the recommended reverse chronological release ordering.

## [0.0.1] - 2014-05-31

### Added

- This CHANGELOG file to hopefully serve as an evolving example of a
  standardized open source project CHANGELOG.
- CNAME file to enable GitHub Pages custom domain
- README now contains answers to common questions about CHANGELOGs
- Good examples and basic guidelines, including proper date formatting.
- Counter-examples: "What makes unicorns cry?"

[unreleased]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.5...HEAD
[0.0.5]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.4...v0.0.5
[0.0.4]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.3...v0.0.4
[0.0.3]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.2...v0.0.3
[0.0.2]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.1...v0.0.2
[0.0.1]: https://github.com/olivierlacan/keep-a-changelog/releases/tag/v0.0.1

## [0.0.4] - 2014-08-09

### Added

- Better explanation of the difference between the file ("CHANGELOG")
  and its function "the change log".

### Changed

- Refer to a "change log" instead of a "CHANGELOG" throughout the site
  to differentiate between the file and the purpose of the file — the
  logging of changes.

### Removed

- Remove empty sections from CHANGELOG, they occupy too much space and
  create too much noise in the file. People will have to assume that the
  missing sections were intentionally left out because they contained no
  notable changes.

## [0.0.3] - 2014-08-09

### Added

- "Why should I care?" section mentioning The Changelog podcast.

## [0.0.2] - 2014-07-10

### Added

- Explanation of the recommended reverse chronological release ordering.

## [0.0.1] - 2014-05-31

### Added

- This CHANGELOG file to hopefully serve as an evolving example of a
  standardized open source project CHANGELOG.
- CNAME file to enable GitHub Pages custom domain
- README now contains answers to common questions about CHANGELOGs
- Good examples and basic guidelines, including proper date formatting.
- Counter-examples: "What makes unicorns cry?"

[unreleased]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.5...HEAD
[0.0.5]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.4...v0.0.5
[0.0.4]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.3...v0.0.4
[0.0.3]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.2...v0.0.3
[0.0.2]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.1...v0.0.2
[0.0.1]: https://github.com/olivierlacan/keep-a-changelog/releases/tag/v0.0.1

LICENSE.txt

Docs

LICENSE.txt 是一种文本文件，其中包含了软件或其他创作作品的许可证条款和条件。许可证条款和条件通常描述了使用、复制、修改和分发作品的规则，以及有关责任和保证的条款。

大多数用户都会将许可证文本放在存储库根中名为 LICENSE.txt（或者 LICENSE.md 或 LICENSE.rst）的文件中。

在许多开源软件项目中，开发人员会提供一个 LICENSE.txt 文件，以确保任何人都可以了解和遵守使用软件的规则。这些规则通常是根据特定的开源许可证制定的，例如 GPL、MIT、BSD 等。

在其他类型的创作作品中，例如文学作品、音乐作品或图像作品中，也可能包含有关作品使用的许可证条款和条件的 LICENSE.txt 文件。这些许可证可能会规定作品的使用和分发方式，以及任何可能的限制和责任。

许可证许可关键字
学术自由许可证 v3.0afl-3.0
Apache 许可证 2.0apache-2.0
艺术许可协议 2.0artistic-2.0
Boost 软件许可证 1.0bsl-1.0
二条款 BSD“简化版”许可证bsd-2-clause
三条款 BSD“新版”或“修改版”许可证bsd-3-clause
BSD 3 条款净化版许可证bsd-3-clause-clear
知识共享许可证系列cc
免费知识共享 v1.0 通用cc0-1.0
知识共享署名 4.0cc-by-4.0
知识共享署名相同方式共享 4.0cc-by-sa-4.0
你想干嘛就干嘛公共许可证wtfpl
教育社区许可证 v2.0ecl-2.0
Eclipse 公共许可证 1.0epl-1.0
Eclipse 公共许可证 2.0epl-2.0
欧盟公共许可证 1.1eupl-1.1
GNU Affero 通用公共许可证 v3.0agpl-3.0
GNU 通用公共许可证系列gpl
GNU 通用公共许可证 v2.0gpl-2.0
GNU 通用公共许可证 v3.0gpl-3.0
GNU 宽通用公共许可证系列lgpl
GNU 宽通用公共许可证 v2.1lgpl-2.1
GNU 宽通用公共许可证 v3.0lgpl-3.0
ISCisc
LaTeX 项目公共许可证 v1.3clppl-1.3c
Microsoft 公共许可证ms-pl
MITmit
Mozilla 公共许可证 2.0mpl-2.0
开放软件许可证 3.0osl-3.0
PostgreSQL 许可证postgresql
SIL 开源字体许可 1.1ofl-1.1
伊利诺伊大学/NCSA 开源许可证ncsa
The Unlicenseunlicense
zLib 许可证zlib

README.md

Docs

关于自述文件 - GitHub Docs

README.md 是一种文件格式，通常用于项目的根目录中，用于向其他人介绍该项目。它是一个纯文本文件，可以在 GitHub、Bitbucket、GitLab 等代码托管平台上使用。

README.md 的 ".md" 扩展名代表 "Markdown"，这是一种轻量级标记语言，可以使用简单的文本标记来描述项目的结构、功能、安装、配置、使用方法、贡献方式等等。它可以包含代码示例、图像、链接、表格、列表等等，以便其他人更好地了解你的项目并参与到其中。

README.md 文件通常是项目的第一个文件，当其他人访问你的代码库时，它们很可能是首先看到的文件。因此，编写一个清晰、简洁、易于理解的 README.md 文件非常重要，它可以帮助用户更好地了解和使用你的项目，也可以促进更多人的贡献和参与。

自述文件通常包含以下信息：

  • 项目做什么
  • 项目为什么有用
  • 用户如何使用项目
  • 用户能从何处获取项目的帮助
  • 谁维护和参与项目