Skip to main content
Topic: Thought about CSS files. (Read 22123 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Thought about CSS files.

Reply #15

Well it could use different class names if you're worried about that. I just chose the least verbose, and based on tag name. If you're worried that the example markup itself seems harder to read with classes added, don't be. Any markup looks like hell once it's shoved into a PHP template. :D

This is more than interesting. I'm kicking myself that I didn't think of it before. It has the potential to vastly simplify the huge pile of code related to all the dropmenus. The big advantage of it is that it will be a lot simpler to stop stuff you don't want cascading. I'm going to get it all written up and running live on local.

ETA: Changes will involve deprecating the dropmenu class as such, and just relying on #main_menu, #admin_menu, #adm_submenus, .poster and .quickbuttons to specify ul. That will involve a minor edit where superfish is initialised. No big deal.

It will be much better this way. The main menu, admin drops, sidebar menu, etc can still share most of the css for their droppy bitz (coz they all look the same anyway), but how it's specified will be simpler.
Last Edit: June 16, 2013, 08:25:03 pm by Antechinus
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Thought about CSS files.

Reply #16

Hey someone gets it.  :D

Quote(11:52:39 AM) Antechinus: Y'know when you get an idea that makes you want to kick yourself for not thinking of it before?
(11:52:52 AM) Eliana Tamerin: yep
(11:53:01 AM) Antechinus: I had one yesterday afternoon. :D
(11:53:30 AM) Antechinus: And the really funny thing is the other guys at Elk can't see how good it is yet
(11:53:47 AM) Eliana Tamerin: what is it?
(11:53:54 AM) Antechinus: Dropmenu CSS is always horrible, specially for teh n00bz
(11:54:10 AM) Antechinus: all this lilililiaulliliaul blah blah everywhere
(11:54:15 AM) Eliana Tamerin: YES
(11:54:20 AM) Antechinus: hard to understand, easy to break
(11:54:42 AM) Eliana Tamerin: yep
(11:54:50 AM) Eliana Tamerin: enough lead in, out with it
(11:54:57 AM) Antechinus: http://www.elkarte.net/index.php?topic=439.msg3037#msg3037
(11:55:07 AM) Antechinus: See if this makes sense to you
(11:55:20 AM) Antechinus: Starting at the "I had another idea" bit
(11:56:00 AM) Eliana Tamerin: naming could use some work, but I like the concept
(11:56:20 AM) Antechinus: Yes I just used minimal geekstuffz names
(11:56:35 AM) Antechinus: but should get rid of a whole lot of crud
(11:56:58 AM) Antechinus: Best thing is styling sub elements will no longer require descendant shiz
(11:57:02 AM) Eliana Tamerin: oh yes
(11:57:04 AM) Eliana Tamerin: oooh
(11:57:14 AM) Antechinus: so stopping unwanted style cascades becomes really easy
(11:57:21 AM) Antechinus: because they will never want to cascade anyway
(11:57:29 AM) Antechinus: a_lvl2 just goes there
(11:57:33 AM) Antechinus: not all the way down
(11:57:45 AM) Antechinus: same for level 1
(11:57:48 AM) Antechinus: blah blah
(11:58:18 AM) Antechinus: and I deprecate the generic dropmenu class
(11:58:42 AM) Antechinus: and just use separate classes or ids for main menu, admin drops, sidebar, etc
(11:58:55 AM) Antechinus: but they all call the a_lvl1 etc stuff
(11:59:07 AM) Antechinus: so do basic setup once
(11:59:22 AM) Antechinus: then since all styling is at one level only to start with
(11:59:33 AM) Antechinus: overrides for different areas later on become very simple
(11:59:49 AM) Antechinus: a_lvl1 sets a style to start
(12:00:01 PM) Antechinus: .poster a_lvl1 is an easy override
(12:00:08 PM) Antechinus: no need to be more specific anywhere
(12:00:45 PM) Eliana Tamerin: I like it
(12:01:12 PM) Antechinus: tldr - it's gonna rock. Specially for teh n00bz who just want to change basic stuff.
(12:04:36 PM) Antechinus: Naming. Hmm.
(12:05:34 PM) Antechinus: I suppose li_level_1, a_level_1 might be better
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Thought about CSS files.

Reply #17

The simpler, the better indeed...

Here's how I'm doing it in Wedge, which as you'll remember is using my own CSS precompiler, so it's a bit of a cheat...
- You can ask Wedge to entirely scrap a CSS file, and replace it with yours, and keep the rest. (Dynamically.)
- 'reset' keyword: allows you to selectively remove all styling associated with a certain selector. Then, you can re-style it on your own terms.
- '@replace' command: allows you to simply target a rule (or several), and replace it (them) on the fly.

These are some of the things that I wrote with themers in mind, but I keep asking myself, are they frigging going to notice these exist at all..? I don't know, but I sure hope they will.

I think that the future of CSS, is in preprocessors, because CSS has been way too slow to implement simple useful things like CSS variables, and even then, their current implementation isn't exactly very CSSish. Heck, even Less's implementation is more it...

Had I known that Less had a PHP implementation back in 2010, I wouldn't have written my own, but by this point, there's too much in Wess that's not in Less, that I don't really see a point in making the switch. (Heck, they only recently implemented extends, which I was adamant they had since their first version...! What a surprise, really...)

Re: Thought about CSS files.

Reply #18

Ok, been thinking. Will compromise with Teh Norv. Yes, radical notion, but I believe it is possible. :D

I'll make three new variant files/folders: _light (current default here),  _dark (placeholder for now) and _basic (also placeholder for now).

I wont get into stripping index.css down to pure framework yet, just to keep up momentum. But, as soon as an area of presentation is finished (like the calendar is now) I'll split that into framework (index.css) and eye candy (index_light.css). This should keep momentum up while getting a start on the final arrangement.

 Cool? :)

ETA: Oh and I've decided on this for a naming scheme for drop menu elements. After trying a pile of options, these seem like the clearest and easiest to read. Adding underscores into the class names just makes them less legible IMO.

Code: [Select]
<ul>		#main_menu		/* Menu bar: wrapper/background. */
<li> listlevel1 /* List positioning: not shown. */
<a> linklevel1 /* Menu bar: link or button. */

<ul> menulevel2 /* Drop menu: wrapper/background. */
<li> listlevel2 /* List positioning: not shown. */
<a> linklevel2 /* Drop menu: link or button. */

<ul> menulevel3 /* Next drop menu: wrapper/background. */
<li> listlevel3 /* List positioning: not shown. */
<a> linklevel3 /* Next drop menu: link or button. */
Last Edit: June 17, 2013, 08:36:09 pm by Antechinus
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Thought about CSS files.

Reply #19

Ok, just as an example of how it's panning out, I've split the main/admin drop menu and sidebar menu coding into basic layout stuff that holds it all together (in index.css) and eye candy (in the_variant.css).

This has been done for two variants: the cool one that runs here, and a dead basic one that is as simple as possible, as a basis for n00bz and others to play with in their quest for coolness.

To run properly, these need images folders in themes/images, and calls for the variants in index.template.php, and language strings, etc. So, I'm not putting everything here, but these are the relevant excerpts from the three CSS files. Spacing and commenting can be altered, but I think it's pretty clear already.

index.css

Code: [Select]
/* Styles for the standard dropdown menus. */
/* --------------------------------------------------*/
/* @todo - Lots of interdependent revision here to minimise code. */

/* This is layout code only. All the eye candy is in the _variant.css. */
/* NOTE: This layout code should NOT be altered */
/* unless you are really sure of what you are doing. */
 /* ALL variants depend on this basic layout code for stability. */
/* ----------------------------------------------------------- */

/* Visible menu bar: wrapper/background. */
#main_menu {
position: relative;
margin: 6px;
padding: 5px 8px 4px 8px;
}
/* @todo - Collect all pseudo clearfixes in one declaration. */
#main_menu:after {
content:"";
display: block;
clear: both;
}
/* Wrapper for secondary admin/profile/etc menus- positioning only. */
#adm_submenus {
padding: 10px 15px;
overflow: auto;
}
/* Level 1 button positioning. No visible styling. */
/* 1px padding gives slight gap between buttons, and drop menus. */
.listlevel1 {
padding: 1px;
float: left;
line-height: 2.3em;
position: relative;
}
/* For the upshrink button in the main menu bar. */
#collapse_button {
position: absolute;
top: 4px;
right: 8px;
}
#upshrink {
padding: 4px 9px 3px 9px;
}
/* Level 1 Menu bar: link or button. General sizing. */
#main_menu .linklevel1, .admin_menu .linklevel1, #adm_submenus .linklevel1 {
padding: 0 0.5em;
display: block;
}
/* Levels 2 and 3: drop menu wrapper. */
.menulevel2, .menulevel3 {
z-index: 90;
position: absolute;
top: 100%;
left: -9999px;
width: 18.2em;
padding: 0.5em;
}
/* Level 3: drop menu positioning. */
.menulevel3 {
margin: -2em 0 0 15.3em;
}
/* Reposition Level 2 drop menu as visible on hover. */
/* @todo - Check Superfish class. I think .sfhover may be deprecated. */
.listlevel1:hover .menulevel2, .listlevel1.sfhover .menulevel2 {
left: 1px;
}
/* Hiding Level 3 drop menu off hover. */
.listlevel1:hover .menulevel3, .listlevel1.sfhover .menulevel3 {
left: -9999px;
}
/* Reposition Level 3 drop menu as visible on hover. */
.listlevel2:hover .menulevel3, .listlevel2.sfhover .menulevel3 {
left: -14px;
}
/* Level 2 and 3 button positioning. No visible styling. */
/* 1px vertical padding gives slight gap between buttons. */
.listlevel2 {
padding: 1px 0;
width: 17em;
position: relative;
float: none;
}
/* Levels 2 and 3 drop menus: link or button. */
.linklevel2, .linklevel3 {
position: relative;
line-height: 2.2em;
padding: 0 7px;
display: block;
}
/* @todo - Note: The next declarations are for keyboard access with js disabled. */
/*.dropmenu ul a:focus, .dropmenu ul ul a:focus {
margin-left: 9990px;
border: none;
width: 17em;
}
.dropmenu ul ul a:focus {
margin-left: 19950px;
}
/* @todo - Cancel those for hover and/or js access. */
/*.dropmenu ul li:hover a:focus, .dropmenu ul li.sfhover a:focus {
margin-left: 0;
width: auto;
} */

/* Styles for sidebar menus.
------------------------------------------------------- */
#main_container {
position: relative;
}
/* @todo - Collect all pseudo clearfixes in one declaration. */
#main_container:after {
content:"";
display: block;
clear: both;
}
#main_admsection {
position: relative;
left: 0;
right: 0;
overflow: auto;
}
#menu_sidebar {
width: 185px;
float: left;
padding: 0 10px 1em 0;
}
#menu_sidebar .catbg {
padding: 5px 8px;
font-size: 1.1em;
}
#menu_sidebar .sidebar_menu {
padding: 4px 0 9px 0;
}
/* Same styling for Level 1 and Level 2. */
#menu_sidebar .listlevel1 {
padding: 1px 0;
line-height: 2em;
float: none;
}
#menu_sidebar .linklevel1, #menu_sidebar .linklevel2 {
display: block;
padding: 2px 7px;
}
#menu_sidebar  .listlevel1:hover .menulevel2, #menu_sidebar  .listlevel1.sfhover .menulevel2 {
top: -1px;
left: 160px;
}
/* @todo - Check these again. */
/* Note: The next declarations are for keyboard access with js disabled. */
#menu_sidebar .linklevel2:focus {
margin-left: 10150px;
width: 17em;
}
/* @todo - Check these again. */
/* Cancel those for hover and/or js access. */
#menu_sidebar .listlevel2:hover .linklevel2:focus, #menu_sidebar .listlevel2.sfhover .linklevel2:focus {
margin-left: 0;
width: auto;
}
/*End sidebar flyout coding. */


_light.css (the one you see here)

Code: [Select]
/* This variant is the standard, light, Elkarte default theme. */
/* ----------------------------------------------------------- */
/* This is eye candy only. All the layout code is in index.css. */
/* NOTE: The layout code in index.css should not be altered
/* unless you are really sure of what you are doing.
 /* ALL variants depend on the basic layout code for stability. */
