Note that there are some explanatory texts on larger screens.

plurals
  1. POPut all styles in css files vs Mixed structure
    primarykey
    data
    text
    <p>I am told that the good pattern is to put all styles in css files because blah and blah (you can search the reason in google since it's a very popular idea). However, I am a person always asking why when people trying to sell. Based on my own experience with some project. I think putting all styles in files are harder to maintain, since there are some inheritable or page specific styles.</p> <p>For example I have a control to display terms and conditions:</p> <pre><code>.TermsAndConditions { background-clip: padding-box; border: 1px solid #CFC2A7; border-radius: 5px 5px 5px 5px; box-shadow: 0 1px 1px rgba(0, 0, 0, 0.1), 0 1px rgba(255, 255, 255, 0.6) inset, 1px 0 rgba(255, 255, 255, 0.3) inset, -1px 0 rgba(255, 255, 255, 0.3) inset; height: 26px; line-height: 26px; padding: 0 10px; text-align: center; text-decoration: none; vertical-align: middle; white-space: nowrap; position:absolute; top: 0px; left:0px; } </code></pre> <p>When I need to use it on two of my pages I have to create two specific classes for it:</p> <pre><code>.HomePageTermsAndConditions { position: static; bottom: 20px; right:30px; } .ImagePreviewPageTermsAndConditions { position:absolute; top: 50px; left:60px; } Home page: &lt;div class="TermsAndConditions HomePageTermsAndConditions"&gt; &lt;/div&gt; Preview page: &lt;div class="TermsAndConditions ImagePreviewPageTermsAndConditions"&gt; &lt;/div&gt; </code></pre> <p>Absolutely no styles inline, but there are some problems:</p> <ol> <li><p>Position information is not shared at all, so the performance gain is very limited based on the network speed nowadays. (e.g. clear: left)</p></li> <li><p>Some styles are not even inheritable, so we have to create css classes for each level, which doesn't save effort.</p></li> <li><p>Hard to maintain, since css classes in files may be inherited or overridden by on another page, when editing a class it’s hard to know what effect it may cause, so it takes times to do testing/debug/fixing round trip.</p></li> <li><p>Hurt performance, some css class will remain there when the page using it is removed. It takes effort to clean them.</p></li> </ol> <p>So what I proposed is to move page/tag specific styles (like position info) inline like this:</p> <pre><code>.TermsAndConditions { background-clip: padding-box; border: 1px solid #CFC2A7; border-radius: 5px 5px 5px 5px; box-shadow: 0 1px 1px rgba(0, 0, 0, 0.1), 0 1px rgba(255, 255, 255, 0.6) inset, 1px 0 rgba(255, 255, 255, 0.3) inset, -1px 0 rgba(255, 255, 255, 0.3) inset; height: 26px; line-height: 26px; padding: 0 10px; text-align: center; text-decoration: none; vertical-align: middle; white-space: nowrap; } &lt;div class="TermsAndConditions" style="position:absolute; bottom: 20px; right:30px;"&gt; &lt;/div&gt; &lt;div class="TermsAndConditions" style="position: static; top: 50px; left:60px;"&gt; &lt;/div&gt; </code></pre> <p>Benifits we can get:</p> <ol> <li><p>No page specific information in classes. Doesn’t hurt performance since only several styles are in the page</p></li> <li><p>Easier to maintain, since inline style has higher priority, editing an inline style will immediately bring the effect on UI. Also you don’t need to worry about breaking other pages.</p></li> <li><p>When we need to remove a page, we usually don’t need to clean the css. Since page specific css are in the page, it goes with the page. Things in the css files are more likely to be shared.</p></li> <li><p>More object-oriented. Since css classes in files have no page specific information, they are more like a control by itself. It’s easy to plug in to other pages.</p></li> </ol> <p>For example:</p> <p>When I need it on a new page, I just copy the html and change the style inline:</p> <pre><code>&lt;div class="TermsAndConditions" style="position: absolute; top: 50px; left:60px;"&gt; &lt;/div&gt; </code></pre> <p>This is my idea against "putting all styles in css files". I am hoping to see your ideas about it, either good sides or bad sides.</p> <p>Thanks</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload