blocks|key|315703|text|Web开发肯定会带来一些组织上的挑战。HTML/CSS并不是拆分工作的理想环境。定义某些规则并严格遵守它们是非常重要的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|315704|我个人的策略是在共享源(如CSS或标记组件)中的名称前面加上一些模块后缀。如果您坚持使用该策略，它将使名称全局唯一。|315705|例如：|315706|而不是|315707|div.question_title
div.question_body|code-block|syntax|javascript|315708|你可以使用|315709|div.so_question_title
div.so_question_body

div.su_question_title
div.su_question_body|315710|在一些共享数据上，如配色方案的颜色，也与团队达成一致。在全局的某个地方定义它们，并在任何地方重用它们。|315711|当团队在同一页面的不同部分工作时，另一个问题就出现了。在这里，如果你正在开发一个页面组件，有一天你可能会发现一些东西被破坏了，因为在页面本身工作的人改变了一些东西，并且改变向下传播到元素层次结构中。|315712|例如，如果您以这种方式定义CSS样式：|315713|div.main_news+*
{
++++/*+...+*/
}|315714|这将是自找麻烦。我建议您通常使用尽可能小的范围来定义CSS样式，这对于某些技术来说是足够的。|315715|一种可能的解决方法是:每个子模块首先重置其顶级层次结构元素的所有样式，例如：|315716|div.news_container
{
++++/*+Reset+styles+*/
}|315717|因此，您现在可以在模块上工作，从而确保某些父元素中的更改将在您的边界上停止。|315718|更新:关于带有UID的div。如果你指的是Facebook，我不确定你指的是什么UID。只有隐藏的输入有一些长的隐含的ID作为它们的值(主页，没有登录)，但这可能是框架出于某种原因自动生成这些值的结果。我曾经为helpers编写了一些代码(用于ASP.NET+MVC)，以便在应用程序范围内生成唯一的I(我想完全自动且透明地为我绑定带有I标签的复选框)。另一种情况是，有状态事件驱动框架(如ASP.NET+WebForms)将生成的惟一ID作为支持其操作的要求。每个控件都必须有一些唯一的ID，这样才能在服务器端知道哪个元素在页面上引发了事件。此外，当您将元素拖放到表单中时，一些WYSIWYG编辑器会向元素添加自动ID。|315719|抛开这些不谈，当然也可以使用一些预先构建的脚本来检查代码，并将唯一的is注入到标记和CSS代码部分。但是你真的需要确切地知道你在做什么和为什么要这样做。我个人认为，这种“唯一性”通常可以通过在团队中强制执行一些简单的规则来手动实现，而一些工作当然可以自动化，就像我上面描述的那样。|315720|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1C|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1D|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1E|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|1F|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|1G|8|@]|9|@]|A|$K|L]]|$1|M|3|N|5|6|7|1H|8|@]|9|@]|A|$]]|$1|O|3|P|5|J|7|1I|8|@]|9|@]|A|$K|L]]|$1|Q|3|R|5|6|7|1J|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|1K|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|1L|8|@]|9|@]|A|$]]|$1|W|3|X|5|J|7|1M|8|@]|9|@]|A|$K|L]]|$1|Y|3|Z|5|6|7|1N|8|@]|9|@]|A|$]]|$1|10|3|11|5|6|7|1O|8|@]|9|@]|A|$]]|$1|12|3|13|5|J|7|1P|8|@]|9|@]|A|$K|L]]|$1|14|3|15|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|16|3|17|5|6|7|1R|8|@]|9|@]|A|$]]|$1|18|3|19|5|6|7|1S|8|@]|9|@]|A|$]]|$1|1A|3|-4|5|6|7|1T|8|@]|9|@]|A|$]]]|1B|$]]

Web development definitely brings some organizational challenge. HTML/CSS is not exactly the dream environment for splitting work. It is very important to define certain rules and strictly follow them.

My personal tactic I have come to is to prefix the names in shared sources (like CSS or markup components) with some module suffix. If you keep to the strategy, it will uniquify the names globally.

For example:

instead of

<pre><code>div.question_title
div.question_body
</code></pre>

you could use

<pre><code>div.so_question_title
div.so_question_body

div.su_question_title
div.su_question_body
</code></pre>

Also agree with teams on some shared data like colors of the color scheme. Define them somewhere globally and reuse them everywhere.