/*----------------------------------------------------------- */

/* Styles for the standard dropdown menus.
----------------------------------------------------------- */
/* Visible menu bar: wrapper/background. */
#main_menu {
background: #4b863c;
background-image: linear-gradient(to bottom, #5BA048 0%, #3d6e32 100%); /* W3C */
border-radius: 6px 6px 0 0;
}
/* Needed for new PM notifications. */
.listlevel1 strong {
color: #fff;
}
/* Level 1 Menu bar: link or button. General sizing. */
#main_menu .linklevel1, .admin_menu .linklevel1, #adm_submenus .linklevel1 {
/* If there will be a border on hover, ensure there is a default border. */
/* Applying a default transparent border stops links jumping on hover. */
border: 1px solid transparent;
border-radius: 4px;
color: #fff;
}
/* Override link colour for admin/profile/etc menus. */
.admin_menu .linklevel1, #adm_submenus .linklevel1 {
color: #444;
}
/* Level 1 button hover and focus effects. */
#main_menu .active, /* Level 1 active button shares same styling. */
#main_menu .linklevel1:hover, #main_menu .listlevel:hover .linklevel1, #main_menu .linklevel1:focus,
/* For primary admin/profile/etc drop menus. */
.admin_menu .linklevel1:hover, .admin_menu .linklevel1:focus,
/* For secondary admin/profile/etc menus. */
#adm_submenus .linklevel1:hover, #adm_submenus .linklevel1:focus {
background: #fcfcfc;
background-image: linear-gradient(to bottom, #fcfcfc 0%, #e5e5e5 100%); /* W3C */
color: #555;
border: 1px solid #afafaf;
border-top: 1px solid #bbb;
text-decoration: none;
}
/* Main menu Level 1 active button and hover need a different border. */
#main_menu .active, #main_menu .linklevel1:hover, #main_menu .listlevel:hover .linklevel1, #main_menu .linklevel1:focus {
border: 1px solid #38642d;
}
/* Level 1 active buttons for primary admin/profile/etc drop menus... */
.admin_menu .active,
/* ......and for secondary admin/profile/etc menu strip. */
#adm_submenus .active {
background: #4b863c;
background-image: linear-gradient(to bottom, #5BA048 0%, #3d6e32 100%); /* W3C */
color: #fff;
border: 1px solid #38642d;
}
/* Hover effects for those buttons. */
.admin_menu .active:hover, .admin_menu .listlevel1:hover .active, #adm_submenus .active:hover {
background: #437837;
color: #fff;
box-shadow: 1px 1px 1px rgba(0,0,0,0.3) inset;
border: 1px solid #5aa049;
border-left: 1px solid #2d5024;
border-top: 1px solid #2d5024;
}
/* Level 1 active buttons get a bit more weight. */
.active {
font-weight: 600;
}
/* Top level subsection indicators. */
/* Comment these out if you don't want them. */
#main_menu .subsections .linklevel1, .admin_menu .subsections .linklevel1 {
padding: 0 0.8em 0 0.5em;
}
#main_menu .subsections .linklevel1:after,.admin_menu .subsections .linklevel1:after {
content:" \2193";
position: absolute;
top: 0.5em;
right: 0.3em;
font-size: 1.3em;
}
/* Levels 2 and 3: drop menu wrapper. */
.menulevel2, .menulevel3 {
background: #fff;
border: 1px solid #aaa;
border-radius: 4px;
box-shadow: 3px 3px 3px rgba(0,0,0,0.3);
}
/* Levels 2 and 3 drop menus: link or button. */
.linklevel2, .linklevel3 {
color: #555;
/* Applying a default transparent border stops links jumping on hover. */
border: 1px solid transparent;
border-radius: 3px;
}
/* Admin menu icons. */
.linklevel2>img {
vertical-align: middle;
margin: 0 0 0 -4px;
}
/* Levels 2 and 3: hover effects. */
.listlevel2:hover .linklevel2, /* linklevel2 highlighted with cursor over level 3. */
.linklevel2:hover, .linklevel2:focus, .linklevel2.sfhover:focus,
.linklevel3:hover, .linklevel3:focus, .linklevel3.sfhover:focus {
background: #fcfcfc;
background-image: linear-gradient(to bottom, #fcfcfc 0%, #e5e5e5 100%); /* W3C */
color: #555;
border: 1px solid #afafaf;
border-top: 1px solid #bbb;
text-decoration: none;
}
/* Level 2: subsection indicators. */
.listlevel2.subsections .linklevel2:after {
content: "\2192";
position: absolute;
right: 6px;
font-size: 1.3em;
color: #777;
}
/* Levels 2 and 3: highlighting of current section */
/* @todo - This should probably be applied to main menu as well, just for consistency. */
.linklevel2.chosen, .linklevel3.chosen {
font-weight: 600;
}

/* Styles for sidebar menus.
------------------------------------------------------- */
/* Same styling for Level 1 and Level 2. */
#menu_sidebar .linklevel1, #menu_sidebar .linklevel2 {
color: #555;
border: 1px solid transparent;
}
#menu_sidebar .linklevel1:hover, #menu_sidebar .linklevel1:focus, #menu_current_area .linklevel1,
#menu_sidebar .linklevel2:hover, #menu_sidebar .linklevel2:focus {
background: #fcfcfc;
background-image: linear-gradient(to bottom, #fcfcfc 0%, #e5e5e5 100%); /* W3C */
color: #555;
border: 1px solid #afafaf;
border-top: 1px solid #bbb;
border-radius: 3px;
text-decoration: none;
}
#menu_current_area .linklevel1 {
font-weight: 600;
}
/* Level 1: subsection indicators. */
#menu_sidebar .listlevel1.subsections .linklevel1:after {
content: "\2192";
position: absolute;
right: 6px;
}
/*End sidebar flyout coding. */


