I do a lot of custom applications at work. I'm trying to define some standards for new applications. Something a little like Elements.
我在工作中做了很多定制的应用。我正在为新应用程序定义一些标准。有点像元素的东西。
CSS: How do you organize the style sheets? Should I have one base style sheet for the whole site and one for each individual page for customizations? Should I have another for print styles? I've heard that linking more files takes more time for the browser to retrieve them. (More objects per page...also a problem with lots of javascript files or images) ... How many is is too many? Do you heavily comment your CSS? Provide any nested structure? Alphabetize within elements? Do I need a reset? What about imports? And typography?
CSS:你如何组织样式表?是否应该为整个站点提供一个基本样式表，为每个单独的页面提供一个基本样式表以进行定制?我应该再买一件印花样式的吗?我听说链接更多的文件需要浏览器花更多的时间来检索它们。(每页更多对象…还有很多javascript文件或图像的问题)……多少是太多?你对你的CSS有过多的评论吗?提供任何嵌套的结构?在元素依字母顺序排列?我需要重置吗?进口呢?和排版吗?
Javascript: Basically the same question. Javascript files...Should I include one or two nice libraries (JQuery and Prototype, for example) and then have another included for each page? Now I'm suddenly including 5 or 6 CSS and JS files...
Javascript:基本上是同一个问题。Javascript文件…我应该包含一个或两个不错的库(例如JQuery和Prototype)，然后为每个页面包含另一个库吗?现在我突然包含了5到6个CSS和JS文件……
Directory Structure: How do you organize a site? Currently, I use something like
目录结构:如何组织网站?目前，我使用类似的东西
/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
Also, any other tips would be welcome. Thanks!!
另外，任何其他的建议都是受欢迎的。谢谢! !
6 个解决方案
#1
23
Should I have one base style sheet for the whole site and one for each individual page for customizations?
我是否应该为整个站点提供一个基本样式表，并为每个单独的页面进行定制?
Be pragmatic. If you have few enough rules that you can organise them all in one file and retain an oversight of what does what, do that. If you have a significant number of rules that only apply to certain sections or individual pages in your site, by all means break them out into their own sub-stylesheets, but don't feel the need to create a separate stylesheet for every single page even when it only contains two rules. Add a page-specific class or id to <body> so you can pick out single pages from a shared stylesheet should you need to.
是务实的。如果你没有足够的规则，可以将它们组织在一个文件中，并对做什么保持监督，那就这样做。如果你有大量的规则只适用于某些部分和个人在你的网站页面,通过一切手段打破他们进入自己的sub-stylesheets,但不要觉得有必要创建一个单独的每一个页面的样式表,即使它只包含两个规则。向添加特定于页面的类或id，以便在需要时从共享样式表中挑选单个页面。
The separation of styles into stylesheets is for your benefit as an author, so do what you find easiest to manage. For a complicated site that'll probably be more than one CSS file, but it's not going to be dozens.
将样式分离到样式表中对于作者来说是有好处的，所以要做您认为最容易管理的事情。对于一个复杂的站点来说，它可能不止一个CSS文件，但不会是几十个。
Should I have another for print styles?
我应该再买一件印花样式的吗?
Generally yes. Whilst you can embed print styles inside another stylesheet using an @media rule, this has traditionally been buggy, so putting the media in the <link> tag is usually easiest. In any case print stylesheets are often so different from their screen counterparts that it just makes sense to keep their rules separate.
通常是的。虽然可以使用@media规则在另一个样式表中嵌入打印样式，但这在传统上是有问题的，因此将媒体放到 标记中通常是最容易的。无论如何，打印样式表与屏幕上的样式表非常不同，因此保持它们的规则独立是有意义的。
I've heard that linking more files takes more time for the browser to retrieve them.
我听说链接更多的文件需要浏览器花更多的时间来检索它们。
Yes, but this effect is often overstated. HTTP/1.1 reduces the per-request latency by keeping connections between the client and server alive, which is a strong mitigation.
是的，但这种效应往往被夸大了。HTTP/1.1通过保持客户端和服务器之间的连接处于活动状态来减少每个请求的延迟，这是一种很好的缓解方法。
How many is is too many?
多少是太多?
Enough that you're extremely unlikely to have that many stylesheets. Scripts can be a problem if you're using the kind of framework that demands one script file per class, but otherwise are generally OK. It's more commonly problematic with lots of small images.
足够了，你不太可能有那么多样式表。如果您使用的框架要求每个类都有一个脚本文件，那么脚本可能会是一个问题，但是其他情况下通常都可以。在很多小的图像中，这是很常见的问题。
Do you heavily comment your CSS?
你对你的CSS有过多的评论吗?
Light commenting usually should be enough. CSS's declarative rule style doesn't usually get complicated enough to need the in-depth explanations code can demand. In particular though, document anything counterintuitive like browser-specific hacks.
轻松的评论通常就足够了。CSS的声明式规则样式通常不会复杂到需要深入解释代码的需求。特别是，记录任何违反直觉的类似于浏览器的黑客行为。
Alphabetize within elements?
在元素依字母顺序排列?
Not unless that makes it easier for you to manage. Usually it wouldn't, you'd try to group similar rules, or rules applying to similar groups of elements.
除非这能让你更容易管理。通常不会，你会尝试将相似的规则或应用于相似元素组的规则分组。
Do I need a reset?
我需要重置吗?
A full reset? Not if you know what you're doing and can select the particular problematic defaults you want to reset.
一个完整的重置吗?如果你知道你在做什么，并且可以选择你想要重置的有问题的默认设置，那就不要这样做。
Should I include one or two nice libraries (JQuery and Prototype, for example)
我应该包含一两个很好的库(例如JQuery和Prototype)吗?
Don't include more than one framework unless you absolutely have to.
除非绝对需要，否则不要包含多个框架。
and then have another included for each page?
然后每一页都包含一个?
If each page has particular custom behaviour you could. But that doesn't usually happen. If you make progressive-enhancement behaviour scripts that bind to eg. class names, you can include the script for each behaviour on each page that uses it, then let it find the elements to bind to automatically.
如果每个页面都有特定的自定义行为，您可以这样做。但这通常不会发生。如果您制定与eg绑定的渐进增强行为脚本。类名，您可以在每个使用它的页面上包含每个行为的脚本，然后让它自动找到要绑定到的元素。
Directory Structure: How do you organize a site?
目录结构:如何组织站点?
Personally, for my Python/WSGI applications:
就我个人而言，对于我的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
It's important for me to keep the ‘data’ in a separate place (with separate permissions) to the application in ‘system’. You need to be able to swap out the ‘system’ folder to upgrade the application, without having to worry that there are uploaded images in htdocs/img you have to worry about keeping.
对我来说，将“数据”放在一个单独的位置(具有单独的权限)到“系统”中的应用程序是很重要的。您需要能够交换“system”文件夹以升级应用程序，而不必担心htdocs/img中有上传的图像，您需要担心保存这些图像。
#2
8
CSS: I only use one stylesheet. I just keep appending to the bottom as I go along. I usually place a comment before each page-specific set of rules. Ctrl+F if I need to edit something.
CSS:我只使用一个样式表。我一直往下写。我通常在每一组特定页面的规则前放置一个注释。Ctrl+F如果我需要编辑一些东西。
Javascript: Usually include only one library, and maybe a few plugins. Used to throw any page-specific JS directly into the header of that page, but I find it a bit ugly and mixes 'behaviour' with data. So I'm starting a new paradigm --
Javascript:通常只包含一个库，或者几个插件。用于将任何页面特定的JS直接扔到页面的头中，但我发现它有点难看，并将“行为”与数据混合在一起。所以我开始了一个新的范例。
MVCB -- Model, View, Controller, Behaviour. MVC is great for desktop apps with rather static UIs, but when you add lots of JS I think it calls for an extra layer of abstraction.
MVCB——模型、视图、控制器、行为。MVC非常适合使用静态ui的桌面应用程序，但是当您添加大量的JS时，我认为它需要一个额外的抽象层。
Thus, my original file structure:
因此，我的原始文件结构:
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
. 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]
#3
3
I have posted my directory structure and comments in another thread, but it is applicable here too!
我已经在另一个线程中发布了我的目录结构和注释，但是它也适用于这里!
I have been using the following setup for a while now with great results:
我使用以下设置已经有一段时间了，效果非常好:
-
/site: This is where my actual working website will live. I'll install my CMS or platform in this directory after the templates are created.
/site:我的工作网站就在这里。在创建模板之后，我将在这个目录中安装CMS或平台。
- .htaccess (basic tweaks I usually find myself enabling anyway)
- .htaccess(基本的调整，我通常发现自己已经启用了)
- robots.txt (so I don't forget to disallow items like /admin later)
- 机器人。txt(所以我不会忘记以后不允许像/admin这样的项目)
-
/source: Contains any comps, notes, documents, specifications, etc.
/来源:包含任何编译、注释、文件、规格等。
-
/templates: Start here! Create all static templates that will eventually need to be ported into the CMS or framework of /site.
/模板:从这里开始!创建所有最终需要移植到CMS或/site框架中的静态模板。
- /_behavior
- global.js (site-specific code; may be broken out into multiple files as needed)
- 全球。js(特定站点代码;可以根据需要分为多个文件)
- / _behavior全球。js(特定站点代码;可以根据需要分为多个文件)
-
/_media: Images, downloadable files, etc. Organized as necessary
/_media:图片、可下载的文件等
-
/_style: I prefer modular CSS development so I normally end up with many stylesheet for each unique section of the website. This is cleaned up greatly with Blender - I highly recommend this tool!
/_style:我更喜欢模块化的CSS开发，因此我通常会为网站的每个独特部分使用很多样式表。这是大大清理与搅拌机-我强烈推荐这个工具!
- print.css (this eventually gets blended, so use @media print)
- 打印。css(最终会混合使用，所以使用@media print)
- reset.css (Eric Meyer's)
- 重置。css(Eric Meyer)
- screen.css (for @media screen, handheld)
- 屏幕上。css(用于@media屏幕，手持)
- additional modules as necessary
- 额外的模块是必要的
-
/_vendor: all 3rd party code (jQuery, shadowbox, etc.)
/_vendor:所有第三方代码(jQuery、shadowbox等)
-
Blendfile.yaml (for Blender; see above)
Blendfile。yaml(搅拌机;见上图)
- template.html (basic starting template; can be copied and renamed for each unique template)
- 模板。html(基本的起始模板;可以为每个唯一模板复制和重命名)
- /_behavior
-
/tests: Selenium unit tests
硒/测试:单元测试
#4
3
Just make sure you don't use capital letters for folders. It may bite you when you develop on windows and deploy on a linux server.
只要确保你不会在文件夹中使用大写字母。当您在windows上开发和在linux服务器上部署时，它可能会对您产生影响。
#5
1
Do your best to have one style sheet. Linking individual style sheets for individual pages defeats the purpose.
尽量有一个样式表。将单个样式表链接到单独的页面会导致失败。
You can inherit other stylesheets in your css by including the following lines at the top of the sheet
您可以在css中继承其他样式表，方法是在表的顶部包含以下行
@import url('blueprint/screen.css');
@import url('blueprint/styles.css');
in this case I'm inheriting the blueprint css styles then adding my custom styles below that.
在本例中，我将继承blueprint css样式，然后在其下面添加自定义样式。
In terms of JS libraries I prefer to link 3 files.
就JS库而言，我更喜欢链接3个文件。
The Library, one page with all of the plugins, and finally the page code.
库，一个包含所有插件的页面，最后是页面代码。
For directory structure I generally have the following:
对于目录结构，我一般有以下几点:
/_css /_images /_scripts files
/ _css / _images / _scripts文件
but recently I've began to put everything used to make the site look/work the way I want it to in a /_presentation directory... then anything additional like images for blog posts etc would go in /images
但是最近，我开始将所有用于使站点看起来/工作起来的东西放在/_presentation目录中……然后任何其他的东西，如博客文章的图片等，都会进入/图片
Hope this helps.
希望这个有帮助。
#6
0
I always try to keep the browser from having to load and interpret CSS rules and JS code that isn't used on the HTML in question. I agree with @bobince that you should only break a page's styles and scripts into a separate file if it's necessary for organization, but if your site is very big at all, you will reach that point.
我总是尽量避免浏览器必须加载和解释CSS规则和JS代码，这些在HTML中没有使用。我同意@bobince的观点，如果需要进行组织，您应该将页面的样式和脚本拆分为单独的文件，但是如果您的站点非常大，那么您将达到这一点。
However since I only build template based sites, I am beginning to wonder why I link to external files at all. For example, if I have a base template the things I put in the head of that template will be applied to all the pages on my site. So why not just put my styles and scripts there?
然而，由于我只构建基于模板的站点，我开始怀疑为什么我要链接到外部文件。例如，如果我有一个基本模板，我放在模板头部的东西将应用到我网站上的所有页面。那么为什么不把我的样式和脚本放在那里呢?
Two reasons come to mind. First the browser can cache the external file and reuse it on every page that includes it without having to load it all over again. Second designers might not be as comfortable poking around in your templates as they are messing with plain CSS files.
有两个原因。首先，浏览器可以缓存外部文件并在包含它的每个页面上重用它，而不必重新加载它。第二设计师可能不会像在普通CSS文件中乱翻一样轻松地在模板中翻找。
That's all well and good for global styles that apply to every single page in your site, but what about those one-off pages that have some style that isn't shared anywhere else? If you added this style to a globally applied external file you'd increase the initial load time of your site just to have a style that is only used on one page. Further, when you go back to that file months later you will likely have forgotten what those rules were even for.
这对于适用于站点中的每一个页面的全局样式来说都很好，但是那些具有其他地方没有共享的样式的一次性页面呢?如果您将此样式添加到全局应用的外部文件中，您将增加站点的初始加载时间，使其具有只在一个页面上使用的样式。此外，当您在几个月后回到该文件时，您可能已经忘记了这些规则的作用。
I suggest that any style rule that is not expressed on every single page should be placed in <style> tags within the sub-template that renders the HTML the rule applies to. This will move the load and complexity from the global stylesheet to the actual page where the styles are needed, and give the rules context so that they can be maintained in the future. If this scares your designer they don't need to be writing CSS anyway. Just tell them to stick to Photoshop and let you do the big-boy work.
我建议，任何没有在每个页面上表达的样式规则都应该放在子模板中呈现规则应用的HTML的
#1
23
Should I have one base style sheet for the whole site and one for each individual page for customizations?
我是否应该为整个站点提供一个基本样式表，并为每个单独的页面进行定制?
Be pragmatic. If you have few enough rules that you can organise them all in one file and retain an oversight of what does what, do that. If you have a significant number of rules that only apply to certain sections or individual pages in your site, by all means break them out into their own sub-stylesheets, but don't feel the need to create a separate stylesheet for every single page even when it only contains two rules. Add a page-specific class or id to <body> so you can pick out single pages from a shared stylesheet should you need to.
是务实的。如果你没有足够的规则，可以将它们组织在一个文件中，并对做什么保持监督，那就这样做。如果你有大量的规则只适用于某些部分和个人在你的网站页面,通过一切手段打破他们进入自己的sub-stylesheets,但不要觉得有必要创建一个单独的每一个页面的样式表,即使它只包含两个规则。向添加特定于页面的类或id，以便在需要时从共享样式表中挑选单个页面。
The separation of styles into stylesheets is for your benefit as an author, so do what you find easiest to manage. For a complicated site that'll probably be more than one CSS file, but it's not going to be dozens.
将样式分离到样式表中对于作者来说是有好处的，所以要做您认为最容易管理的事情。对于一个复杂的站点来说，它可能不止一个CSS文件，但不会是几十个。
Should I have another for print styles?
我应该再买一件印花样式的吗?
Generally yes. Whilst you can embed print styles inside another stylesheet using an @media rule, this has traditionally been buggy, so putting the media in the <link> tag is usually easiest. In any case print stylesheets are often so different from their screen counterparts that it just makes sense to keep their rules separate.
通常是的。虽然可以使用@media规则在另一个样式表中嵌入打印样式，但这在传统上是有问题的，因此将媒体放到 标记中通常是最容易的。无论如何，打印样式表与屏幕上的样式表非常不同，因此保持它们的规则独立是有意义的。
I've heard that linking more files takes more time for the browser to retrieve them.
我听说链接更多的文件需要浏览器花更多的时间来检索它们。
Yes, but this effect is often overstated. HTTP/1.1 reduces the per-request latency by keeping connections between the client and server alive, which is a strong mitigation.
是的，但这种效应往往被夸大了。HTTP/1.1通过保持客户端和服务器之间的连接处于活动状态来减少每个请求的延迟，这是一种很好的缓解方法。
How many is is too many?
多少是太多?
Enough that you're extremely unlikely to have that many stylesheets. Scripts can be a problem if you're using the kind of framework that demands one script file per class, but otherwise are generally OK. It's more commonly problematic with lots of small images.
足够了，你不太可能有那么多样式表。如果您使用的框架要求每个类都有一个脚本文件，那么脚本可能会是一个问题，但是其他情况下通常都可以。在很多小的图像中，这是很常见的问题。
Do you heavily comment your CSS?
你对你的CSS有过多的评论吗?
Light commenting usually should be enough. CSS's declarative rule style doesn't usually get complicated enough to need the in-depth explanations code can demand. In particular though, document anything counterintuitive like browser-specific hacks.
轻松的评论通常就足够了。CSS的声明式规则样式通常不会复杂到需要深入解释代码的需求。特别是，记录任何违反直觉的类似于浏览器的黑客行为。
Alphabetize within elements?
在元素依字母顺序排列?
Not unless that makes it easier for you to manage. Usually it wouldn't, you'd try to group similar rules, or rules applying to similar groups of elements.
除非这能让你更容易管理。通常不会，你会尝试将相似的规则或应用于相似元素组的规则分组。
Do I need a reset?
我需要重置吗?
A full reset? Not if you know what you're doing and can select the particular problematic defaults you want to reset.
一个完整的重置吗?如果你知道你在做什么，并且可以选择你想要重置的有问题的默认设置，那就不要这样做。
Should I include one or two nice libraries (JQuery and Prototype, for example)
我应该包含一两个很好的库(例如JQuery和Prototype)吗?
Don't include more than one framework unless you absolutely have to.
除非绝对需要，否则不要包含多个框架。
and then have another included for each page?
然后每一页都包含一个?
If each page has particular custom behaviour you could. But that doesn't usually happen. If you make progressive-enhancement behaviour scripts that bind to eg. class names, you can include the script for each behaviour on each page that uses it, then let it find the elements to bind to automatically.
如果每个页面都有特定的自定义行为，您可以这样做。但这通常不会发生。如果您制定与eg绑定的渐进增强行为脚本。类名，您可以在每个使用它的页面上包含每个行为的脚本，然后让它自动找到要绑定到的元素。
Directory Structure: How do you organize a site?
目录结构:如何组织站点?
Personally, for my Python/WSGI applications:
就我个人而言，对于我的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
It's important for me to keep the ‘data’ in a separate place (with separate permissions) to the application in ‘system’. You need to be able to swap out the ‘system’ folder to upgrade the application, without having to worry that there are uploaded images in htdocs/img you have to worry about keeping.
对我来说，将“数据”放在一个单独的位置(具有单独的权限)到“系统”中的应用程序是很重要的。您需要能够交换“system”文件夹以升级应用程序，而不必担心htdocs/img中有上传的图像，您需要担心保存这些图像。
#2
8
CSS: I only use one stylesheet. I just keep appending to the bottom as I go along. I usually place a comment before each page-specific set of rules. Ctrl+F if I need to edit something.
CSS:我只使用一个样式表。我一直往下写。我通常在每一组特定页面的规则前放置一个注释。Ctrl+F如果我需要编辑一些东西。
Javascript: Usually include only one library, and maybe a few plugins. Used to throw any page-specific JS directly into the header of that page, but I find it a bit ugly and mixes 'behaviour' with data. So I'm starting a new paradigm --
Javascript:通常只包含一个库，或者几个插件。用于将任何页面特定的JS直接扔到页面的头中，但我发现它有点难看，并将“行为”与数据混合在一起。所以我开始了一个新的范例。
MVCB -- Model, View, Controller, Behaviour. MVC is great for desktop apps with rather static UIs, but when you add lots of JS I think it calls for an extra layer of abstraction.
MVCB——模型、视图、控制器、行为。MVC非常适合使用静态ui的桌面应用程序，但是当您添加大量的JS时，我认为它需要一个额外的抽象层。
Thus, my original file structure:
因此，我的原始文件结构:
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
. 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]
#3
3
I have posted my directory structure and comments in another thread, but it is applicable here too!
我已经在另一个线程中发布了我的目录结构和注释，但是它也适用于这里!
I have been using the following setup for a while now with great results:
我使用以下设置已经有一段时间了，效果非常好:
-
/site: This is where my actual working website will live. I'll install my CMS or platform in this directory after the templates are created.
/site:我的工作网站就在这里。在创建模板之后，我将在这个目录中安装CMS或平台。
- .htaccess (basic tweaks I usually find myself enabling anyway)
- .htaccess(基本的调整，我通常发现自己已经启用了)
- robots.txt (so I don't forget to disallow items like /admin later)
- 机器人。txt(所以我不会忘记以后不允许像/admin这样的项目)
-
/source: Contains any comps, notes, documents, specifications, etc.
/来源:包含任何编译、注释、文件、规格等。
-
/templates: Start here! Create all static templates that will eventually need to be ported into the CMS or framework of /site.
/模板:从这里开始!创建所有最终需要移植到CMS或/site框架中的静态模板。
- /_behavior
- global.js (site-specific code; may be broken out into multiple files as needed)
- 全球。js(特定站点代码;可以根据需要分为多个文件)
- / _behavior全球。js(特定站点代码;可以根据需要分为多个文件)
-
/_media: Images, downloadable files, etc. Organized as necessary
/_media:图片、可下载的文件等
-
/_style: I prefer modular CSS development so I normally end up with many stylesheet for each unique section of the website. This is cleaned up greatly with Blender - I highly recommend this tool!
/_style:我更喜欢模块化的CSS开发，因此我通常会为网站的每个独特部分使用很多样式表。这是大大清理与搅拌机-我强烈推荐这个工具!
- print.css (this eventually gets blended, so use @media print)
- 打印。css(最终会混合使用，所以使用@media print)
- reset.css (Eric Meyer's)
- 重置。css(Eric Meyer)
- screen.css (for @media screen, handheld)
- 屏幕上。css(用于@media屏幕，手持)
- additional modules as necessary
- 额外的模块是必要的
-
/_vendor: all 3rd party code (jQuery, shadowbox, etc.)
/_vendor:所有第三方代码(jQuery、shadowbox等)
-
Blendfile.yaml (for Blender; see above)
Blendfile。yaml(搅拌机;见上图)
- template.html (basic starting template; can be copied and renamed for each unique template)
- 模板。html(基本的起始模板;可以为每个唯一模板复制和重命名)
- /_behavior
-
/tests: Selenium unit tests
硒/测试:单元测试
#4
3
Just make sure you don't use capital letters for folders. It may bite you when you develop on windows and deploy on a linux server.
只要确保你不会在文件夹中使用大写字母。当您在windows上开发和在linux服务器上部署时，它可能会对您产生影响。
#5
1
Do your best to have one style sheet. Linking individual style sheets for individual pages defeats the purpose.
尽量有一个样式表。将单个样式表链接到单独的页面会导致失败。
You can inherit other stylesheets in your css by including the following lines at the top of the sheet
您可以在css中继承其他样式表，方法是在表的顶部包含以下行
@import url('blueprint/screen.css');
@import url('blueprint/styles.css');
in this case I'm inheriting the blueprint css styles then adding my custom styles below that.
在本例中，我将继承blueprint css样式，然后在其下面添加自定义样式。
In terms of JS libraries I prefer to link 3 files.
就JS库而言，我更喜欢链接3个文件。
The Library, one page with all of the plugins, and finally the page code.
库，一个包含所有插件的页面，最后是页面代码。
For directory structure I generally have the following:
对于目录结构，我一般有以下几点:
/_css /_images /_scripts files
/ _css / _images / _scripts文件
but recently I've began to put everything used to make the site look/work the way I want it to in a /_presentation directory... then anything additional like images for blog posts etc would go in /images
但是最近，我开始将所有用于使站点看起来/工作起来的东西放在/_presentation目录中……然后任何其他的东西，如博客文章的图片等，都会进入/图片
Hope this helps.
希望这个有帮助。
#6
0
I always try to keep the browser from having to load and interpret CSS rules and JS code that isn't used on the HTML in question. I agree with @bobince that you should only break a page's styles and scripts into a separate file if it's necessary for organization, but if your site is very big at all, you will reach that point.
我总是尽量避免浏览器必须加载和解释CSS规则和JS代码，这些在HTML中没有使用。我同意@bobince的观点，如果需要进行组织，您应该将页面的样式和脚本拆分为单独的文件，但是如果您的站点非常大，那么您将达到这一点。
However since I only build template based sites, I am beginning to wonder why I link to external files at all. For example, if I have a base template the things I put in the head of that template will be applied to all the pages on my site. So why not just put my styles and scripts there?
然而，由于我只构建基于模板的站点，我开始怀疑为什么我要链接到外部文件。例如，如果我有一个基本模板，我放在模板头部的东西将应用到我网站上的所有页面。那么为什么不把我的样式和脚本放在那里呢?
Two reasons come to mind. First the browser can cache the external file and reuse it on every page that includes it without having to load it all over again. Second designers might not be as comfortable poking around in your templates as they are messing with plain CSS files.
有两个原因。首先，浏览器可以缓存外部文件并在包含它的每个页面上重用它，而不必重新加载它。第二设计师可能不会像在普通CSS文件中乱翻一样轻松地在模板中翻找。
That's all well and good for global styles that apply to every single page in your site, but what about those one-off pages that have some style that isn't shared anywhere else? If you added this style to a globally applied external file you'd increase the initial load time of your site just to have a style that is only used on one page. Further, when you go back to that file months later you will likely have forgotten what those rules were even for.
这对于适用于站点中的每一个页面的全局样式来说都很好，但是那些具有其他地方没有共享的样式的一次性页面呢?如果您将此样式添加到全局应用的外部文件中，您将增加站点的初始加载时间，使其具有只在一个页面上使用的样式。此外，当您在几个月后回到该文件时，您可能已经忘记了这些规则的作用。
I suggest that any style rule that is not expressed on every single page should be placed in <style> tags within the sub-template that renders the HTML the rule applies to. This will move the load and complexity from the global stylesheet to the actual page where the styles are needed, and give the rules context so that they can be maintained in the future. If this scares your designer they don't need to be writing CSS anyway. Just tell them to stick to Photoshop and let you do the big-boy work.
我建议，任何没有在每个页面上表达的样式规则都应该放在子模板中呈现规则应用的HTML的