Another issue arrives when teams are working on different parts of the same page. Here if you're developing a page component, you may find one day something is broken because the guys working on the page itself changed something and changes propagated down the element hierarchy.

For example, if you define a CSS style in this manner:

<pre><code>div.main_news *
{
 /* ... */
}
</code></pre>

it would be asking for trouble. I suggest that you have at as a rule to define CSS styles with the minimum possible scope which is sufficient for some technique to work.

One possible workaround: each submodule firstly resets all the styles for its top-level hierarchy element, like:

<pre><code>div.news_container
{
 /* Reset styles */
}
</code></pre>

so that you can now work on the module resting assured the changes in some parent elements would be stopped at your perimeter.

UPDATE: Regarding divs with UIDs. If you mean Facebook, I'm not sure what UIDs you are referring to. Only hidden inputs have some long cryptic IDs as their values (main page, not logged in), but this is likely the result of the framework automatically generating these values for some reason. I once wrote some code (for ASP.NET MVC) for Html helpers to generate unique IDs application-wide (I wanted to bind checkboxes with labels by IDs completely automatically and transparently for me). Another case could be that a stateful event-driven framework (such as ASP.NET WebForms) has unique IDs generated server side as a requirement to support its operation. Each control has to have some unique ID so that it is possible to know on the server side which element raised an event on a page. Also some WYSIWYG editors would add auto IDs to elements when you drag them and drop to a form.

This all aside, it is of course possible to have some pre-build script to go over the code and inject unique IDs into markup and CSS code portions. But you really need to know exactly what and why you are doing this. I'm personally of the opinion this "uniquization" in general can be achieved manually by enforcing some simple rules in a team, while some work can of course be automatized, like what I described above.

blocks|key|317769|text|我的公司做业务网络应用程序。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|317770|大多数时候，我们使用具有ADF或PHP前端的SOA体系结构，因此如何命名并不重要，因为大多数HTML都是从组件呈现的(它减少了您在免费HTML中的自由度，但使其开发更快)。|317771|此外，我们的团队不是按主题组织的，他们被放在不同的技术领域，如数据库，图形用户界面或性能。|317772|最大的好处是，您可以在不同的应用程序中重用一些Web服务，而不必联系原始开发人员。|317773|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

My company does Business Web Applications.

Most of the times we use a SOA Architectre with ADF or PHP frontend, so it does not matter how things are named, because most of the HTML is rendered from components (It reduces the freedom you have in free HTML, but makes it faster to develop).

Also our Teams are not organized by Topics, they are put in different technical areas, like Database, GUI or Performance.

The big advantage is, that you can reuse some of the Web-services in different Applications, without having to contact to original developer.

blocks|key|3058721|text|根据我的经验，无论你如何努力标准化所有的东西，对于大团队来说，每个人都以同样的方式做同样的事情几乎是不可能的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3058722|不要试图在“标准级别”或“如何”级别解决问题……在人的层面上，在管理层面上解决它。|3058723|我们使用几种技术来维护管理层的一致性：|3058724|3058725|维护开发人员通知其他人的工具。这包括维基、内部论坛等等，|unordered-list-item|3058726|有足够的中层管理人员可用。没有人能意识到一切，但对一个人来说，意识到他所处的水平的一切是有意义的。这样，用户管理组可以与安全组同步，安全组可以与内容管理组同步。这个中层管理人员的任务是对每件事都有足够的了解，他们不需要知道每一个细节，只要足够把它应该在哪里的知识传递给它就行了。|3058727|按你认为合适的方式添加级别，但在每个级别中都应该有一个人查看每个人或多或少都在做同样的事情。他将负责在两个团队以完全不同的方式做事情时发出警报。|3058728|保持良好的信息流。有标准很重要，但让人们真正知道他们退出了更好，并确保他们使用它们，通过代码修订和每周会议是完全必要的，如果你想继续做正确的事情。|3058729|3058730|我知道很多人不喜欢“管理”。他们认为这是额外的一层，什么也不做。好吧，那不是真的。管理有助于解决这样的问题。帮助与大型团队沟通，并对正在发生的事情有一个大致的看法……有很多“技术”来定义如何做事情的标准……当没有人员确保人们遵循、了解和遵循这些标准时，所有这些技术都会失败。|offset|length|style|BOLD|3058731|entityMap^0|0|0|0|0|0|0|0|0|0|2Y|V|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Z|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|10|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|11|8|@]|9|@]|A|$]]|$1|G|3|H|5|I|7|12|8|@]|9|@]|A|$]]|$1|J|3|K|5|I|7|13|8|@]|9|@]|A|$]]|$1|L|3|M|5|I|7|14|8|@]|9|@]|A|$]]|$1|N|3|O|5|I|7|15|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|16|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|17|8|@$S|18|T|19|U|V]]|9|@]|A|$]]|$1|W|3|-4|5|6|7|1A|8|@]|9|@]|A|$]]]|X|$]]