_basic.css (teh boilerplate version)

Code: [Select]
/* This variant is a very basic, boilerplate version of the default theme. */
/* It is intended primarily as a "clean slate" for custom theming. */

/* This variant uses named colours instead of hex codes, to make things easier for beginners. */
/* A complete list of CSS colour names can be found at http://www.w3schools.com/cssref/css_colornames.asp */

/* ----------------------------------------------------------- */
/* This is eye candy only. All the layout code is in index.css. */
/* NOTE: The layout code in index.css should NOT be altered
/* unless you are really sure of what you are doing.
/* ALL variants depend on the basic layout code for stability. */
/* ----------------------------------------------------------- */


/* Styles for the standard dropdown menus.
----------------------------------------------------------- */

/* Visible menu bar: wrapper/background. */
#main_menu {
background: forestgreen;
}

/* Needed for new PM notifications. */
.listlevel1 strong {
color: white;
}

/* Level 1 Menu bar: link or button. */
/* If there will be a border on hover, have a border here. */
/* A default transparent border stops links jumping on hover. */
#main_menu .linklevel1, .admin_menu .linklevel1, #adm_submenus .linklevel1 {
border: 1px solid transparent;
color: white;
}

/* Override link colour for admin/profile/etc menus. */
.admin_menu .linklevel1, #adm_submenus .linklevel1 {
color: black;
}

/* Level 1 button hover and focus effects. */
#main_menu .active, /* Level 1 active button shares same styling. */
#main_menu .linklevel1:hover, #main_menu .listlevel:hover .linklevel1, #main_menu .linklevel1:focus,

/* For primary admin/profile/etc drop menus. */
.admin_menu .linklevel1:hover, .admin_menu .linklevel1:focus,

/* For secondary admin/profile/etc menus. */
#adm_submenus .linklevel1:hover, #adm_submenus .linklevel1:focus {
background: gainsboro /* This is a pale grey. */;
color: black;
border: 1px solid darkgray;
text-decoration: none;
}

/* Main menu Level 1 active button and hover need a different border. */
#main_menu .active, #main_menu .linklevel1:hover, #main_menu .listlevel:hover .linklevel1, #main_menu .linklevel1:focus {
border: 1px solid black;
}

