我在工作中做了很多自定义应用程序。我正在尝试为新应用程序定义一些标准。有点像Elements的东西。
CSS ：您如何整理样式表？我是否应该为整个网站提供一个基本样式表，并为每个单独的页面设置一个用于自定义？打印样式我应该有另一个吗？我听说链接更多文件需要更多时间让浏览器检索它们。 （每页更多对象......还有很多javascript文件或图像的问题）......有多少是太多了？你是否大肆评论你的CSS？提供任何嵌套结构？在元素内按字母顺序排列？我需要重置吗？进口怎么样？和排版？
Javascript ：基本上是同一个问题。 Javascript文件......我应该包含一个或两个不错的库（例如JQuery和Prototype），然后为每个页面添加另一个库吗？现在我突然想要包含5或6个CSS和JS文件......
目录结构：您如何组织网站？目前，我使用类似
的东西/CSS ... For CSS files
/JS ... For javascript files
/INC ... For private code includes
/ASSETS/IMG ... For images
/ASSETS/AU ... For audio
/ASSETS/SWF ... For Flash
此外，欢迎任何其他提示。谢谢！
答案 0 :(得分：23)
我是否应该为整个网站提供一个基本样式表，并为每个单独的页面设置一个用于自定义？
务实。如果您没有足够的规则可以将它们全部组织在一个文件中并且保留对什么做什么的监督，那么这样做。如果您有大量规则仅适用于您网站中的某些部分或单个页面，请务必将其分解为各自的子样式表，但不要觉得需要为每个页面创建单独的样式表即使它只包含两个规则。将特定于页面的类或ID添加到＆lt; body＆gt;因此，如果需要，您可以从共享样式表中选择单个页面。
将样式分隔为样式表是为了您作为作者的利益，因此您最容易管理的内容也是如此。对于一个复杂的网站，它可能不止一个CSS文件，但它不会是几十个。
我是否应该为打印样式添加另一种？
一般是的。虽然您可以使用@media规则将打印样式嵌入到另一个样式表中，但这传统上是错误的，因此将介质放在＆lt; link＆gt;中。标签通常最简单。在任何情况下，打印样式表通常与屏幕样式表的区别很大，因此将规则分开是有意义的。
我听说链接更多文件需要更多时间让浏览器检索它们。
是的，但这种影响往往被夸大了。 HTTP / 1.1通过保持客户端和服务器之间的连接保持活动来减少每个请求的延迟，这是一个强有力的缓解。
有多少是太多了？
足够你不太可能拥有那么多样式表。如果您使用的是每个类需要一个脚本文件的框架，那么脚本可能会成为一个问题，但通常都可以。对于许多小图像来说，这通常是个问题。
你是否对你的CSS发表评论？
轻度评论通常应该足够了。 CSS的声明性规则样式通常不够复杂，需要代码可以要求的深入解释。特别是，记录任何违反直觉的，如浏览器特定的黑客攻击。
元素内的字母表？
除非能让您更轻松地管理，否则不会。通常它不会，您尝试将类似的规则或规则分组应用于类似的元素组。
我需要重置吗？
完全重置？如果您知道自己在做什么，并且可以选择要重置的特定有问题的默认值，那就不行了。
我应该包含一个或两个不错的库（例如JQuery和Prototype）
除非绝对必须，否则不要包含多个框架。
然后为每个页面添加另一个？
如果每个页面都有特定的自定义行为。但这通常不会发生。如果您制作了绑定到例如的渐进增强行为脚本。类名，您可以在每个使用它的页面上包含每个行为的脚本，然后让它找到要自动绑定的元素。
目录结构：您如何组织网站？
就个人而言，对于我的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
对于我来说，将“数据”保存在“系统”中的应用程序的单独位置（具有单独的权限）非常重要。您需要能够换出'system'文件夹来升级应用程序，而不必担心在htdocs / img中有上传的图像，您必须担心保留。
答案 1 :(得分：8)
CSS：我只使用一个样式表。随着我的进展，我一直坚持到底。我通常在每个特定于页面的规则集之前发表评论。如果我需要编辑内容，请按Ctrl + F.
Javascript：通常只包含一个库，也许只有一些插件。用于将任何特定于页面的JS直接抛出到该页面的标题中，但我发现它有点难看并且将“行为”与数据混合在一起。所以我开始了一个新的范例 -
MVCB - 模型，视图，控制器，行为。 MVC非常适合具有相当静态UI的桌面应用程序，但是当你添加大量JS时，我认为它需要额外的抽象层。
因此，我的原始文件结构：
index.php
app
config
bootstrap.php -- code that needs to run before anything else, or functions that don't really fit elsewhere
core.php -- timezone, database, and misc settings
routes.php -- default routes
layouts -- layout/template files
flash -- layouts for one-time popup messages
objects -- all files are stored in the same folder as the controller to keep directories
smaller and ease reusability
object
controller.php
model.php
routes.php -- object-specific routes to override default routes
behaviours -- page-specific javascript files
action.js -- included automatically on that page if this file exists
views
action.php -- the view for this action
public -- static media files, sometimes called "assets"
favicon.ico
xrds.xml
css
img
js
uploads
core
app.php -- initializes stuff
controller.php -- default controller
dispatcher.php -- includes everything and calls all the appropriate functions
model.php -- default model that all other models inherit from
components -- helper functions to used in controllers
datasources -- mysql, oracle, flat-file...
helpers -- functions to be used in views and layouts
structures -- model helpers such as tree or polymorphic behaviours
utils -- functions that are useful everywhere
libs -- 3rd party libs
<强>的.htaccess
Options -Indexes
RewriteEngine On
RewriteCond %{REQUEST_URI} !^/app/public/
RewriteCond %{DOCUMENT_ROOT}/app/public%{REQUEST_URI} -f
RewriteRule .* /app/public/$0 [L]
RewriteCond %{REQUEST_URI} !^/app/objects/
RewriteRule ^([^/]+)/(.+\.js)$ /app/objects/$1/behaviours/$2 [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule .* /index.php?url=$0 [L,QSA]
答案 2 :(得分：3)
我已在另一个帖子中发布了我的目录结构和注释，但它也适用于此处！
我已经使用了以下设置一段时间了，效果很好：
/ site：这是我实际工作的网站所在地。创建模板后，我将在此目录中安装CMS或平台。
/ source：包含任何组合，备注，文档，规格等。
/ templates：从这里开始！创建最终需要移植到CMS或/ site框架中的所有静态模板。
/ _ media：图片，可下载文件等。必要时组织
/ _ style：我更喜欢模块化的CSS开发，所以我通常最终会为网站的每个独特部分添加许多样式表。使用Blender大大清理了这一点 - 我强烈推荐这个工具！
/ _ vendor：所有第三方代码（jQuery，shadowbox等）
Blendfile.yaml （适用于Blender;见上文）
/ tests：Selenium单元测试
答案 3 :(得分：3)
请确保不要对文件夹使用大写字母。当您在Windows上开发并在Linux服务器上部署时，它可能会咬你。
答案 4 :(得分：1)
尽量拥有一张样式表。链接单个页面的单个样式表会失败。
您可以通过在表格顶部添加以下行来继承css中的其他样式表
@import url('blueprint/screen.css');
@import url('blueprint/styles.css');
在这种情况下，我继承了蓝图css样式，然后在下面添加我的自定义样式。
就JS库而言，我更喜欢链接3个文件。
图书馆， 一页包含所有插件， 最后是页面代码。
对于目录结构，我通常有以下内容：
/ _ CSS /_图片 / _scripts 文件
但是最近我开始把所有用于使网站看起来/工作的东西按照我想要的方式放在/ _presentation目录中...然后任何其他像博客文章的图像等将进入/ images
希望这有帮助。
答案 5 :(得分：0)
我总是试图让浏览器不必加载和解释CSS规则和未在HTML上使用的JS代码。我同意@bobince的说法，如果组织需要，你应该只将页面的样式和脚本分成单独的文件，但如果你的网站非常大，你就会达到这一点。
然而，由于我只构建基于模板的站点，我开始想知道为什么我会链接到外部文件。例如，如果我有一个基本模板，那么我放在该模板头部的内容将应用于我网站上的所有页面。那么为什么不把我的风格和脚本放在那里呢？
有两个原因浮现在脑海中。首先，浏览器可以缓存外部文件，并在包含它的每个页面上重复使用它，而不必再次加载它。第二个设计师在你的模板中可能不那么舒服，因为他们正在搞乱普通的CSS文件。
对于适用于您网站中每个网页的全局样式而言，这一切都很好，但那些具有某种风格的一次性网页又不会在其他任何地方共享？如果您将此样式添加到全局应用的外部文件中，则会增加站点的初始加载时间，只是为了使样式仅在一个页面上使用。此外，当您几个月后返回该文件时，您可能会忘记这些规则甚至是什么。
我建议任何未在每个页面上表达的样式规则都应放在子模板中的<style>标记中，以呈现规则适用的HTML。这会将负载和复杂性从全局样式表移动到需要样式的实际页面，并提供规则上下文，以便将来可以维护它们。如果这让您的设计师感到害怕，他们无论如何都不需要编写CSS。告诉他们坚持使用Photoshop，让你做大男孩的工作。