CSS "data dictionary"

Richard · October 5, 2015

This isn't exactly a feature request but it is something new--move it to Support if you think that's a better place.

It would be helpful to many of us if SM published (and maintained!) a dictionary of all the user-modifiable widget class names and IDs and their hierarchy. The developer inspector tools are difficult to use at times. Sometimes my CSS tweaks fail for no apparent reason, and I imagine it's because I'm getting the references wrong or because I'm changing a class which is overridden by something I'm not seeing.

Allen · October 5, 2015

ALL widgets have a unique class name. Their ID changes with every page refresh.
EVERY widget class name looks like this with its own unique number.
.sm-page-widget-4000637

This is typical widget html from the page source or from "Inspect Element". When using "Inspect
Element", wherever your mouse pointer is on the widget, when the "Inspect Element" box opens, a line
will highlight somewhere in this html. Then it's just a matter of reading up lines to find the widget
class name.

<div[COLOR=Yellow] id=[/COLOR]"sm-page-widget-DrpWk3sp"[COLOR=Yellow] class=[/COLOR]"sm-page-widget
          sm-page-widget-html [COLOR=Red]sm-page-widget-4000637[/COLOR]" data-typeid="4000637">
   <div class="sm-page-widget-content"><div class="sm-page-widget-[COLOR="Yellow"]header[/COLOR]"></div>
   |   <div id="sm-page-widget-BWZrCj32" class="sm-page-widget-[COLOR="Yellow"]body[/COLOR]">
   |   |   <div style="font-size: 140%; ... 20px 0;">
   |   |   |  This is ...<br>
   |   |   </div>
   |   <div class="sm-page-widget-[COLOR="Yellow"]footer[/COLOR]"></div>
   </div>
</div>  /* << closes widget div */

sarasphotos · October 6, 2015

I'll add my vote to Richard's. While it's nice of folks like Allen to give us tips, it would be even more helpful to be able to refer to an officially maintained dictionary of css elements and their uses- which would include a list of depreciated elements. Surely this is all documented somewhere. Why the need to make it harder on those of us who want to customize? This philosophy of sending the user on the wild goose chase of using the page inspector for every desired change just bites!

I actually e-mailed support about this when I first started creating my site 2 years ago and the inane and overly-cutesy response that I received convinced me that mailing the support team was a waste of time.

Have a great day!
Sara

leftquark · October 6, 2015

This is a really hard one to answer because while there are definitely some uses that will help people like you, for the most part, I think a list of CSS Class names will actually only confuse you more. The reason for this is a few fold but the main reason is that it's just simply too risky to try to target a specific class all by itself because of the way that content blocks can be placed anywhere on the page. The best thing is to create custom CSS that's specific to where you've placed the content block, and that ends up being a combination of several CSS class names. Trying to go through a dictionary to figure this out ends up being confusing, and most people will end up writing CSS code that will inadvertently change things that they don't want changed. It ends up being much easier to use the Developer Tools to pinpoint the specific hierarchy of classes that you want to modify.

Here's an example:
Let's say I have a single photo content block on my homepage and I want to use some CSS to move it. The dictionary might tell you that the single photo content block uses ".sm-image" class names, so I write some CSS to move ".sm-image" left 40px. What you've just done is move every photo on SmugMug 40 pixels to the left, which includes all your thumbnails, folder images, gallery images, etc. Not what you've intended.

Additionally, the reason that things sometime work and sometimes don't work is simply because CSS is finicky ... you'll still have the same finicky things that impact you even with a SmugMug CSS dictionary.

The very best way to write Custom CSS it to actually do it inside the Developer Tools. You can find out immediately if the code works or doesn't work. I always write my CSS code this way and it makes things so much easier. Otherwise I'd have to write the CSS code in a text editor, go into the Customizer (several clicks), paste the code in, click Publish, go back to my site, and then see if it worked. if I was off by a few pixels, I'd have to repeat the entire process. Painful. Instead, I write all the code in the Developer Tools, make sure it's perfect, then simply copy it from Dev Tools and paste into the Customizer. Wallah! So much nicer!

Lastly, trying to maintain a CSS dictionary is going to be an arduous task, especially as we work to improve and expand SmugMug. We're in this tough paradigm right now with CSS, in that we want to improve features, but we are afraid to break peoples customizations. One solution has been to just give our feature improvements new class names so it won't break peoples Custom CSS. Trying to keep this CSS dictionary maintained would take precious time away from building SmugMug.

sarasphotos wrote: »

I actually e-mailed support about this when I first started creating my site 2 years ago and the inane and overly-cutesy response that I received convinced me that mailing the support team was a waste of time.

Your experience should never be like this. Our heroes always try to be heroic and I appreciate letting us know that your experience wasn't. Please give the heroes another chance -- we really do want to make sure we can satisfy every customer on every help desk experience.

Allen · October 6, 2015

Perhaps some help videos on how to use "Inspect Element", Firebug, Web Developer, etc.

I use both of these at same time, Firefox "Inspect Element" to find class names and WebDev's edit CSS box to test.
In WebDev I can go thru every edit CSS box tab looking at all the site CSS.

leftquark · October 7, 2015

A good video on how to use Chrome's Developer Tools can be found here: https://www.youtube.com/watch?v=Z3HGJsNLQ1E

Richard · October 7, 2015

Thanks for your thoughtful reply, Aaron. A few comments:

I appreciate the difficulty here. I feel a bit like the Disney Sorcerer's Apprentice when I try to use the developer tools--all I see is a bunch of trees when what I need to start is a map of the forest. It's true that changing the wrong setting in the wrong place can have devastating consequences, but that's true whether you do it in a tool or in the SM preview. What I need is a better sense of how it all fits together.

As for the difficulty of compiling and maintaining a dictionary, it's hard to believe that (like a comprehensive bug list) you don't have one internally. Why not make it available to those of us who might be able to profit from it? No need to dumb it down for the non-technical (which certainly would mean additional work). Just call it Advanced CSS Reference For Geeks Only, or something like that. You could put up a disclaimer like FireFox does when you invoke about:config warning the user that they better know what they're doing 'cause they're on their own. Maybe it would be beyond me, but maybe not entirely. No way of knowing without seeing it.

I suppose that with enough practice I'll get the hang of it--once a techie, always a techie. But when I was programming for a living, I had a strong preference for documentation over reverse engineering or trial and error. Sometimes the documentation was even current and correct

.

I've installed Firebug (which at first glance doesn't look very different from the built-in tools) and I'll check out the video.

Thanks again.

CSS "data dictionary"

Comments