/* Level 1 active buttons for primary admin/profile/etc drop menus... */
.admin_menu .active,
/* ......and for secondary admin/profile/etc menu strip. */
#adm_submenus .active {
background: forestgreen;
color: white;
border: 1px solid black;
}

/* Hover effects for those buttons. */
.admin_menu .active:hover, .admin_menu .listlevel1:hover .active, #adm_submenus .active:hover {
background: darkgreen;
color: white;
border: 1px solid black;
}

/* Level 1 active buttons get a bit more weight. */
.active {
font-weight: bold;
}

/* Top level subsection indicators. */
/* Comment these out if you don't want them. */
#main_menu .subsections .linklevel1, .admin_menu .subsections .linklevel1 {
padding: 0 0.8em 0 0.5em;
}
#main_menu .subsections .linklevel1:after,.admin_menu .subsections .linklevel1:after {
content:" \2193";
position: absolute;
top: 0.5em;
right: 0.3em;
font-size: 1.3em;
}

/* Levels 2 and 3: drop menu wrapper. */
.menulevel2, .menulevel3 {
background: white;
border: 1px solid darkgray;
}

/* Levels 2 and 3 drop menus: link or button. */
.linklevel2, .linklevel3 {
color: black;
/* Applying a default transparent border stops links jumping on hover. */
border: 1px solid transparent;
}

/* Admin menu icons. */
.linklevel2>img {
vertical-align: middle;
margin: 0 0 0 -4px;
}

/* Levels 2 and 3: hover effects. */
.listlevel2:hover .linklevel2, /* < highlighted with cursor over level 3. */
.linklevel2:hover, .linklevel2:focus, .linklevel2.sfhover:focus,
.linklevel3:hover, .linklevel3:focus, .linklevel3.sfhover:focus {
background: gainsboro;
color: black;
border: 1px solid darkgray;
text-decoration: none;
}

/* Level 2: subsection indicators. */
.listlevel2.subsections .linklevel2:after {
content: "\2192";
position: absolute;
right: 6px;
font-size: 1.3em;
color: black;
}

/* Levels 2 and 3: highlighting of current section */
.linklevel2.chosen, .linklevel3.chosen {
font-weight: bold;
}

/* Styles for sidebar menus.
------------------------------------------------------- */

/* Same styling for Level 1 and Level 2. */
#menu_sidebar .linklevel1, #menu_sidebar .linklevel2 {
color: black;
border: 1px solid transparent;
}

#menu_sidebar .linklevel1:hover, #menu_sidebar .linklevel1:focus, #menu_current_area .linklevel1,
#menu_sidebar .linklevel2:hover, #menu_sidebar .linklevel2:focus {
background: gainsboro;
color: black;
border: 1px solid darkgray;
text-decoration: none;
}

#menu_current_area .linklevel1 {
font-weight: bold;
}

/* Level 1: subsection indicators. */
#menu_sidebar .listlevel1.subsections .linklevel1:after {
content: "\2192";
position: absolute;
right: 6px;
}

/*End sidebar flyout coding. */

Given the complexity of multi-level drop menu coding, and taking into account the choice between drops or sidebar, I think this is close to as simple as we can make it.
Last Edit: June 20, 2013, 08:49:26 am by Antechinus
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Thought about CSS files.

Reply #20

And, on the subject of simplicity, I've started rearranging the contents of index.css to get all related stuff in one place. I'm over finding things declared more than once in hidden corners. Way to drive people mental when they're trying to fix something. Drives me mental anyway. :P

Anyway, I found all of this:

