What are some strategies for using CSS classes to library HTML? - html

I am developing a library of HTML components. The underlying technology is not relevant; the code for each component just generates HTML that is ultimately sent to the browser.
The problem I'm having is that a lot of the generated HTML needs to be styled by the application. And I don't know ahead of time exactly what that styling might be. Also, the generated HTML tends to have several divs and spans for, each of which might be styled differently. Think of something like a calendar component and all the different ways that might be styled.
At first I thought I'd just assign a class to every non-trivial element. I prefixed all my class names with "foo" (the name of my library), so the div for the calendar component has class foo-calendar. But inside the components I started to wonder about this approach because I kept having to make up weird names for all the various divs that make up each one. And what about when there's only one tag of a certain type in the component? Do I still give it a class even though it doesn't add any additional meaning?
The I started thinking that I'll only add enough classes to uniquely identify each tag. So if there's only one input field in the component, I won't give it a class at all, because the CSS selector ".foo-calendar input" will find it. But this approach seems a little too subjective.
Another question I have is, do I prefix all my class names with the name of my library, or only the "top-level" classes? Or do I nest the class names? In other words if the calendar has class foo-calendar, then does the month display have the class "month" or "foo-month" or "foo-calendar-month?"
What strategies do you follow for assigning CSS classes to library HTML?

I'd say more classes is better (to make css selection easier), and namespace them all (to avoid collision), but I'm imagining a WordPress plugin or something modular that I might want to plug into my existing website.
I really like the way Gravity Forms structured their html classes, because it makes it easy for me to tweak and customize without having to touch the markup, so if that's what you're looking for, maybe take a look at their CSS Guide: http://www.gravityhelp.com/gravity-forms-css-visual-guide/

I suggest looking into OOCSS (Object Oriented CSS).
Code - https://github.com/stubbornella/oocss
Introduction - http://www.stubbornella.org/content/2009/03/23/object-oriented-css-video-on-ydn/
I personally like this method because it feels easier to style elements on the page.
The basic idea to evaluate the styles you have on your page then create some general purpose classes that can be applied throughout your site. Sometimes I get very granular and I create a class like .bold {font-weight:bold} but most of the time this should not be done. Also another key idea is to separate CSS structure (your grids, positioning, etc.) and your styles (colors, font-weight, backgrounds, etc.). This is done to improve maintainability.
If you find a common theme in how your widgets are styled then break that out into a class and apply as needed. For example, all over the web there are elements that have an image to the left and text on the right. See your SO signature at the bottom of your question here. This could be made into a generic class that could be applied any instance of a widget with an image to the left and text on the right.

If you add a reset declaration you don't need to prefix all your classnames. You'll find a proper reset-css in several css frameworks.
I would use as less as possible classes for your elements (and would use no IDs), as you have described in the 4th paragraph.
Of course if you do this, your css selectors are becoming very long - but maybe you could use SASS/SCSS to prevent totally chaos ;-)

Related

What is the harm of using html custom elements which was created in the page itself?

Is there any harm if custom tags are used and created based on one's choice?
like the one below
<hello>hi there!</hello>
I tried using CSS
hello{
color:red;font-family:arial;
}
The above code works
I have used the above and also can add CSS. is there any harm of doing this, or the CSS features these won't support?
This is purely out of curiosity so don't suggest CSS edits or solutions please.
Why you can't make up elements
It is not valid HTML. Therefore how it behaves will be unpredictable.
It may work in some browsers, currently, but if any of your users visit your site on a different browser, they may get a totally different experience. Further to that, support could be dropped, or change at any time without warning.
Other options for custom elements
It is actually possible to define your own Document Type Definition (DTD), however that too is not a good idea.
Your best bet is to either stick with normal, well-supported HTML elements (see here for list of valid elements), or to use a web component framework, such as Vue, Angular or React, for custom elements/ components.
Don't forget, that you can add the class attribute (as well as others) to any element for styling, so for your use-case, there isn't any need to have additional elements.

Namespaces in CSS and Styling Conflicts

