When to style directly in the HTML instead of CSS - html

I've tried to search for a subject on this, but I haven't found any, so I thought I'd go ahead.
My question is when it is correct, if anytime, to just put your style directly in your HTML file, instead of using a .css file.
I mean, I get that it is very useful to use your .css file when you have alot of things that needs to be repeated, or is used on several pages.
But in my case, I have one page where I'm about to style something, that I'm pretty sure only will be on that page. This being the width, height, and small stuff for a div.
To show you what I mean, here's the code:
<div style="margin:0px auto; width:600px;">
<div style="float:left">
<p class="InputFieldsText">Brugernavn</p>
<div class="InputFields"><input name="Text1" type="text" class="Medium" placeholder="Din e-mail adresse" /></div>
<p class="InputFieldsUnderText">Glemt dit brugernavn?</p>
<p class="InputFieldsText">Password</p>
<div class="InputFields"><input name="Text1" type="password" class="Medium" /></div>
<p class="InputFieldsUnderText">Glemt dit password?</p>
<input onclick="window.location='user_page.html'" class="LargeIndent" name="Submit1" type="button" value="Log ind" />
</div>
<div style="float:left; width:172px; text-align:center">
<img alt="" height="128" src="images/lock.png" width="128">
</div>
</div>
So, as you can see, in some divs I styled it directly, instead of coming up with a name for my class and put on there.
I know it isn't wrong to do, since it will come out the same if I used it in my .css file and called a class, but is there a "guideline" or something that this and this is not recommended etc. etc.
Hope you understood my question. Really not that big of a deal, I've just always wondered :)
Regards

The answer is pretty simple, IMO: never. :)
You should always use a style sheet, because it allows you to quickly and easily change the entire appearance and layout of your site. If you embed the style information in the HTML directly, you have to work a lot harder if something needs to change; with a style sheet, you simply change the CSS file in a single location, and the change becomes global everywhere that style sheet is used.

It's best not to mix presentation with content. To simplify your CSS there is nothing wrong with using smarter selectors and IDs for elements for which you know there will always be one and only one. You don't have to define classes for every little thing.
In my opinion, inline styles make markup so cluttered, especially with large style declarations which cause line wrapping.
A small block of style inside the HTML page (instead of an external file) might be acceptable in some cases as it reduces the number of requests sent to the server. Server-side processing can be used to accomplish this by reading a separate stylesheet file and injecting the style directly into the page. With this approach, there is a trade-off between page size and the number of HTTP requests.

During development of a page I bung eveything into the same file.
just being lazy - have the stylesheet in the head part.
Then when in production seperate the HTML from the CSS. actually I do that during development when they share common features - a cut and paste job is required.

Never have your style information inline
When working with hierarchical template systems, I sometimes find it convenient to place style definitions in a stylesheet in that template, which ends up being part of the page. If these need to be reused, they can be migrated to a separate stylesheet.

Well, first things first. Styling takes some order of precedence :
inline styling
CSS in HEAD
imported CSS files
That is, if a specific element has some attributes defined in the .css file, then you can definitely override them by using inline CSS (<div style='...'></div>), for example.
Apart from that, I suppose it's merely a matter of taste and of how 'cluttered' (vs 'compartmentalized') you want your code to end up. Don't forget that CSS's main purpose is to separate : LOOK from STRUCTURE.
My GENERAL STRATEGY is :
Use CSS files, for better organization is bigger sites, that may be used an re-used in various files (portability)
Use CSS in HEAD in some "quite" big, but not too big chunks of CSS code, that are page-specific.
Use inline CSS for local modifications only (in REALLY small pages, or for existing specifications that I want to alter on location)...
CONCLUSION :
Anyway, as your main issue is about inline CSS, here's my 2 cents : inline CSS makes the code easily unreadable (at least for my taste), so why do it unless necessary?

You should always use a external .css files, because external style sheets enable you to change the appearance and layout of all the pages in a Web site, just by editing one single file!
If you will use inline css rather than external css in HTML pages that will take of much time to edit the changes so should use the external css files for smoother process.

Related

Angular: safely embed markup preserving style attributes

I need to render an HTML markup preserving styles.
<div style="text-align: center">Some text</div>
And here how I render it:
<span [innerHTML]="content"></span>
But innerHTML removes style attributes. There are dozens and dozens questions on the internet and the only solution provided makes use of DomSanitizer.bypassSecurityTrustHtml. But there are XSS security risks and this is not an option for me.
On the other hand I'm considering CSS as pretty safe, except couple of tags that could be whitelisted.
So there is an approach to render HTML markup, preserving CSS attributes but XSS safe?