Code: [Select]
/* a descriptive style */
.description, .information, .plainbox {
padding: 6px 12px;
font-size: 0.9em;
border: 1px solid #ccc;
border-top: none;
border-radius: 0 0 3px 3px;
background: none;
margin: -1px 0 12px 0;
-moz-box-sizing: border-box; -webkit-box-sizing: border-box; box-sizing: border-box;
}
/* a simple full surrounding box */ /* @todo - How many types of silly plain boxes do we need? */
.simplebox {
padding: .5em 1em;
font-size: 0.9em;
border: 1px solid #ccc;
border-radius: 3px;
background: none;
margin: .5em 0 1em 0;
-moz-box-sizing: border-box; -webkit-box-sizing: border-box; box-sizing: border-box;
}
/* an informative style */
.information {
background: #f0f6f0;
margin: 2px 1px 12px 1px;
}
.information p {
padding: 12px;
margin: 0;
}
.para2 {
padding: 12px 0 44px 0;
margin: 0;
}
/* Styles for info boxes
------------------------------------------------- */
/* @todo - ZOMFG. More silly plain box styles. */
.noticebox {
color: #555;
/* @todo - Change background image for simple sprite combined with quickbuttons? */
background: #fff6ca url(../images/profile/warning_moderate.png) 10px 50% no-repeat;
text-align: left;
border-top: 1px solid #ffd324;
border-bottom: 1px solid #ffd324;
padding: 7px 10px 7px 35px;
margin-bottom: 12px;
}
.infobox {
color: #555;
/* @todo - Change background image for simple sprite combined with quickbuttons? */
background: #efe url(../images/icons/field_valid.png) 10px 50% no-repeat;
text-align: left;
border-top: 1px solid green;
border-bottom: 1px solid green;
padding: 7px 10px 7px 35px;
margin-bottom: 12px;
}
.descbox {
text-align: left;
padding: 7px 10px 7px 35px;
border: 1px solid #c5c5c5;
border-radius: 7px;
margin: 6px 0;
}

So in SMF 2.0.x there were the first three: .description, .information and .plainbox. Now it seems we have seven (!?!?!?!) classes of basic rectangular boxes with little borders around them. Methinks this is getting into seven deadly sins territory. I doubt we really need more than two such classes.

 Antechinus goes to sharpen his axe again. Teh axe is getting a real workout. ;D

ETA: HA! Did some searching.

/* @todo - .plainbox is only called on Line 939 of Display.template.php - kill it! /
/
@todo - .simplebox is only called on Line 554 of ManageBoards.template.php, and on Lines 512 and 1066 of ManagePermissions.template.php - kill it! /
/
@todo - Only two of .descbox, on Lines 586 and 1604 of Packages.template.php - kill this too! */

So that will easily knock it back to four classes.
Last Edit: June 20, 2013, 09:06:41 am by Antechinus
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Thought about CSS files.

Reply #21

Quote from: Antechinus – index.css
[snip]
_light.css (the one you see here)
[snip]
_basic.css (teh boilerplate version)
[snip]

Oh, it's good to see how it's shaping up! Something like this, give or take what's where, is a nice way to offer a basics, simple, css, up for us other mortals to customize. ;)

ETA: I guess after the upcoming PR, we should add '_basic' to the files to copy, when making a copy of the default theme in admin (dunno if the others too, but _basic will be needed for a copy, people make it likely to start customizing a bit and/or to test something).
The best moment for testing your PR is right after you merge it. Can't miss with that one.

Re: Thought about CSS files.

Reply #22

Yeah having that copied would make a lot of sense. We should also document the process for adding extra variants to a theme. Something like:

1/ Edit index.template.php to add names for new ones.
2/ Edit language strings in /languages/Themes.*******.php.
3/ Copy a variant image folder and name the copy to suit.

Which is pretty easy, as long as they know. :)

Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Thought about CSS files.

Reply #23

IMHO installing (or uninstalling) variants should be possible via Packman and without file edits at all...
 instead of theme_settings in index.template.php and a language string we should move it to the database.. Variant names IMO don't need a translated name, so a simple table structure (maybe elkarte_themes or a new one) would be enough.
We'd need the id_theme, (id_variant), the short variant name and a descriptive name.
Thorsten "TE" Eurich
------------------------

Re: Thought about CSS files.

Reply #24

Well the best way would be to copy an images folder and a stylesheet and rename those too. Otherwise I can see db storage being problematic, because there would be no obvious record in the files of what was installed. Themers do not like stuff being hidden, y'know. ;)
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Thought about CSS files.

Reply #25

yep, agreed.
another idea: How about adding a new folder named "variants" where you can simply place your own variant folder...
/themes/default/variants/thorstensgreen/.. with sub-folders for css and images.