From my experience, no matter how well you try to standardize everything, for big teams complete coherence, with everyone doing the same things the same way is almost impossible. 

Don't try to solve the problem at the "standards level" or the "how to" level... solve it at the human level, at the management level.

We use a couple of techniques to maintain coherence at the management level:

<ul>
<li>Maintain the tools for the developer to inform the rest. That includes Wikis, internal discussion forums and so on.</li>
<li>Have enough middle management available. No body can be aware of everything but it makes sense for a person to be aware of everything that is at his level. That way the User Management group can sync with the Security group and the Security Group can be in sync with the Content Management group. The mission of this middle management is to know enough about everything, the do not need to know every detail, just enough to pass it the knowledge where it should be.</li>
<li>Add levels as you see fit, but in every level there should be one person looking up everyone is doing more or less the same things. He will be in charge to raise alarms if two groups are doing things in completely different ways.</li>
<li>Maintain a good information flow. Having standards is important but allowing people to actually KNOW they exits is even better and ensuring they use them, through code revision and weekly meeting is completely needed if you want to keep doing things rigth.</li>
</ul>

I know a lot of people do not like "management". They think is an extra layer that does nothing. Well, that ain't true. Management helps to solve problems like exactly this. Help to communicate big teams and have a general view of what's happening... there are a lot of "techniques" to define a standard on how to do things... all that techniques fail when there isn't a human being making sure people follow know and follow those standards.

blocks|key|317819|text|像Shaun+Inman的CSScaffold这样的CSS框架有很多要说的。它可以让你细分样式表，定义常量，轻松处理本地上下文等。它不能解决你的问题，但它可以是一个很大的帮助。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|317820|在Javascript方面，可以使用本地上下文，尽管我很少遇到问题。|317821|HTML元素的命名肯定很棘手，但HTML5应该会有所帮助(只需要更少的id和类)，并且您提到的预编译可以是另一种选择。|317822|entityMap|0|LINK|mutability|MUTABLE|url|http://www.shauninman.com/archive/2009/02/09/csscaffold^0|D|A|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@$A|Q|B|R|1|S]]|C|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|C|$]]]|I|$J|$5|K|L|M|C|$N|O]]]]

There is a lot to be said for CSS Frameworks like Shaun Inman's <a href="http://www.shauninman.com/archive/2009/02/09/csscaffold" rel="nofollow noreferrer">CSScaffold</a>. It lets you subdivide stylesheets, define constants, easily handle local contexts, etc. It doesn't solve your problem, but it can be a big help.

On the Javascript side, it is possible to work with local contexts, although I've rarely if ever run into problems.