I am developing a web product, that when used, it generates code that the users would embed in their site.
The generated code contains HTML, JavaScript, and CSS. And when embedded in a page, it will show along with other content in that page that I have no control over. In other words, the code generated by my product would be embedded in a webpage that already has other content in it. I do not have control over the styling and content of that page.
Now, I am worried about styling naming conflicts. Assume I am using a CSS class named .amazing-color and it styles certain components a certain way.
Assume that a web page that uses my code coincidentally had a styling also named .amazing-color which would have different styling code, and may overwrite my own styling.
My question is, how can I prevent this from happening? How can I prevent naming conflicts in CSS?
You may suggest that I have complex names for my styles, so I would use .my-super-amazing-color-212321, but that would lead to complex CSS classes that are not readable. I think a better solution would be by using namespaces. However I am not sure if there are namespaces in CSS, and if they exist, how can I use them. So, are there name spaces in CSS? Can you provide a sample code on using them?
Thanks.
First of all, you're not asking about namespaces in CSS, but namespaces in classes. Classes are an HTML feature, not a CSS one.
Now, there's no formal namespacing mechanism for classes, but a convention in such situations is to use a common abbreviation or initialism as a prefix for all the classes that you use. So you might use "mwp-" for "My Web Product".
Since you are generating the HTML, CSS and JS, you can probably make this prefix configuable, so users of your product can choose a different prefix if it clashes.
Finally, make it clear in your documentation for using your product what prefix you are using and how someone using your product can change the prefix if they need to.

How to extend multiple elements with Polymer

I know there is this question on multiple inheritance/composition. However, it seems like this question is more about how to reuse functionality from multiple existing elements in other elements. And obviously, the solution for that are mixins.
I would like to know, how I can actually "decorate" existing elements without really borrow functionality from them. We know there is this extends property one can use to extend an existing element with Polymer.
So making a normal <button> behave like a mega-button is as simple as attaching <button is="mega-button"> and write a component for it. But it turns out, that it's not possible to extend multiple elements. So something like extends="foo bar" doesn't work. What if I want to build a web component, that can actually be applied to different elements?
For example, I don't want to only extend <button> elements with mega-button but probably also an <a> element so that it looks like and behaves like a mega-button too?
The mixin approach doesn't really help here (as far as I get it), because they do nothing more then providing shared logic for different web components. That means, you create multiple components, and reuse logic (packed in a mixin) from a mixin.
What I need is a way to create one web component that can be applied to multiple elements.
Any idea how to solve that?
UPDATE
Addy answered with some approaches to handle that use case. Here's a follow up question based on one approach
How to find out what element is going to be extended, while registering my own in Polymer
And another one on Is it possible to share mixins across web components (and imports) in Polymer?
UPDATE 2
I've written an article and concludes my experiences and learnings about inheritance and composition with polymer: http://pascalprecht.github.io/2014/07/14/inheritance-and-composition-with-polymer/
If you need to have just a single import that has support for being applied to multiple elements, your element could include multiple element definitions which may or may not take advantage of Polymer.mixin in order to share functionality between your decorating elements.
So pascal-decorator.html could contain Polymer element definitions for <pascal-span> and <pascal-button>, both of which mixin logic from some object defined within pascal-decorator.html. You can then do <button is="pascal-button"> and <button is="pascal-span"> whilst the logic for doing so remains inside the same import.
The alternative (if you strictly want to do this all in one custom element, which imo, makes this less clean) is to do something like checking against the type of element being extended, which could either be done in the manner you linked to or by checking as part of your element registration process.
In general, I personally prefer to figure out what logic I may need to share between elements that could be decorated, isolate that functionality into an element and then just import them into dedicated elements that have knowledge about the tag (e.g <addy-button>, <addy-video> etc).

Is there some template engine like mustache, but which targets CSS?

Shouldn't be useful to have templated CSS? Let's say for example I want to decide at run time the class names of my CSS, or wich id to apply the template CSS to. It should be feasible in practice, parsing CSS is relatively easy and injecting / removing classes at runtime can be done. Is there a projects which does that?

Is using the style attribute frowned upon?