How to Isolate some part of HTML code style & formatting? [duplicate]

I am trying to figure out a way to display an archive of email newsletters on my client's site. The issue is that the newsletters are full of a zillion inline styles, which is great for seeing them in Outlook or wherever, but they're not looking too hot in an otherwise-nicely styled site.
My goal is for my client to be able to copy the entire source code of a generated newsletter (which her list management company* gives her access to) and paste it into the CMS (drupal, if it makes a difference).
*Constant Contact? Mail Chimp? I forget. One of those.
Then I'd like to display it on her site, inside the basic structure (header, nav, etc) of the rest of the site. If this was 1997, I'd say "iframes!" and be done with it, but A) that seems like a lame solution, and B) the code doesn't actually exist on a page by itself, which I think is required for iframes.
Is there some kind of tag I can put around this block of HTML to isolate it from the rest of the site's styles? Or is there another way to go about this entirely?
Thanks!
IFrames are the only way to go that I've ever been able to find. The only alternative to this would be to override every style in the parent page's CSS for the newsletter display area.
As you noted, using an iframe will probably require you to host the newsletters in an independent file. The only alternative to this that I'm aware of is that you can use JavaScript to dynamically create and/or populate the iframe.
If you go with this method, you could have the newsletter present in a div with a specific class, and then use JavaScript to move the div into an iframe. The big downside being that this wouldn't happen for users without JavaScript enabled.
9 years later and there still isn't a better solution.
If you don't have an external source (you can't add html into a frame manually) you need to use js to insert the messy html/css (in my case I use it to view emails)
<iframe class="my-frame" width="100%" height="100%" src="about:blank"></iframe>
and js:
const frame = document.querySelector('.my-frame');
frame.contentWindow.document.open('text/html', 'replace');
frame.contentWindow.document.write(hereGoesYourMessyHtmlCss);
frame.contentWindow.document.close();
Is there a reason why you can't use a modal? That would allow you to force a new request and make the page render how you'd want it to by not applying your general stylesheet while at the same time keeping your user on the desired page. Of course, it doesn't display the element inline so-to-speak, but it's nearly functionally equivelent.
Cutting and pasting raw HTML presents too many security problems, in my opinion. Never trust user's input. Even when the content is entirely benign, next week the designer of newsletter might decide to change their formatting or incorporate some javascript and you'll be responsible for anything that might go wrong.
Therefore I would implement a parser that would drop anything but the content part and leave only b, a, h*, blockquote and similar simple elements, like the ones allowed in forum posts, as well as their styles. After that, you can display it as a normal post in a CMS. I don't see any reason why that should look differently.
As for how to isolate that from your other CSS, you don't really need to if you are careful that all of CSS rules of your CMS apply to elements with specific classes. Alternatively, do a CSS reset for your posts:
.post p {
margin: 0;
...
.post /* all the standard CSS reset rules preceded with .post */
and then
<div class="post"> content parsed from your CMS </div>
Another option that I haven't used myself but am looking to possibly leverage in a similar situation is to use the Shadow DOM which is part of the Web Components spec. My main concern is that we still have some user's using IE 11 and while there seems to be support for polyfills it doesn't look like covering all browser's is real straight forward based on what I've read elsewhere.
Some details on how to use Shadow DOM to this effect can be found here and here. I've also created a small gist that I've created to demonstrate basic idea that I've been formulating as I learn about how the Shadow DOM works which I'll be updating as I learn more. Below you can see a snapshot of the content of that gist.
<!doctype html>
<html>
<head>
<style>
.row {
display: flex;
}
.column {
flex: 50%;
padding: 10px;
height: 300px;
}
* {
color: Red;
}
</style>
</head>
<body>
<div class="row">
<div class="column" style="background-color:#aaa;">
<h2>Column 1</h2>
<div id="content1">
SOME CONTENT FROM CMS
</div>
</div>
<div class="column" style="background-color:#bbb;">
<h2>Column 2</h2>
<div id="content2">
SOME MORE CONTENT FROM CMS
</div>
</div>
</div>
<script>
document
.getElementById("content1")
.attachShadow({ mode: 'open' })
.innerHTML = `
<style>
*{all:initial}
style{display: none}
div{display: block}
</style>
<h3>This text is not red</h3>
<div>slot content: <slot></slot></div>`;
document
.getElementById("content2")
.attachShadow({ mode: 'open' })
.innerHTML = `
<style>
*{all:initial}
style{display: none}
div{display: block}
</style>
<h3>This text is not red</h3>
<div>slot content: <slot></slot></div>`;
</script>
</body>
</html>

Tags That Will Operate As Multiple Tags

I had a very hard time trying to word what I wish to know how to do, nor could I locate any post or website from Google that had my answer probably due to not being able to word this correctly, but I will explain in fullest detail.
<br />
<hr />
<br />
Break, horizontal, break is my way of separating parts of the post from another. How can I group the three into one simple tag that can replace the three, thus saving me time and hassle .
It would be also helpful to know if there are ways to define tag groupings with more than just empty tags like a tag identified by the string title1 would be a tag containing all the format, text, and all sub-elements of the template that was coded somewhere else.
If this question has already been posted then I am sorry. Thanks!
You don't need the <br> tags because <hr> is a block level element and automatically creates a line break. If you're doing that to get some vertical space above and below thw <hr> why not just use CSS to give the <hr> some margin?
hr
{
margin-bottom: 20px;
margin-top: 20px;
}
Neither <br> nor the proposed alternative <hr> are particularly well-suited here.
You need to learn about CSS. All you need to do is apply appropriate styles (i.e. a margin) to the elements that wrap your posts.
<div class="post">
<h1>Post #1</h1>
<p>something</p>
</div>
<div class="post">
<h1>Post #2</h1>
<p>something else</p>
</div>
div.post {
margin-bottom: 3em;
}
If you are using HTML5 then use <article> instead of <div class="post"> to denote individual posts.
As for grouping tags, this is currently not possible in plain HTML, you need to apply some preprocessing for that. The usual solution is to use a content management system which creates the final HTML based on your content and an HTML template.
Whilst this specific problem can be solved with a little bit of CSS, it sounds like you need a layout or templating engine of some sort in the long run. I'm a rubyist by trade so my go-to solution for doing this is Jekyll.
What Jekyll does is generate static html files from layouts and content that you write. You can abstract a lot of the repetitive layout markup into separate files and then just reference them when you need them.
The following guide is a good place to get started: http://net.tutsplus.com/tutorials/other/building-static-sites-with-jekyll/
If you're already working with another framework then do some reading around it first to see if there's something there you can use. If you're just writing straight-up HTML/CSS though, then definitely give Jekyll a try.

CSS Form Frameworks?

I have been looking at a couple html/css form frameworks like Uni-Form and Formy. They provide easier management of html forms. I was wondering if anyone knows similar ones. I am not looking for css grid frameworks nor Yahoo's YUI.
blueprintCSS has a form plugin (I don't know if it can be used alone, I haven't tried to do that). http://www.blueprintcss.org/
http://www.blueprintcss.org/tests/parts/forms.html
Baseline CSS also has a form system. I haven't personally used it.
just tried formy and uniform..
i want something styled a bit simpler, just to look clean so i can do the rest..
Formalize is another one, quite simple, worth a look.. looked at uniform and jformer and they're both too comprehensive, if that could be used as a reason to ignore them
Formalize
Uniform (different from Uni-Form)
There is also Tacit.
It's a "class-less" CSS framework were you only need a single <link> statement in your HTML and the web page will have a complete look. In particular, for forms, you get a more finished appearance out of the box, just by including the CSS file, and you don't need to attribute specific classes to your form elements. It also guarantees your form will work visually fine both in Desktop and in Mobile.
You can get an overall idea from the demo page.
Here are also a few examples of pages that use Tacit, and the only work put into was including the CSS file: http://filfreire.com/, http://www.jare.io/, https://socatar.com/,
I think uniform is the best solution for forms.
Html is good and understandable, it has a bunch of tricky form examples solved very nicely ad it pays attention to usability much more than other frameworks.
Other seem to insist more on a vertical typographic rythm than common sense and usability. :)
There is also: Formy http://code.google.com/p/formy-css-framework/
I have developer a single class CSS framework just for forms. The class "form" can be added to any form input to style it properly. You can see the examples on the documentation: https://form.js.org
Here an example of mailing list form:
form {
margin: 1rem;
}
<link href="https://cdn.jsdelivr.net/npm/#codolog/form#1.0.0/dist/form.min.css" rel="stylesheet"/>
<form>
<div>
<div>
<input type="email" class="form" placeholder="Enter your email">
</div>
<div>
<button type="button" class="form full">Subscribe</button>
</div>
</div>
<form>