Naming of HTML elements is definitely tricky, but HTML 5 should help (fewer id's and classes are necessary) and precompilation as you mention can be another option.

blocks|key|314817|text|根据我的经验，我参与了几个单页面web应用程序项目|type|unstyled|depth|inlineStyleRanges|entityRanges|data|314818|您的diff团队应该坐下来设置一些简单的css约定|314819|例如|314820|mod-search.css|314821|.mod-search+.title+{+}
.mod-search+.text+{+}|code-block|syntax|javascript|314822|mod-news.css|314823|.mod-news+.title+{+}
.mod-news+.text+{+}|314824|在生产环境中，使用您最喜欢的前端将所有资源集中在一起|314825|对js也是如此，实际上js比css更容易管理。|314826|确保每个模块都包装在自己的闭包中|314827|我以YUI为例|314828|mod-search.js|314829|(function(){
+++var+node+=+Y.Node.create('<div/>').addClass('mod-search');+
+++//+hook+your+event+to+this+module+node+only
+++node.delegate('click',+handleSearch,+'button.search');
}());|314830|mod-news.js|314831|(function(){
+++var+node+=+Y.Node.create('<div/>').addClass('mod-news');+
+++//+hook+your+event+to+this+module+node+only
+++node.delegate('click',+handleViewNews,+'a.view-news');+
}());|314832|all-in-one.js.php|314833|//
//+php+set+content+type+text/javascript
//
YUI().use('node',+'event',+function(Y){
+++//+php+include+mod-new.js
+++//+php+include+mod-search.js
});+|314834|HTML|314835|<html>
++++<head>
++++++++<link+href='all-in-one.css.php'+rel='stylesheet'+/>
++++</head>
++++<body>
++++++++<script+src='all-in-one.js.php'+></script>
++++</body>
</html>|314836|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1G|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1H|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1I|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|1J|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|1K|8|@]|9|@]|A|$K|L]]|$1|M|3|N|5|6|7|1L|8|@]|9|@]|A|$]]|$1|O|3|P|5|J|7|1M|8|@]|9|@]|A|$K|L]]|$1|Q|3|R|5|6|7|1N|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|1O|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|1P|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|1R|8|@]|9|@]|A|$]]|$1|10|3|11|5|J|7|1S|8|@]|9|@]|A|$K|L]]|$1|12|3|13|5|6|7|1T|8|@]|9|@]|A|$]]|$1|14|3|15|5|J|7|1U|8|@]|9|@]|A|$K|L]]|$1|16|3|17|5|6|7|1V|8|@]|9|@]|A|$]]|$1|18|3|19|5|J|7|1W|8|@]|9|@]|A|$K|L]]|$1|1A|3|1B|5|6|7|1X|8|@]|9|@]|A|$]]|$1|1C|3|1D|5|J|7|1Y|8|@]|9|@]|A|$K|L]]|$1|1E|3|-4|5|6|7|1Z|8|@]|9|@]|A|$]]]|1F|$]]

i worked with several one-page-web-app projects, from my experience

your diff teams should sit down once to setup some simple css convention 

for example 

mod-search.css

<pre><code>.mod-search .title { }
.mod-search .text { }
</code></pre>

mod-news.css

<pre><code>.mod-news .title { }
.mod-news .text { }
</code></pre>

in production use your fav front end do lump all the resources into one 

also do the same to js, actually js is easier to manager than css 

make sure each module is wrapped in its own closure 

i am using YUI as an example 

mod-search.js

<pre><code>(function(){
 var node = Y.Node.create('&lt;div/&gt;').addClass('mod-search'); 
 // hook your event to this module node only
 node.delegate('click', handleSearch, 'button.search');
}());
</code></pre>

mod-news.js 

<pre><code>(function(){
 var node = Y.Node.create('&lt;div/&gt;').addClass('mod-news'); 
 // hook your event to this module node only
 node.delegate('click', handleViewNews, 'a.view-news'); 
}());
</code></pre>

all-in-one.js.php 

<pre><code>//
// php set content type text/javascript
//
YUI().use('node', 'event', function(Y){
 // php include mod-new.js
 // php include mod-search.js
}); 
</code></pre>

the HTML

<pre><code>&lt;html&gt;
 &lt;head&gt;
 &lt;link href='all-in-one.css.php' rel='stylesheet' /&gt;
 &lt;/head&gt;
 &lt;body&gt;
 &lt;script src='all-in-one.js.php' &gt;&lt;/script&gt;
 &lt;/body&gt;
&lt;/html&gt;
</code></pre>

blocks|key|314838|text|当多个团队开发UI时，应该记录UI约定。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|314839|最好是让相同的团队为所有组件编写/设计UI，然后根据需要拆分其他层。|314840|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

UI conventions should be documented when multiple teams are developing UIs. 

Preferably you should have the same team write/design the UI for all components, then break up the other layers as needed.

blocks|key|3272049|text|命名空间冲突问题可以通过使用命名约定来避免。其他阅读：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3272050|3272051|CSS+Practice:+Pseudo-Namespaces+in+Complex+Projects+|unordered-list-item|offset|length|3272052|CSS+Namespaces+Support+-+Functional+and+Design+Specification|3272053|3272054|简而言之:这取决于你的系统是如何构建的，但假设所有东西都是由模块组成的，然后给你的CSS标识符(或JS等)命名。如下:+SiteName-ModuleName-Function。|3272055|如果您愿意使用您的应用程序语言(例如PHP)来干预CSS/JS代码，那么可以使用“任意”命名，方法是为每个模块分配其动态生成的数字id，并将该id附加到客户端语言对象的标识符。例如：|3272056|#+PHP+script
class+module_articles+{
++++public+function+__construct()+{
++++++++$this->GUI+=+new+view;
++++}
++++public+function+display_articles()+{
++++++++//+The+CSS+file+is+rendered+first+by+the+PHP+engine+and
++++++++//+the+identifiers+name+is+constructed+with+the+$this->GUI->id+property.
++++++++$this->GUI->load_css('path/to/file.css');
++++}
}