Basic variant infos (name, author, description) could be placed in a variant.xml (similar to package-info.xml)
/themes/default/variants/thorstensgreen/variant.xml
/themes/default/variants/thorstensgreen/css/index.css
/themes/default/variants/thorstensgreen/images/on.png
..
Thorsten "TE" Eurich
------------------------

Re: Thought about CSS files.

Reply #26

How do you generate the variant.xml? Manually? Isn't that as much trouble as doing it the way it's done now.?

Thought: the problem with file edits is not that they're file edits. It's that they can break stuff. If file edits didn't break stuff, nobody would care about hooks.

How likely is it that the edits required to add a variant to a theme will break stuff? My guess, about as likely as the server going feet up. All you have to do is add a language string to Themes/****.php, which is a simple search/add at the end of the file, or search/delete if removing.

Ditto for the list of variants in index.template.php. You just have to add your variant name last in the list, and it gets deleted if you uninstall. Files and folders? Easy. Point is that this is one example where I honestly don't see any need to panic about using file edits. Anything can break stuff occasionally. Hooks can be a PITA occasionally too.
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Thought about CSS files.

Reply #27

Just a warning here for anyone playing with CSS for Elk.

I've been looking into styling/stability for the page links. They were declared as display: inline-block; in the stylesheet. That's fine sometimes, but it's not perfect all the time.

It has a well-known quirk attached to it: CSS display: inline-block: why it rocks, and why it sucks

Quote from: The enormous drawbackI hope so far that I have managed to get you to realize the potential and simplicity of this approach. However, there’s one giant drawback, that might or might not apply to your use case. That is, since the elements become rendered inline, white-space in your HTML code will affect the rendering. That means, if we want perfect size and alignment, but we have space between the LI elements in our code example, it will render a 4 pixel margin to the right of each element.
This is something to be aware of whenever you are considering declaring anything as inline-block. If inline-block gves you odd results for paddings/margins, use floats instead. It'll save you some aggravation.
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Thought about CSS files.

Reply #28

Just been looking around a bit, and have decided that we should include some* stuffz like this in our CSS files.

CSS Document Anatomy

*Meaning I don't think it's necessary, or even desirable, to blindly follow all his recommendations, but he definitely has some ideas worth using.

QuoteAt the top of stylesheets, I maintain a table of contents which will detail the sections contained in the document, for example:

/*------------------------------------*\
    $CONTENTS
\*------------------------------------*/
/**
  CONTENTS............You’re reading it!
 
RESET...............Set our reset defaults
 * FONT-FACE...........Import brand font files
 */

This will tell the next developer(s) exactly what they can expect to find in this file. Each item in the table of contents maps directly to a section title.


If you are working in one large stylesheet, you leave five (5) carriage returns between each section, thus:

/*------------------------------------*\
    $RESET
\*------------------------------------*/
[Our
reset
styles]





/*------------------------------------*\
    $FONT-FACE
\*------------------------------------*/

This large chunk of whitespace is quickly noticeable when scrolling quickly through larger files.

And especially this, since we'll be splitting between a baseline, layout CSS file (index.css) and teh groovy eye candy and bouncing parrots _variant.css file....

QuoteWhen working in an object oriented manner you will often have two chunks of CSS (one being the skeleton (the object) and the other being the skin (the extension)) that are very closely related, but that live in very different places. In order to establish a concrete link between the object and its extension with use object/extension pointers. These are simply comments which work thus:

In your base stylesheet:

/**
 * Extend .foo in theme.css
 /
 .foo{}

In your theme stylesheet:

/*

 * Extends .foo in base.css
 */
 .bar{}

Here we have established a concrete relationship between two very separate pieces of code.

Since Elk comes with groovy file minimisation as standard, I figure we should comment the crap out of the CSS files, as the comments should all be stripped before zipping anyway.

I think the major problem with the old SMF index.css is not so much its length or complexity, but the density of its formatting.
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Thought about CSS files.

Reply #29

Cool! Sure thing, commenting it better is quite necessary IMHO. Every of those ideas sounds great to me. Can only help a bit.
The best moment for testing your PR is right after you merge it. Can't miss with that one.