As someone who is beginning to make a transition from table based design to full CSS I'm wondering if using the style attribute to make adjustments to elements is considered "cheating" and if absolutely ALL presentation should be strictly in the style sheet?
See also:
A question of style - approaches to styling and stylesheets
There are cases where you know for sure that all you want to do is tweak the style of this one specific element, and nothing else.
In those cases you can happily use an inline style attribute. But then, at some point in the future, you'll realise that in fact you need to apply the same style to something else, and you'll realise you were wrong.
Been there, done that. 8-)
I feel there's an aspect that has not been touched upon here: the distinction between hand-edited HTML snippets and generated HTML snippets.
For human editing, it's probably better and easier to maintain to have the styles in a file.
However
As soon as you start generating HTML elements, with server-side scripts or with some kind of JavaScript, be sure to make all styles required for basic functionality inline!
For example, you wrote some kind of JavaScript library that generates tooltips. Now, you will inject DIVs into your page, that will need some styles. For example, position: absolute and, initially, display:none. You may be tempted to give these elements the class .popup and require that this class has the correct definitions in some CSS file. After all, styles should be specified in the CSS file, right?
You will make your JavaScript library very annoying to reuse, because you can no longer simply copy and invoke one .js file and be done with it. Instead, you will have to copy the .js file, but also have to make sure that all styles required by the script are defined in your CSS file, and you have to go hunting for those, and make sure their names don't conflict with classes you already have.
For maximum ease of use, just go ahead and set the required styles directly on the element as you create it. For styles that are purely for aesthetical purposes, such as background-color, font-size and such, you can still attach a class, to give the consumer of your script an easy way to change the appearance of your script elements, but don't require it!
You can use the style attribute, but the point of using CSS is that you make a change in a single file, and it affects the entire site. Try to avoid it as much as possible (old habits die hard)
It's not maintainable. All of us have done it. What you're best to do is put every adjustment into a style. Let me teach you something most developers do not know about CSS ... you can use N styles at a time.
For example, imagine you have a great style for colorized divs called someDIVStyle:
.someDIVStlye
{
background-color: yellow;
...
}
You want to use it, but just want to adjust the background-color to blue. Many people would copy/paste it and then make a new style with the change. However, simple create a style like this:
.blueBackground
{
background-color: blue;
}
Apply it as such:
<div class="someDIVStyle blueBackground">...
The style furthest to the right always overrides the properties of the styles preceding it. You can use a number of styles at once to meet your needs.
I agree with some other posters that it is best to keep the style information in the stylesheet. CSS tends to get complicated quickly, and it is nice to have that information in one place (rather than having to jump back and forth from HTML to stylesheet to see what styles are being used).
A little off-topic tip: Pressing F12 in IE8 brings up a great tool that lets you inspect the styles of elements in web pages you're browsing. In Firefox, FireBug does the same thing. Those kinds of tools are lifesavers if you want to know how a style change will affect an element.
It's a very "personal" question, to me the word "ALL" is a very strong word. You should do your best to have most of the styling in your css. but you can use style occetionally if it makes your life easier.
Generally it is best to have styles on the style sheet especially if it will be used multiple times, but using the style attribute is definitely not "cheating". A quick look through the stackoverflow source shows many examples of this.
Yes, it's kind of cheating, but it's up to you if you want to cheat a little. :)
The fundamental idea of having the styles in a style sheet is to separate the content from the layout. If you use the style attribute you are still mixing layout within the content.
However It's not that terrible, as you can quite easily move the style into a class. It's quite handy during development to be able to set a style on a specific element so easily without having to make up a class name and worry how the style will cascade.
I sometimes let the style attribute go through in the production code, if it's something that is specific for just one page, and if it's doubtful that it will be there for long. Occationally just because I am pressed for time, and it can be cleaned up later on...
So, even if you use a style attribute sometimes, you should still have the ambition that all the styles should be in a style sheet. In the long run it makes the code easier to maintain.
As others have said, in general, no.
However, there are cases where it makes perfect sense. For example, today I had to load an random background image into a div, from a directory with an unknown # of files. Basically, the client can drop files into that folder and they'll show up in the random background image rotation.
To me, this was a clear reason to dynamically build up the style tag on the div.
In addition, if you're using, for example, the .net framework with webforms and built-in controls then you'll see inline styles used anyway!
There can be very good reasons to put style information in a specific page.
For example, if you want to have a different header background on every page (travel agencies...), it is far easier to put that style information in that specific element (better, in the head of the document...) than to give that element a different class on every page and define all those classes in an external style-sheet.
The style attribute does have one important use: setting style programmatically. While the DOM includes methods to manipulate style sheets, support for them is still spotty and they're a bit heavyweight for many tasks, such as hiding and showing elements.
Yes, the style attribute is frowned upon in general. Since you're moving to the CSS method from table-based, I'd strongly recommend that you avoid inline styles. As a previous poster pointed out: bad habits are hard to break and getting into the habit of using inline styles for their temporary convenience is a mistake. You might as well go back to using the font tag. There's really no difference.
Having said that, there are occasions where it makes sense to use a simple inline style, but first develop the habit of using stylesheets. Only when you're comfortable with putting everything in a stylesheet should you start looking at shortcuts.
I think that's the general consensus of everyone who posted an answer