class+view+{
++++private+static+$instance_number+=+0;
++++public+$id;

++++public+function+__construct()+{
++++++++$this->id+=+%2B%2B+self+::+$instance_number;
++++}
++++public+function+load_css($path)+{
++++++++//+$id+can+also+be+the+CSS+file+path+(slashes+replaced+with+underscore)
++++++++//+or+the+module+name+itself+(e.g.+module_articles)
++++++++$id+=+$this->id;
++++++++include+$path;
++++}
}|code-block|syntax|javascript|3272057|最终，CSS文件应该是这样的：|3272058|/*+CSS+of+module_articles+*/

<?php+echo+$id+?>author_name+{+/*...*/+}
<?php+echo+$id+?>article_date+{+/*...*/+}|3272059|注意:文件应该通过PHP的include关键字来包含！稍后使用Output+Buffering输出它。|3272060|entityMap|0|LINK|mutability|MUTABLE|url|http://meiert.com/en/blog/20070321/css-practice-pseudo-namespaces-in-complex-projects/|1|http://opensource.adobe.com/wiki/display/flexsdk/CSS%2BNamespaces%2BSupport|2|http://php.net/manual/en/ref.outcontrol.php^0|0|0|0|1F|0|0|0|1O|1|0|0|0|0|0|0|0|V|G|2|0^^$0|@$1|2|3|4|5|6|7|1B|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|1C|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|1D|8|@]|9|@$F|1E|G|1F|1|1G]]|A|$]]|$1|H|3|I|5|E|7|1H|8|@]|9|@$F|1I|G|1J|1|1K]]|A|$]]|$1|J|3|-4|5|6|7|1L|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|1M|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|1N|8|@]|9|@]|A|$]]|$1|O|3|P|5|Q|7|1O|8|@]|9|@]|A|$R|S]]|$1|T|3|U|5|6|7|1P|8|@]|9|@]|A|$]]|$1|V|3|W|5|Q|7|1Q|8|@]|9|@]|A|$R|S]]|$1|X|3|Y|5|6|7|1R|8|@]|9|@$F|1S|G|1T|1|1U]]|A|$]]|$1|Z|3|-4|5|6|7|1V|8|@]|9|@]|A|$]]]|10|$11|$5|12|13|14|A|$15|16]]|17|$5|12|13|14|A|$15|18]]|19|$5|12|13|14|A|$15|1A]]]]

A namespace clashes problem can be avoided by using a naming convention. Additional reading: 

<ul>
<li><a href="http://meiert.com/en/blog/20070321/css-practice-pseudo-namespaces-in-complex-projects/" rel="nofollow noreferrer">CSS Practice: Pseudo-Namespaces in Complex Projects</a> </li>
<li><a href="http://opensource.adobe.com/wiki/display/flexsdk/CSS+Namespaces+Support" rel="nofollow noreferrer">CSS Namespaces Support - Functional and Design Specification</a></li>
</ul>

In short: It depends how your system is built, but assuming that everything is composed out of modules, then name your CSS identifiers (or JS IDs etc.) as follows: SiteName-ModuleName-Function.

If you're willing to use your application language (e.g. PHP) to intervene with the CSS/JS code, then an "arbitrary" naming may be used, by assigning each module it's dynamically-generated numeric id and attaching that id to the identifier of the client-side language object.
For instance:

<pre><code># PHP script
class module_articles {
 public function __construct() {
 $this-&gt;GUI = new view;
 }
 public function display_articles() {
 // The CSS file is rendered first by the PHP engine and
 // the identifiers name is constructed with the $this-&gt;GUI-&gt;id property.
 $this-&gt;GUI-&gt;load_css('path/to/file.css');
 }
}

class view {
 private static $instance_number = 0;
 public $id;

