I am currently beginning my forays into HTML and CSS. Already I have become frustrated at the standard box model setup where padding adds to the size of the box itself, so I've set in my CSS templating to use border-box models. Is this ok, or is it not recommended as a best practice / not recommended for learning HTML/CSS? Will many javascript/jQuery scripts break if I use it rather than the standard box model? I don't want to get into the habit of using it if most developers shy away from it or if it will cause pre-made scripts and plugins to break.
The reason I am asking this is because it seems like there are some people who are disgruntled with the current box-model, and if there are any signs that the standard box model might be changing to the border-box model, then I may want to stick with it.
You are asking us if you should use the standard approach, or the non-standard approach. The answer is going to be: use the standard approach. Otherwise, you'll always be fighting CSS.
The best analogy I found for the 'standard' mox model is to pretend you're looking for a box to ship something and need to figure out the space needed. Your object is going to be a certain size, and then you need to leave room for all of your packing materials (the padding).
EDIT:
I admit that I wasn't all that familiar with that CSS property. After doing some research, it does seem to have practical uses (especially when trying to divy up columns in a fluid layout). That said, I wouldn't call it a replacement for the standard box model, but rather an alternative to use when it makes sense to use it. Learn the standard box model, and then you'll know when it makes sense to alter it.
If you use a css reset (as is fairly standard practice) this become much less of an issue.
These are two of the most popular
'The Meyer' - http://meyerweb.com/eric/tools/css/reset/
'YUI Reset' - http://developer.yahoo.com/yui/reset/
These will remove all browser default styling, giving you a 'blank canvas' on which to build. You'll find the majority of CSS frameworks (and most sites) will use a reset of some description. With YUI they even give you another stylesheet to build back some of the removed styles (in a cross browser consistent way).
As for Padding/Margin/Borders specifically (which is what you really asked about in the first place) - it really depends on the context. They exist for different reasons - for example I tend to use margin when spacing divs, and padding when spacing headings but there are no hard and fast rules.
Related
A while ago I came across this SO question:
CSS set background-image by data-image attr
If I understand the question correctly, the OP needed the ability to set an attribute on certain HTML elements and make the accompanying CSS interpret it as a URL to the background image of such elements.
I had recently faced a similar situation, where the background image of an element that had until then been static was changed into getting a variable image from a database. I considered several options but, among them, replacing the affected element with an <img> element had several undesired side effects and building dynamic .css files seemed an overkill, so I tried using a custom data- attribute and CSS's attr() function to bind it to the element's background-image, but it did not quite work due to the then limited implementation of attr() among different browsers.
In my case, I ended up deciding that a background image served from a database was content rather than design and took the approach that seemed easiest, given that browsers have supported inline CSS styles for quite a while now: I applied all non-variable styles as a rule on a separate stylesheet but I kept the variable background-image as an inline style in the element where it needed to be applied.
Since none of the answers posted to the question I am referring to suggested the usage of inline CSS styles, I did so myself and my answer has since been downvoted several times without a hint of reasoning regarding why. I understand that downvotes needn't be justified and I am happy with that, but I am worried about not seeing some obvious caveats that are waiting to bite me when I least expect it.
I have read SO threads What's so bad about in-line CSS?, using inline css - a no-no or okay in certain situations? and Inline styles vs styles in CSS, as well as some external discussions such as https://teamtreehouse.com/community/when-is-inline-css-a-good-idea and https://www.thoughtco.com/avoid-inline-styles-for-css-3466846 with respect to the usage of inline CSS, and from them I gather more or less the following:
Inline CSS is a maintenance nightmare.
It is a "best practice" separating content from design.
Inline CSS seems to be almost OK when prototyping.
Inline CSS is a necessary evil when building HTML emails.
I think I understand the arguments given in those discussions, but none of them seem to consider cases of dynamic inline styles being applied, so they do not effectively address my scenario. Based on my own experience,
That particular piece of maintenance has become trivial, since the value comes from a relational database, which has enabled us to provide things like user-customizable backgrounds without ever revisiting the source files.
It is an even better practice to analyse each scenario individually and apply the specific solutions that provide the greatest benefit at the lowest cost, regardless of what "best practices" guides may say about general scenarios.
I personally do not use inline CSS for prototyping because the browsers' development tools keep track of my changes when they are applied on a separate file but not when I define them inside the HTML block.
HTML emails make me shiver.
Nevertheless, I would really like to know why is this such a bad idea. In what ways can I expect this decision (using inline CSS to set the background-image style of an element to a value coming from a database) will come back to haunt me?
Thanks
Looking at the CSS Zen Garden, I can see how powerful and convenient it is to separate design and content. The possibilities seem nearly endless. One can change the style sheet and the appearance of the whole site can be drastically altered.
Let's say I'm putting together the HTML part of a website. How do I know where to put divs, where to nest them, etc?
For example, let's say I want to centre something on the screen: I would generally nest 3 divs together: one display:table, one display:table-cell, and one margin-left:auto;margin-right;auto which would have the content.
Let's say I'm just doing the HTML content, but am not thinking about the design at this stage. How would I know that I need to nest together 3 divs if I don't necessarily know I will centre it on the screen?
Or if I have one design now with HTML/CSS and I have my divs and spans all set out, what happens in 18 months if I decide to change the CSS for a completely new layout? Sometimes I will have extra divs and sometimes I won't have enough.
Presumably it would always be better to have more levels than not enough. That way, the worst thing that can happen is that you have a few superfluous divs which aren't styled and have no visible effect.
Is this generally a problem others have? I know CSS Zen Garden is a special case, but would you generally change the HTML code considerably when you change the corresponding CSS?
I've worked in web development for many years, and over here in Reality things are a bit different from Theory: There is no such thing as separation of content and presentation. You'll always end up sliding in additional divs.
You better follow the YAGNI principle. Don't worry about your CSS as you're writing your HTML. Come back later and do the neccessary adjustments.
As for Zen Garden, you'll find a comment in the source code:
This xhtml document is marked up to provide the designer with the maximum possible flexibility. There are more classes and extraneous tags than needed, and in a real world situation, it's more likely that it would be much leaner.
Theoretically, in order to change the style, you wouldn't have to touch the data (HTML). In practice, there are those problems you mentioned.
What I would do is a more-or-less sensible usage of divs (so for example, anything I think that I might want to move around, or any bunch of HTML that I would want to refer to together - would go in a div of its own). Otherwise, don't use too many divs, for reasons such as readability, maintainability, and size of HTML.
Then, whenever you want to change the style, make the minimal addition of divs so that you'll be able to do what you want.
This is a genuine problem with CSS and it was recognised by the authors of CSS3. The most recent published draft (2003) of the CSS Generated and Replaced Content module discusses a pseudo element called ::outside which would have solved the problem you describe. It would, when implemented, for
<div class="mycontent">Some text</div>
have allowed you to write:
div.mycontent { margin-left:auto;margin-right:auto; }
div.mycontent::outside { display:table-cell; }
div.mycontent::outside(2) { display:table; }
Unfortunately, the ::outside pseudo-element never made it into the CSS3 selectors spec, and the next draft (2011) of the CSS Generated and Replaced Content module will not mention the ::outside pseudo-element.
So we're stuck with putting wrapper divs everywhere just in case which as you note, does not allow proper separation of presentation and content, and remains a deeply unsatisfactory situation.
It all depends on how your website is driven. If you are using template files, the amount of updates will be minimal.
You do not want to overload your code with superfluous Divs because a) load time (althought it will be minimal difference in theory) and b) because it will create a lot of confusion when others edit your files.
From your example, it looks like you may be used to table style layouts. Using Divs to contain your layout will make flexibility very easy.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Inline styles vs styles in CSS
i guess i'm looking for some opinions on this. I am all for using css styles as classes in a separate .css file. But every once in a while, i run into a scenario where i need just some padding for a particular element or change the css class' width only in one particular situation. Is it okay to add inline styles in those scenarios? do people do this or always create classes for everything.
My theory would be if its not something reusable or does not contain more than 2 styles, why create a class for it. Am I wrong in thinking that?
Summary of Answers (since there are many)
It is better to avoid inline styles because
1) style sheets provides more maintainability.
2) better separation of html data and layout.
3) re-usability of styles.
4) probably provides better caching.
Overall, css style sheet is the best practice.
Anything is reusable if you think it through and set it up correctly. Even one-line, one element CSS attributes can be beneficial if reused. This takes advantage of the concept of caching, which will keep the css in memory after the initial load hit. No matter which way you slice it, inline styles add to your overhead every load without question.
Never mind the fact that inline mixed with a proper css document adds overhead to your own debug time, figuring out where the darned calls are coming from.
Two answers to this one:
1) It's considered good practice to keep your design (css) and your data (html) separate. By adding in-line styles, it makes it more difficult to revise the look of a site, it makes it more difficult for future programmers to modify your site, and is overall NOT the best way to go.
If everything is in a CSS file(s), then you can change the entire design of your site without having to mess with the data (HTML) of the site. This is ideal.
2) Yes, a lot of people still use inline styles very often when tweaking something small, regardless of "best practice".
You said: "if its not something reusable or does not contain more than 2 styles"
I would add another reason to use external stylesheets: maintainability. If you (or someone else) has to fix your code in the future, you will have a much easier time of it if all of your styling is in one place. You will not remember that you added that little bit of styling inline, and you may spend hours hunting for it.
It is a good standard to keep all styling separate to maintain clean, maintainable code.
That said, we can acknowledge that it is "ok" to use inline styles, as you asked in your question. However, best practice is often something more than "ok" and should serve as a guide as often as possible.
I feel like a good balance is all that you need. While its typically considered better practice to create classes as much as possible, there comes a point when its just easier to use an inline style. Like you said, if there's just that one element that needs that minimal extra padding, its not a crime to give it that. At least, in my opinion it isn't. But definitely be in the habit of making classes for just about everything, except minor exceptions.
Its not just about re-use, its about getting into the habit of doing things correctly. What if someone else needed to help you on the project, they would have to sift through your whole file to find every instance of an inline style somewhere...
People who know their CSS always create a specific style rule for everything.
Thats my opinion and I believe it to be shared among my colleagues.
A big point for me is: maintenance. When all of the CSS is in external stylesheets, it is going to be relatively straightforward to find the styles your looking for to edit them. If there are inline styles, it will be harder to find what you're looking for.
I'm usually skeptical about claims that a style never be reused. If it happened once, it is likely to happen again. Coding for reusability is always a good idea and usually results in cleaner, better written code in my experience.
Even in these situations, I will usually add a unique class somewhere up in the target element's ancestors - often on the body tag - that I can use to target the the "unique situation" and keep all the CSS in the external stylesheet.
That being said, I do occasionally use inline styles. When I do, it is almost exclusively in a situation where I know that I will be animating styles with JavaScript after the page has loaded. I only do inline styles for the properties that I am going to animate and the rest go in the external stylesheet.
So I've read this article and from what I understand, each native browser widget is actually a combination of basic elements, styling and scripts. This begs the question - if they are consisted of basic building blocks, does that mean that there is a way of customizing them through JavaScript? And I don't mean in the replacement sort of way, as some JavaScript libraries/plugins do - simply by accessing their "Shadow DOM" properties and adding some CSS styles to them, for example. Also, this page has some use cases, but nothing practical.
Anyone ever tried anything like this? Is it possible at all? Downsides?
Thanks.
My main concern would be that the implementations of the shadow DOM would be different between browsers and then you are basically back to needing some sort of library to deal with it. I'm not sure if that is the case, but its worth considering. Also, given that there are so many widget libraries available and that is the standard way of handling most of these issues, is it worth taking on a whole new set of unknown issues instead of just working with known elements?
Looking at the source code for Stack Overflow, I noticed they have used tables and inline CSS quite a bit, also something I found odd was use of inline table attribute formatting.
<table width="100%">
I'm just curious if there was any specific reason(s) to why they used tables to structure their template instead of the popular (or used to be popular) DIVs.
As well...the purpose of using CSS includes and using inline CSS on the same page (I know there is probably a great answer/solution(s) for this...I'm just curious to what they are)
I understand there is nothing wrong with using tables for tabular data...but in this case Stack Overflows tables are used for structure.
Tables vs. Divs is a pointless holy war.
There are specific issues with using tables in particular ways for layout that can cause problems. One of these is building an entire site layout in a single table in order to handle margins and placement -- because of the way tables are rendered this frequently means a website will not render progressively by the browser engine as the content downloads, and can only be rendered after the entire thing has been received. For a large page or slow modem user, they may be staring at a blank page for quite a while, which is a "Bad Thing". Never mind a lot of the inconsistencies in table rendering in the mozilla/ie5 generation of browsers that made consistent cross-browser table layouts somewhat painful, especially with images in the cells.
Supporters of the pure div path like to talk about content vs. presentation, because in theory HTML 4.01 is pure content, all of it meaningful. The divs provide meaningful organizational structure in an abstract sense, which is then given presentation exclusively by CSS. In these arguments, tables are valid only if being used to contain actual tabular data. Of course, this ignores the fact that for any sufficiently complex layout, there are almost always quite a few empty divs floating around simply to support the necessary hooks for presentation CSS, breaking the first level of this abstraction. Once this abstraction is broken, there's no law stating that, when your layout simply requires a presentation hook in the HTML that has no meaningful content, a div is somehow more appropriate than a table. If you are stuck with the choice of a meaningless div or a meaningless table in order to make your layout work, choose whichever is easier.
In the end, it's about being aware of the limitations in all methods and using the one that is most appropriate. There are many cases where using a table is simply easier than setting up a pointless (i.e. not-content-meaningful) array of divs, and the table rendering limitations don't apply. If the table is small and represents a minor chunk of the interior content, the rendering delay is not relevant.
Having not been involved in SO development, I only speak generally:
I've found that tables are often easier and more consistent across browsers than CSS-based layouts.
Also, emitting random CSS here and there often happens when trying to get things done. It can be refactored later, I suppose.
With respect to why they chose to set a table's width in HTML instead of CSS, I couldn't say.
I know that SO used a real, honest to goodness designer when they started. I don't know, though, if that designer gave them an image of what the site should look like or actual markup.
Please don't flame me for saying so. We're not all CSS ninjas.
SO was probably written by programmers, not web developers.
Tables are not evil, but certain uses of them (which used to be everywhere) are evil. Namely, using spacers, nested cells, etc, to control margin and padding.
Even though everyone now a days talk about layout with css and divs, the truth of the matter is css is awful when it comes to layout. You can only do so much. Look at some suggested solutions to get 2 or 3 column layouts using css, they all suck. Throwing a <table><tr><td id="left-column"><td id="right-column"></tr></table> is a lot easier.
css is just not suitable for non-trivial layout (and by that, I mean pure div/css)
The table solution I just threw above needs to use css to control width and padding and borders and background images, etc.
Give up and use tables
Because Internet Explorer does not support the display:table CSS property, which is what provides the grid-like layout model (equivalent to how html tables are rendered). The grid-model is the simplest and most flexible way to model many layouts.
So you have three choices, none of them attractive:
sacrifice support for Internet Explorer (all other modern browsers supports display:table property, which have been part of the CSS2 standard for more than a decade)
use cumbersome CSS workarounds which are costly and hard to maintain.
sacrifice semantic purity and use TABLE-elements.
SO chose the last option, probably because they think support for Internet Explorer users is more important than support for disabled users, and because they wanted something that was quick to develop and simple to maintain.
Jeff and his team were getting it done quick and dirty. This was a very quick development cycle, without the time to refactor out much of the clutter.
And face it - unless you are an expert, CSS is time consuming for table structures.
Inline styles and included css are just a sign they were trying to get it done, not worrying (at least for the first iteration) about the "right" way of doing it. The right way was whatever worked and got it done fast.
IE8 will be the last major browser to finally add support for the CSS display: table-* values, so the distinction will go away. Hopefully this will end the whining about how hard CSS is, and people can stop polluting markup with presentation.
I'm a reasonably smart person, not too far below average at least, but I find css layout totally unintuitive. Tables are extremely intuitive. I think one measure of a good technology is how often you have to refer to the manual while reading it. Tables blow CSS out of the water in this way compared to css. Again and again, when using css, I have to dig to figure out how to do something like this
Tables and layout
SO's layout is not based on tables.
At a quick glance, I'd say SO layout is 80% div-based and 20% table-based. Tables are used in the header and on the "badges" box. Table use is appropriate for badges IMHO (it's a list of items, after all), not so good for the header.
Anywhere else, divs are used.
Inline CSS
Again, many inline definitions are used (probably to quickly mockup site's structure), but SO correctly uses also css (to style the divs and to provide print formatting).
"css is too hard" and "tables are quicker and easier" excuses, coupled with some down right misgivings about what's wrong with the use of tables for structural markup.
The question is asking why SO chose to use tables, inline css, etc., to which I think the answer is probably nothing more than that either they aren't familiar with graceful degradation and semantics, or they didn't consider it important enough to devote the time and resources.
There's nothing wrong with not knowing css, but to dismiss semantic markup and the proper use of css just because you don't know it is just WRONG.
To champion that your site looks the same in every browser using tables, while not giving a seconds thought to those that don't use a visual browser smacks of selfishness - that's a strong word, and I apologize for the tone, as I don't intend to insult.
BTW - I take umbrage at the idea that the use of tables for structural markup is a 'holy war'. While some might think that Semantic markup is overly championed, it is not based upon blind faith.
CSS is great and can really simplify your markup, however, sometimes aligning content with tables is just easier and more reliable. Also for code generated dynamically some of the pain points for non-CSS based styling are less bad. Specifically, since you are dynamically, creating the markup you can re-factor the styling elements in the functional code.
As for the in-line styles, I often use these when I'm building a page and then try to re-factor them into an external sheet later. This makes it a little easier for my testing (no need to do a hard refresh) and changes are in one file instead of two.
My thougths would be they went with table because (apart from the argument table vs css)
They needed to get the functionality get out rolled quickly to have an opinion
After all this is just the public beta.
They were experimenting with ASP.NET MVC more and layout issues less
SO is all about programming questions and answers and at the end that what matters.
SO is all about recognizing the contributors by rewarding points and badges which it does quite decently (this may also be a controversial topic).
and so on....
I have no idea, but the only explanation I can come up with is that Jeff isn't as supportive of web standards as he'd like us to think and none of the team are that hot on CSS. Programmers often use cross-browser-ness, ease-of-use and numerous other supposed time benefits to excuse their lack of CSS skills. And I don't mean that as a criticism, they're probably really good at programming C#/Java/Ruby/SQL/whatever, they just can't seem to admit that they don't really know something as well us a bunch of polo-neck wearing, Mac Book wielding designers...