Should <br /> and <hr /> be avoided at all costs in web design?

I continuously find places where I need to use the <br /> tag because CSS can't do what I need. Isn't the <br /> considered part of the "design" and not part of document structure? What is the acceptable usage for it? Should the same rules also apply to the <hr />?
Here is an example of where I feel forced to use the <br /> tag:
I want to display this:
<address>1234 south east Main St. Somewhere, Id 54555</address>
like this:
1234 south east main st.
Somewhere, Id 54555
There is nothing wrong with using <br /> or <hr />. Neither of them are deprecated tags, even in the new HTML 5 draft spec (relevant spec info). In fact, it's hard to state correct usage of the <br /> tag better than the W3C itself:
The following example is correct usage of the br element:
<p>P. Sherman<br>
42 Wallaby Way<br>
Sydney</p>
br elements must not be used for separating thematic groups in a paragraph.
The following examples are non-conforming, as they abuse the br element:
<p><a ...>34 comments.</a><br>
<a ...>Add a comment.<a></p>
<p>Name: <input name="name"><br>
Address: <input name="address"></p>
Here are alternatives to the above, which are correct:
<p><a ...>34 comments.</a></p>
<p><a ...>Add a comment.<a></p>
<p>Name: <input name="name"></p>
<p>Address: <input name="address"></p>
<hr /> can very well be part of the content as well, and not just a display element. Use good judgement when it comes to what is content and what is not, and you'll know when to use these elements. They're both valid, useful elements in the current W3C specs. But with great power comes great responsibility, so use them correctly.
Edit 1:
Another thought I had after I first hit "post" - there's been a lot of anti-<table> sentiment among web developers in recent years, and with good reason. People were abusing the <table> tag, using it for site layout and formatting. That's not what it's for, so you shouldn't use it that way. But does that mean you should never use the <table> tag? What if you actually have an honest-to-goodness table in your code, for example, if you were writing a science article and you wanted to include the periodic table of the elements? In that case, the use of <table> is totally justified, it becomes semantic markup instead of formatting. It's the same situation with <br />. When it's part of your content (ie, text that should break at those points in order to be correct English), use it! When you're just doing it for formatting reasons, it's best to try another way.
Just so long as you don't use <br/> to form paragraphs, you're probably alright in my book ;) I hate seeing:
<p>
...lengthy first paragraph...
<br/>
<br/>
...lengthy second paragraph...
<br/>
<br/>
...lengthy third paragraph...
</p>
As for an address, I would do it like this:
<address class="address">
<span class="street">1100 N. Wullabee Lane</span><br/>
<span class="city">Pensacola</span>, <span class="state">Florida</span>
<span class="zip">32503</span>
</address>
But that's likely because I love jQuery and would like access to any of those parts at any given moment :)
<hr /> and <br />, much like everything else, can be abused to do design when they shouldn't be. <hr /> is meant to be used to visually divide sections of text, but in a localized sense. <br /> is meant to do the same thing, but without the horizontal line.
It would be a design flaw to use <hr /> across a site as a design, but in this post, for instance, it would be correct to use both <br /> and <hr />, since this section of text would still have to be a section of text, even if the site layout changed.
<hr/> and <br/> are presentational elements that have no semantic value to the document, so from a purist perspective yes, they ought to be avoided.
Think about HTML not as a presentational tool but rather as a document that needs to be self-describing. <hr/> and <br/> add no semantic value - rather they represent a very specific presentation in the browser.
That all being said, be pragmatic in your approach. Try to avoid them at all cost but if you find yourself coding up the walls and across the ceiling to avoid them then its better to just go ahead and use them. Semantics are important but fringe cases like this are not where they matter the most.
I believe absolutely avoiding usage of a commonly accepted solution (even it is outdated) is the same thing as designing a table with <div> tags instead of <table> tags, just so you can use <div>.
When designing your website, you probably won't require the use of <br /> tags, but I can still imagine them being useful where user input is needed, for example.
I don't see anything wrong with using <br /> but have not come across many situation where I required using them. In most cases, there probably are more elegant (and prettier) solutions than using <br /> tags if this is what you need for vertically seperating content.
I put in a <hr style="display:none"> between sections. For example, between columns in a multi-column layout. In browsers with no support for CSS the separation will still be clear.
No. Why? They're useful constructs.
Adding this addendum (with accompanying HR), in case my brief answer is construed as lacking appropriate consideration. ;)
It can be, and often is, an incredible waste of time -- time someone else is usually paying for -- trying to come up with cross-browser CSS-limited solutions to UI problems that BR and HR tags, and their likes, can solve in two seconds flat. Why some UI folks waste so much time trying to come up with "pure" ways of getting around using tried-and-true HTML constructs like line breaks and horizontal rules is a complete mystery to me; both tags, among many others, are totally legitimate and are indeed there for you to use. "Pure," in that sense, is nonsense.
One designer I worked with simply could not bring himself to do it; he'd waste hours, sometimes days, trying to "code" around it, and still come up with something that didn't work in Opera. I found that totally baffling. Dude, add BR, done. Totally legal, works like a charm, and everyone's happy.
I'm all for abstracting presentation, don't get me wrong; we're all out do to the best work we can. But be sensible. If you've spent five hours trying to figure out some way to achieve, in script, something that BR gives you right now, and the gods won't rain fire down on you for doing it, then do it, and move on. Chances are if it's that problematic, there might be something wrong with your solution, anyway.
Interesting question. I have always used <br/> as a carriage return (and hence as part of content, really). Not sure if that is the right way of going about it, but its served me well.
<hr/> on the other hand...
I'd not say at all costs but if you want to be purist, these tags have nothing to do with structure and everything to layout but HTML is supposed to separate content from presentation. <hr /> can be done through CSS and <br/> through proper use of otehr tags like <p>.
If you do not want to be a purist, use them :)
I think you should seldom need the BR tag in your templates. But at times it can be called for in the content, user generated and system generated. Like if you want to keep a piece of text in the paragraph but need a newline before it.
What are the occasions where you feel you are forced to use BR tags?
<br> is the HTML way of expressing a line break, as there is no other way of doing it.
Physical line breaks in the source code are rightfully ignored (more correctly: treated as a single white space), so you need a markup way to express them.
Not every line break is the beginning of a new paragraph, and packing text into <div>s (for example) just to avoid <br>s seems overly paranoid to me. Why do they bother you?
BR is fine, since a hard line-break could be part of the content, for example in code blocks (even though you'd probably use the PRE-element for that) or lyrics.
HR on the other hand is purely presentational: a horizontal rule, a horizontal line. Use border-top/bottom for neighbouring elements instead.
I personally feel that, in the interest of true separation of content and style, both <br /> and <hr /> should be avoided.
As far as doing away with <br /> tags in my own markup, I use <div> in conjunction with the css margin property to handle anything that needs a line break, and a <span> for anything that would be inline, but of a different "content class" (obviously distinguishing them with the class attribute).
To replace an <hr /> tag with css, I simply create a <div> with the border-top-style css property set to solid and the other three sides set to none. The margin and the padding properties of said <div> then handle the actual placement/positioning of the horizontal line.
Like I said, I'm no expert, my web design experience is mostly a side effect of my work with JSP pages (I am a Java programmer), but I came upon this question during some research and wanted to put my two cents in...
You can use <br> but don't use <hr>.
<BR> — LINE BREAK— This is display information. Still in
common use, but use with restraint.
<HR> — HORIZONTAL RULE— Display info with no semantic value –
never use it. “Horizontal”, by definition, is a visual attribute.
Source: Proper Use Guide for HTML Tags
That's bad usage if you're going Strict.
<br/> and <hr/> are not part of the content. For instance the <hr/> is commonly used to separate blocks of text. But isn't possible to that with border-bottom? And <br/> is seen in many cases as a way to limit text to a certain form, which couldn't be accomplished with css?
Of course you aren't going Strict don't worry to much.
HR has some hacky uses right now in preventing mobile browsers' font inflation algorithms from kicking in.
Also if you have lots of small content separated by HRs, the Googlebot will currently see it as 'N separate entries', which might be useful to you.
BRs should really only be used as a line break within a paragraph, which is a pretty rare typographical usage (except perhaps within a table cell), and I'm not aware of any hacky reason to use them.
Here is an excerpt from a course that helps you learn html.
<form>
<p>Choose your pizza toppings:</p>
<label for="cheese">Extra cheese</label>
<input id="cheese" name="topping" type="checkbox" value="cheese">
<br>
<label for="pepperoni">Pepperoni</label>
<input id="pepperoni" name="topping" type="checkbox" value="pepperoni">
<br>
<label for="anchovy">Anchovy</label>
<input id="anchovy" name="topping" type="checkbox" value="anchovy">