 public function __construct() {
 $this-&gt;id = ++ self :: $instance_number;
 }
 public function load_css($path) {
 // $id can also be the CSS file path (slashes replaced with underscore)
 // or the module name itself (e.g. module_articles)
 $id = $this-&gt;id;
 include $path;
 }
}
</code></pre>

Eventually, the CSS file should be something like this:

<pre><code>/* CSS of module_articles */

&lt;?php echo $id ?&gt;author_name { /*...*/ }
&lt;?php echo $id ?&gt;article_date { /*...*/ }
</code></pre>

Note: The file should be included via PHP's include keyword! Use <a href="http://php.net/manual/en/ref.outcontrol.php" rel="nofollow noreferrer">Output Buffering</a> to output it later.

blocks|key|3058853|text|这不是应该在飞行中发生的事情，它是在公司结构中烘焙的。不知道Facebook或任何其他特定的网站/公司是如何做到这一点的，但它可以像维护单个数据库表一样简单。像这样：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3058854|project_namespace|3058855|3058856|id|unordered-list-item|3058857|namespace|3058858|directory|3058859|3058860|这样，您就有了自己的核心应用程序(1，'+core+'，'/htdocs/core')。可能有一位PM或高级管理人员负责它，一些猴子来创建和维护它-一个额外的数据库表，如果HR还没有管理这种关系，但这在这里是无关紧要的。每个名称空间都需要一个公共结构，即CSS文件的./css、HTML模板的./template、./js、./images等等。同样，可以有一个db表用于此，但与本例无关。添加任意数量的其他团队-+search+(2，'search'，'/htdocs/search')，accounts+(3，'users'，'/htdocs/users')，web服务团队(4，'+services+'，'/htdocs/services/')等等。每个值都是唯一的，我只是在编造，所以请忽略细节的缺失。|3058861|现在你已经有了你的构建过程--一个或一系列的脚本，它从源代码控制中提取所有东西，运行CSS和JS缩微器，通常将所有不同的部分编译到一个网站中。它从db表中加载名称空间，并将它们(或仅唯一ID+)添加到每个相关的CSS规则、HTML元素ID、Javascript类或所需的任何内容。"core“命名空间可能会有一些特殊的规则，允许其他命名空间调用它，一种元API(同样与示例不太相关，但很现实)。|3058862|这至少是它的要点，但它不一定涉及我刚才提到的任何东西。对于一些团队来说，这可能只是一个电子邮件提醒"FTP你的更改在这里，但你最好不要覆盖我的东西“，而对另一些团队来说，它是一个三环活页夹，规则由严格的装配线实现，连接到任意数量的bug跟踪器和代码审查工具，自动机执行单元测试，处理makefile和检查权限等等。我猜Facebook更倾向于后者。|3058863|长话短说：信息组织和用于维护它的构建流程。|offset|length|style|BOLD|3058864|因此，是的，每个人都可以(也应该)知道其他人如何命名他们的div标记&+JS函数和其他所有重要的东西，这要归功于这个不祥的MCP实体，它维护规则并分发名称。有了正确的流程和工具，你永远不会不知道。|3058865|entityMap^0|0|0|0|0|0|0|0|0|0|0|5|4|G|4|0|0^^$0|@$1|2|3|4|5|6|7|12|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|13|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|14|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|15|8|@]|9|@]|A|$]]|$1|H|3|I|5|G|7|16|8|@]|9|@]|A|$]]|$1|J|3|K|5|G|7|17|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|18|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|19|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|1A|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1B|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|1C|8|@$U|1D|V|1E|W|X]|$U|1F|V|1G|W|X]]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|1H|8|@]|9|@]|A|$]]|$1|10|3|-4|5|6|7|1I|8|@]|9|@]|A|$]]]|11|$]]

This isn't something that should happen on the fly, it's baked in the company structure. No telling how Facebook or any other specific site/company does it, but it can be as simple as maintaining a single database table. Like:

project_namespace

<ul>
<li>id</li>
<li>namespace</li>
<li>directory</li>
</ul>

So, you've got your core application (1, 'core', '/htdocs/core'). There's probably a PM or senior in charge of it, and some monkeys to create &amp; maintain it - an extra database table if HR isn't already managing that relation, but that's irrelevant here. Each namespace would require a common structure, ./css for CSS files, ./templates for HTML templates, ./js, ./images, and so on. Again, there can be a db table for that, but irrelevant to this example. Add any number of other teams - search (2, 'search', '/htdocs/search'), accounts (3, 'users', '/htdocs/users'), the web services guys (4, 'services', '/htdocs/services/') and so on. Each value is unique, and I'm just making this up so please ignore the lack of detail.

