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?
Related
What is the most common or accepted way to prioritize between clean html code and clean css code?
As I see it there are two possible approaches…
Either you can go for a html code with minimal markups related to styling. The downside is that the css tend to be a bit messy and perhaps a bit redundant when you for example add similar styling to different objects (which in this approach lacks suitable classes).
The other approach results in a cleaner css code where you have predefined classes for different stylings, think w3.css or bootstrap. This time the downside is that you may end up with a html code that heavily relies on the class attribute of the tags, sometimes the combination of several classes; meaning that the html markup isn’t really separated from the styling.
I realize that there is no definite answer and that the line between the two options are floating. But what is the preferred approach, given that you are not using any precompiled framework?
Edit:
The question is not about inline css. It is about how to think regarding the use of predefined css classes. For example… if you add a class similar to “w3-panel” to some divs then you effectively add some margin in the html code. If you instead target those divs specifically by using selectors you keep the html free of styling.
The former produces cleaner css code and the latter produces cleaner html code. Which route is the most accepted one when not implementing a framework (forcing you to style by adding classes to the html)?
The advantage of the separation is to make it easier to maintain and if you find a css too messy, take a look for SASS or SCSS. And if you are using jQuery to manipulate your CSS, it is easier if you have your definitions in a CSS file. Imho the worst choice you can make is to mix it up - some definitions in CSS and other in the HTML - you may find it useful now, but try to change the site in a few months.
It really depends on your business of application.
If you put styles in same file in html file size would be increasing and it would be getting messy when you added new css each type, but as your css and html are in same file and css is well written and used, page load time would be minimum as html find css in same file.
If you put styles in separate css file, it would be well readable and accessible, you would have separate layer for styles and markup. But each your page load, your included css file would also be load in addition hence increase page load time.
If your application or html page is one time i.e no much furthur additions in future and will be remain same mostly then no need for separe css file.
If your application would be growing or html page being updating quite often, then you should be separate css files.
Personally, I think it is best from the beginning to split the code as much as possible. (HTML for markup, CSS for styling, etc).
Pro(+)
It is easier to troubleshoot
You can scale and later on introduce support tools such as SASS for CSS, etc.
A task can be splitted between persons.
Easier for another programmer to understand the setup of files.
Neg(-)
Take a bit energy to be disciplined and really keep coded splitted.
You sometimes would need a larger monitor to have the splitted codes in parallel view.
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.
I'm trying to figure out HTML styling.
(I'm new to HTML (via shiny in RStudio), so bear with me. )
I get the general setup (i.e., style = “property:value;”), but where/how do I actually find the list of possible property names to assign/edit?
In other words, how do I know what the potential properties are?
Is there a list of them somewhere?
Quality + thoughtful markup is key to writing sensible style rules.
Ensure you write semantic markup - and you'll have much better time targeting the elements with CSS. These are two lists of EVERYTHING. : )
https://developer.mozilla.org/en-US/docs/Web/HTML/Element
https://developer.mozilla.org/en-US/docs/Web/CSS/Reference
I should also add: https://caniuse.com to cross reference browser support of any given newfangled css property.
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).
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 ;-)