I'm looking to see if anyone has ever had any experience with this CSS syntax debate we are currently having on our team. Our dev team has been using the vim plugin Tabular to align text in our code. For example in PHP or Javascript we will align variable declarations using the plugin like this:
$count = 0;
$var_1 = array();
$var_2_long_name = array();
$stdout = fopen( 'php://stdout', 'w' );
$some_data = json_decode( $some_json_data, true );
Helps the code look clean and easy to read.
We have considered using alignment in our CSS (we are using LESS but this question could be applied to SASS or just straight CSS). For example we would change this block:
.btn-section {
position: relative;
top: -65px;
display: block;
z-index: 100;
.content-box;
background-color: #grayButton;
color: #gray;
padding: 10px 0;
.border-radius(5px);
}
To this:
.btn-section {
position : relative;
top : -65px;
display : block;
z-index : 100;
background-color : #grayButton;
color : #gray;
padding : 10px 0;
.content-box;
.border-radius(5px);
}
One of the devs experimenting with this tactic moved the mixins from their original spots to the bottom of the declaration in order to make the code "look right" since mixins don't conform the the normal selector: value; format of regular css. In this case, the .content-box mixin had a background-color declaration that was being overridden by the backgroud-color line beneath it. Moving the mixin to the bottom broke the override and gave the element the wrong background color.
Errors like this coupled with the extra steps it takes to format every single block of CSS make me think this might not be such a good idea. Has anyone ever tried this type of alignment before? Any opinions on whether this is a good or bad idea? Thanks.
I think your alignment tactic is a good idea, I'd just recommend turning it upside down:
.btn-section {
.content-box;
.border-radius(5px);
position : relative;
top : -65px;
display : block;
z-index : 100;
background-color : #grayButton;
color : #gray;
padding : 10px 0;
}
That way the more general mixin styles would be applied first, after which they may be overridden by selection specific adjustments instead of the other way around.
By doing it like this, you eliminate this risk of accidently overriding specific styles with inherited ones and still keep everything neat and easy to read.
Related
I want to create custom css unit, that I'll be able to use in sass with node.js. Is there any guide about creating sass plugin for this? Just for example, I want to create unit "dpx", that will work as double pixel, so "width: 20dpx" will be processed to "width: 40px".
Other solution (not sass plugin), that can work with node is also acceptable.
Use a SASS function that accepts a font-size and returns the value doubled.
#function dpx($size) {
#return $size * 2;
}
div {
font-size: dpx(20px); // output: font-size: 40px;
}
As a simplified version of the current answer, you could also write the following:
$d: 2px;
div { font-size: 20*$d; }
I know this is an old question, but since I found it, other people will find it too.
In such case as yours a good solution would be to make a 1rem equal to 2px.
You can do it this way:
html {
font-size: 2px;
}
now each 1rem will be equal to 2px. If you want to make sure this doesn't break your current page, you can always add
body {
font-size: 8rem;
}
to set the global font-size to 16px (just a guess since this is a default value).
I wrote a pretty complicated widget that uses OnDemandList to create a widget that allows full editing (including adding) of a store.
Now... I am not exactly a CSS guru (quite the contrary), and would love some guidance, just to check that I am doings things in a semi-sane way.
When I create the editor in my widget, I do:
buildRendering: function(){
// ...
this.domNode = put( 'div' );
// ...
},
postCreate: function(){
// ...
// This is here, because if I set the class in buildRendering, it gets zapped by className (the widget's declaration)
put( this.domNode, '.editable-list' );
// ...
},
Then when an editor is added dynamically:
put( row.element, editingWidget.domNode );
put( editingWidget.domNode, '.editable-list-row-editor' );
I also need to make sure that each row has position:absolute so that the editor gets placed in the right spot:
domStyle.set( row.element, 'position', 'relative' );
In the CSS, I have:
.editable-list-row-editor {
position: absolute;
top: 0;
z-index: 20;
}
Questions:
1) Is it OK in terms of best practices to even add a style like I did with domStyle.set( row.element, 'position', 'relative' ); ...? Or shall I do that with CSS? I did it programmatically because it's really important that it's relative.
2) Is it OK in terms of CSS to leave things as non-specific as possible? The idea is that users might (and probably will) end up writing their own CSS, and overriding things by writing more specific rules... is that right? Or maybe I should have written:
.editable-list .editable-list-row-editor {
position: absolute;
top: 0;
z-index: 20;
}
Or better:
.editable-list .row-editor {
position: absolute;
top: 0;
z-index: 20;
}
...?
3) From what I am seeing, CSS classes for widgets should be set in postCreate rather than buildRendering, otherwise Dojo seems to use className to zap anything that was set there... is that what you'd normally do with a widget that creates its own domNode?
My personal opinion on the inline CSS vs CSS stylesheet is that I like to write everything in a seperate stylesheet. The reasoning behind this is that your code becomes cluttered with styling code, but when seperating concerns I think it would be better to write your CSS in a seperate file.
Of course, inline CSS is always the most specific one (the most important one), so if you really want to enforce something, you could add an !important to your CSS rule altought I would recommend use them not that much.
You should write your CSS as specific as possible, because you don't want to interfere with other widgets/HTML but you don't want the opposite as well (external CSS interfering with your widget). But of course, you can write things as:
.editable-list .row-editor {
position: absolute;
top: 0;
z-index: 20;
}
It mostly depends on what .row-editor actually means. If it's something "global", you could keep .row-editor, simply because it will allow you to define a global .row-editor which contains the CSS that is in common, while your .editable-list .row-editor will contain specific CSS rules for that widget.
For example, let's consider that you have another widget with a similar CSS:
.other-widget .row-editor {
position: absolute;
top: 0;
z-index: 25;
}
Then you could also write the following CSS:
.row-editor {
position: absolute;
top: 0;
}
.editable-list .row-editor {
z-index: 20;
}
.other-widget .row-editor {
z-index: 25;
}
But it actually depends on how you see the .row-editor class, if you think it's only specific to your editable list, then you might also consider prefixing it. It's similar to what Dojo already does, Dojo has global CSS classes like .dijitInline but also specific CSS classes like .dijitCalendarDateLabel.
If someone wants to change the style of the widget, he could add a parent class and so he will be able to make a more specific CSS selector. An example, let's say that the following is your CSS:
.editable-list .row-editor {
position: absolute;
top: 0;
z-index: 20;
}
Then someone who wants to change the CSS just adds a tag to a parent (for example the <body> tag):
<body class="myTheme">
<!-- Your HTML -->
</body>
And then specifies the following CSS:
.myTheme .editable-list .row-editor {
z-index: 30;
}
This will actually override your z-index. Dojo already uses this principle with their themes. When you want to use a specific theme, you add the theme CSS and add the name of the theme as a classname in your body, for example:
<body class="claro">
<!-- Your HTML -->
</body>
Of course you don't need to define it at body-level, as long as it's a parent node of your widget it will work.
About the issue about buildRendering vs postCreate, well, I suppose that you use the dijit/_TemplatedMixin mixin. If that's so, then if you look at the code and look for buildRendering you will see it's doing stuff. This means that if you write your own buildRendering you will actually replace their code with yours. If you want to make sure that Dojo executes its own logic first, you have to write something like:
buildRendering: function() {
this.inherited(arguments);
/** Your code */
}
That extra line of code will in fact call the same method of the inherited modules/mixins. You can do with that line what you want, if you don't want that the inherited modules are called, you leave it out (probably breaking it as well), if you want to execute it as the last step you just switch the this.inherited(arguments); to your last step in the buildRendering function (but then it might override your changes).
But in the end, this is all just an opinion and I'm sure that there are other opinions there that are also correct (for other or even similar use cases). But I can tell you that Dojo does things in a similar way for their own widgets, so maybe it's not a bad approach to follow it as well.
Sorry for the long answer, but I wrote it so that it might be useful for similar questions as well.
I've got a SCSS-based layout in which I want to use the spacing module from OOCSS.
The OOCSS module is pure CSS - ptl, for example, stands for padding-top: large, where large is a defined value (by default 20px).
I'd like to enhance it with SCSS. So far I've been able to replace the fixed values with SCSS variables, so I can change the values in one place if I want to (I don't want to):
$spacing-small: 5px;
$spacing-medium: 10px;
$spacing-large: 20px;
...
.pts,.pvs,.pas{padding-top:$spacing-small !important}
Now I'd like to be able to use ptn,pvs, etc. as mixins, so I can do this:
.client-name {
#include spacing-pvs; // this has the same padding properties as pvs
}
I'm flexible in the syntax, but that's the functionality I'd be interested in having.
The only way I can think of for doing this is manually defining every single mixin:
#mixin spacing-pvs {
padding-top: $spacing-small !important;
padding-bottom: $spacing-small !important;
}
.pvs { #include spacing-pvs; }
But there are around 56 styles/mixins. Doing each one individually like this would be pain to write and to maintain.
Is there a better way to do this in SASS/SCSS?
The most efficient mixin would be like this (you'll need a similar mixin for padding, or add an extra argument to switch between margin/padding):
#mixin marginify($t: null, $r: null, $b: null, $l: null) {
margin-top: $t;
margin-right: $r;
margin-bottom: $b;
margin-left: $l;
}
.test {
#include marginify($t: 10px, $b: 10px);
color: green;
}
Which generates this:
.test {
margin-top: 10px;
margin-bottom: 10px;
color: green;
}
The null (available in Sass 3.2+) is doing its magic here: if a variable is null, then it doesn't generate a property for it. However, you have to give up the use of !important (most people would argue that you should only use it as a last resort anyway). Reliance on this mixin is going to introduce a fair bit of bloat because the longhand form is always used over the shorthand (margin: 10px 0), so you'll need to use it responsibly or write a more powerful mixin that will generate the shorthand if appropriate.
That said, using a mixin for this purpose (adding margins) does reduce readability in your code. Before I looked at the entire source, the names made no sense. There's a lot to be said about the readability of vanilla CSS. The marginify mixin isn't really a reusable pattern like a clearfix or inline-menu mixin might be: writing a mixin isn't just about saving keystrokes.
I ended up not using mixins at all. Instead, I left the CSS rules as they were, and I used this less documented feature called #extend. Behold!:
.client-name {
#extend .pvs; // this has the same padding properties as .pvs
}
I'm currently getting headaches from this darn pseudo-element called :first-letter. It seems to be so helpful, but ultimately does not work the way I expected.
Here's an example on jsfiddle, how I tried and how it should look like:
FIDDLE is here
As you can see, :first-letter does nothing. I expected it to overwrite the normal link settings and also the :hover selector.
What could've possibly gone wrong? Any other idea how to achieve this only with CSS?
Instead of putting your "»" in the HTML you could put it in the CSS
http://jsfiddle.net/4DnKu/4/
a.one:before {
content: "»";
color:#0F0;
padding:0 5px 0 0;
}
IMHO it shouldn't be in the HTML either way, as it actually is only decoration.
Pseudo elements are supported by all major browsers, only one you'll have problems with is IE<8. There you could use CSS expressions as a workaround (handle with care!):
a.one {
*zoom: expression( (new Function('elem', '\
if(elem.before)\
return;\
elem.innerHTML = "<span class=ie7-before>»</span>" + elem.innerHTML;\
elem.before = true;\
elem.style.zoom = "1";\
'))(this) );
}
a.one > .ie7-before,
a.one:before {
content: "»";
color:#0F0;
padding:0 5px 0 0;
}
This uses quite a few hacks, so I would not recommend using it unless you understand what is going on there.
Here is the page I have a problem with
on each image (little square) i apply the class <div class="odeurbox"> that should be 67 pixel wide...the result is a box 480 pixel wide
Why is the style is superseded by something else.... obviously, there is something i dont understand from the CSS cascading ..
any light ?
p.s. i know you dont care, but it look good in dreamweaver... sob !
You are missing a } bracket for the class:
.textplusbold {
color: #002B4E;
font-weight: bold;
}
Line 198 of the css file. :)
Well your .odeurbox class's width: 67px value should override any parent style width's. Have you got the width set on the odeurbox class?
You haven't specified a style for the .odeurbox style. Add the following to your stylesheet:
.odeurbox { width: 67px; }