Now you've got your build process - a script or series of scripts that pulls everything from source control, runs the CSS and JS minifiers, and generally compiles all the disparate parts into a website. It loads the namespaces from the db table and prepends them (or just the unique IDs) to every relevant CSS rule, HTML element ID, Javascript class, or whatever is needed. The "core" namespace would probably have some special rules, allowing other namespaces to call on it, sort of a meta-API (again not so relevant to the example, but realistic).

That's the gist of it at least, but it doesn't necessarily involve anything I just mentioned. For some teams that could just be an email reminder of "FTP your changes here, but jerk you best not overwrite my stuff," and for others it's a 3-ring binder of rules implemented with a rigid assembly line, wired to any number of bug trackers and code review tools, of automata performing unit tests and processing makefiles and checking permissions and so on and so forth. I'd guess Facebook leans more to the latter.

Long story short: information organization and a build process to maintain it.

So yes, everyone can (and should) be aware of what others are naming their div tags &amp; JS functions and everything else important, thanks to this ominous MCP-looking entity maintaining the rules and handing out the names. With the right process and tools, you'll never not know.

blocks|key|312733|text|如果你真的想知道，只需打开firebug并通过facebook网站进行洞穴探索。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|312734|30秒后，您会发现他们很少通过ID将css应用于div；而是大量使用点类表示法。|312735|一旦你沿着这条路走下去，将开发组划分成功能就容易得多了。你可以有一个核心组负责使用ID的主要“外壳”，其他所有人都必须使用点类。|312736|您可以通过为每个组指定一个工作前缀来进一步限制它。|312737|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

If you really want to know, just open up firebug and go spelunking through the facebook site.

30 seconds later you'll find out they rarely apply css to divs through IDs; and instead use a lot of the dot class notation. 

Once you go down this path, separating dev groups into functionality is a whole lot easier. You can have one core group that is responsible for the main "shell" using ID's. Everyone else you force to use dot classes. 

You can further restrict this by giving each group a prefix to work in.

blocks|key|315828|text|一些应用程序使用用作代理的门户服务器。它位于所有这些web/应用程序服务器的前面。门户服务器获取这些服务器的HTML数据/提要，然后向标记添加前缀/后缀，使其具有唯一性。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|315829|在某种程度上，你是正确的，有一个组件来处理这些事情。|315830|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Some applications use a portal server which is used as a proxy. It sits in front of all these web/application servers. The portal server gets the data/feeds of HTML these servers and then adds a prefix/suffix to the tags making them unique.

In a way you are correct, there is a component which handles such things.

I was wondering how big companies tend to modularize components on their page. Facebook is a good example:

<blockquote>
 There's a team working on Search that
 has its own CSS, javascript, html,
 etc.. 
 
 There's a team working on the news
 feed that has its own CSS, javascript,
 html, etc...
 
 ... And the list goes on
</blockquote>

They cannot all be aware of what everyone is naming their div tags and whatnot, so what's the controller(?) doing to hook all these components in on the final page??

Note: This doesn't just apply to facebook - any company that has separate teams working on separate components has some logic that helps them out.

EDIT: Thanks all for the responses, unfortunately I still haven't really found what I'm looking for - when you check out the source code (granted its minified), the divs have UIDs, my guess is that there is a compilation process that runs through and makes each of the components unique, renaming divs and css rules.. any ideas?

EDIT 2: Thanks all for contributing your thoughts - the bounty went to the highest upvoted answer. The question was designed to be vague- I think it led to a really interesting discussion. As I improve my build process, I will contribute my own thoughts and experiences.

Thanks all!
Matt Mueller

Modularizing web applications

单元测试

数据库

服务器

HTML5

我想知道大公司是如何在他们的页面上模块化组件的。Facebook就是一个很好的例子：有一个致力于搜索的团队，他们有自己的CSS、javascript、html等。有一个团队正在开发新闻提要，它有自己的CSS，javascript，html等……..。这份清单还在继续他们不可能都知道每个人都在给他们的div标签和诸如此类...

问模块化web应用程序
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问模块化web应用程序EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问模块化web应用程序
EN