应该实际操作。如果你的规则足够少,可以将它们全部组织在一个文件中,并保持对规则的整体视图。如果某些部分或单独页面的规则很多,则将它们分解为自己的子样式表,但是即使仅包含两条规则也不必为每个单独页面创建单独的样式表。请添加适用于<body>的特定类或id,以便在需要时从共享样式表中提取单个页面。
将样式分离到样式表中是为了方便作者,因此请按照您发现最容易管理的方式进行操作。对于复杂的网站,可能需要使用多个CSS文件,但通常不是数十个。
通常是的。虽然您可以使用@media规则在另一个样式表中嵌入打印样式,但这通常会存在bug,因此在<link>标签中放置媒体通常是最简单的方法。无论如何,在屏幕对应的样式表与其打印对应物之间通常存在很大的不同,因此将它们的规则分开是很有意义的。
是的,但经常夸大了这种影响。 HTTP/1.1通过保持客户端和服务器之间的连接来减少每次请求的延迟,这是一个有效的缓解方法。
足以让您极不可能有那么多样式表。如果您使用需要每个类一个脚本文件的框架,则脚本可能会出现问题,但通常情况下它们都可以正常运行。更常见的问题是大量小图像。
通常应该足够轻型的评论。CSS的声明规则样式通常不会变得足够复杂,需要代码等深入解释。特别是像针对特定浏览器的hack之类的事情应该记录在文档中。
不是除非它使你更容易管理。通常不会,您会尝试将相似的规则或适用于相似元素组的规则分组。
如果您知道自己在做什么,并且可以选择要重置的特定有问题的默认设置,则无需进行完全重置。
除非您绝对必须,否则不要包含多个框架。
如果每个页面都具有特定的自定义行为,则可以这样做。 但是这通常不会发生。如果您制作渐进增强行为脚本,可以将每个行为的脚本包括在使用它的每个页面上,然后让它自动找到要绑定的元素。
就我个人而言,对于我的Python/WSGI应用程序:
appfolder
application.py - main WSGI entry point and control/configuration script
data - run-time writable application file store
private - files not available through the web server
public - mounted as a virtual directory on the web server
logs - access, error, application log files
system - all the static application code and data
htdocs - web server root folder
file - static servable files
img - static images
script - JavaScript
style - CSS
lib - Python modules used by site
appmodule - main application code package
templates - HTML page templates
mail - mail text templates
对我来说,将“数据”与“系统”应用程序分开(使用不同的权限)是很重要的。您需要能够更换“系统”文件夹以升级应用程序,而无需担心必须保留 htdocs/img 中上传的图像。