# Explaining why styling should not be done directly in HTML

I recently noticed that <marquee> has been deprecated from html according to this site. From this answer on Stack Overflow, the marquee replacement is made from CSS. The explanation given to the change is that html is about document structure, and that layout and animation and styling etc. should be done from CSS.

This got me thinking:

Would explicitly teaching the difference between setting the style attribute of an html tag, and doing it through CSS useful for increasing the students' understanding of the joining of CSS and HTML?

To narrow it down, I'm looking for examples or explanations of how teaching it explicitly might make it easier for the students to style their webpages. Preferably an explanation.

By "explicitly teaching" what I mean is actually devoting a lesson with the title of "Styling through .CSS", or something similar.

Some context, if it is needed:

The students learn basic web designing: HTML, JavaScript (very basic), JSP and SQL. They learn these for 1 year and at the end of the year they should have a website (for which they receive grades). I am wondering if a lesson entirely about CSS might eventually lead to better looking websites.

• The core problem here is that you're assuming that styling should not be done directly in HTML, and that using CSS is better. Neither of those things is true. – Puppy Jul 30 '17 at 21:48
• @Puppy well, part of the question is whether I should teach it separatly. If I don't, then they won't use stylesheets. But do you think any website anywhere actually hardcodes all it's css in html? Every div has a mountain of code in its style attribute? – ItamarG3 Jul 31 '17 at 8:17
• This site shows the power of keeping css separate. csszengarden.com - Same structure, different css stylesheet. – David Spence Jul 31 '17 at 14:09
• @DavidSpence nice. I'll definitely use that – ItamarG3 Jul 31 '17 at 14:10
• If you are teaching them about specificity as it applies to styling html, this is a good place to mention why you may or may not want to use inline styles. And no, I am not making this an answer, someone else may integrate this into theirs if they want. – Kik Jul 31 '17 at 16:14

Would explicitly teaching the difference between setting the style attribute of an html tag, and doing it through CSS useful for increasing the students' understanding of the joining of CSS and HTML?

To narrow it down, I'm looking for examples or explanations of how teaching it explicitly might make it easier for the students to style their webpages. Preferably an explanation.

Show them why having separate CSS files makes their lives easier.

Step 1: Give students an assignment where they create an HTML page with a bunch of elements that use the style attribute for inline styling. Have something like 10 buttons with the same background color, 10 paragraphs with the same alignment, etc.

Step 2: Now have them change those styles. Have them change the background color on the buttons and the alignment on the paragraphs. The point is to show them how painful this manual process is.

Step 3: Now introduce the concept of css classes and separating CSS into its own section or its own file. Have them modify their HTML to use this approach instead of inline styles.

Step 4: Now have them change the styles again. This is a 2-line change instead of a 20-line change. This assignment will be much less tedious than the previous one.

This approach will motivate students where they live and show them the real-life benefits of separating your CSS styles from your HTML content. Then you can introduce some of the other benefits that the other answers discuss.

• Instead of site wide display changes that affect all clients (which you can do with careful search/replace) I'd instead focus on providing different views for different clients dynamically - print view, high contrast (for vision disability), screen reader compatible, etc. – ivanivan Feb 20 '18 at 2:03

I like the idea of producing a few style sheets, and having the pupils apply them to their HTML. They can then see the power of having separate style sheets.

Start with a style sheet that you made. Use the new grid layout, have some college styling. But at first get them only creating the html.

They can then start editing the style sheets. They will see that the power of one small change can change every heading, or every paragraph.

I have also in the past, written a HTML file that had a set of buttons at the bottom. These buttons would trigger a different CSS file to be loaded. It was some very simple JavaScript.

## To answer should they be kept separate

Keeping style and content separate, is recommended by W3 and many others. It implements separation of concerns and single responsibility. Both very important patterns in software design.

Even better: keep layout, style, structure, and content separate.

One css for layout, another for style, then a template for structure (I use moustache), pull the content from a database, to create json, and programmatically combine it with the template (use a template library). [this section is now about my teaching, but what I do for my websites.]

## To answer should you devote a lesson to separate CSS files.

Yes. If it is important to keep these separate, which it is, then you should teach pupils to keep them separate. Save time by not teaching them to mix it in with the HTML (This will save time twice, as you won't have to un-teach it).

I have only done this with one or two people (not a class).

• That second paragraph sounds especially useful. But that doesn't answer whether I should really devote a lesson for teaching how and why one should write a css stylesheet, instead of inline html style attributes. – ItamarG3 Jul 30 '17 at 10:04
• Added a partial answer to If and why to devote a lesson to it. – ctrl-alt-delor Jul 30 '17 at 11:01
• I agree that un-teaching is an especially wasteful use of everyone's time. It is best to catch misconceptions before bad habits are built and reinforced. – Buffy Jul 30 '17 at 13:03
• @tim, this is just a load optimisation. Conceptuality it should still remain separate. However Google is saying put it in the same file. They are not saying that you should style each bit separately. They are saying take what could be in a css file and add it to the <style> section of the html. – ctrl-alt-delor Jul 30 '17 at 21:38
• Instead of giving the students a variety of style sheets that affect their code, I would try the opposite approach. After teaching them inline styles in HTML, give them a page that relies on a CSS document for its style and ask them to make their own stylesheet for it (using the same techniques they learned from using inline HTML - just a matter of labeling the styles and putting them together in one place). Then everyone in class can compare their style sheets on a common test subject (the one you provided) and see the possibilities. – Darren Jul 31 '17 at 13:31

If you only want to build a page that is simple and ad-hoc and will never change in the future and will only ever be seen on one kind of device, then, sure, build the styling directly into html. It is the same when you write a program that will only be run once on one device to get an answer, after which the program becomes obsolete. There is, then, no reason to code carefully. "Quick and dirty" works for such things.

However things do change, and web pages are viewed on devices with varying screen sizes, even color models. And they may be viewed in future on devices that don't yet exist.

So, if you want to build sites that are important and lasting and that must be maintained in the future, use CSS. You probably wouldn't write an important C program all in main, but would at least, factor out the things that must be the same but are reused. In simple C programming we factor out functions for this. In html we factor out styling. At a deeper level, the server side also factors out much of the data, etc. This lets things that are supposed to be the same, stay the same, and lets us modify one level of design independently from other levels.

This isn't exactly the same thing, but look at the underlying code of Google's front page. I don't know what they use to put that together and maintain it, but I doubt that it is just a text editor. Note that their front page, though incredibly simple in layout, changes frequently.

Note to the Instructor When you get ready to grade the student's work, view it on various devices, with different screen resolutions. I don't, however, suggest that you also make them provide per-device css.

For that matter, view some of the StackExchange pages on a desktop vs a phone. And for a shocker, look at both the source and stylesheets of some of the pages.

• The comparison with functions is good. I presume the sin in question is directly supplying style attributes in source HTML. If so, it could be compared to taking the body of a method and just sticking that where you were going to call the method. Counterproductive in the extreme. – Luke Sawczak Jul 31 '17 at 2:02

To make them really understand what you can do with CSS alone - with only substituting another CSS file - take them to the CSS Zen Garden. With exactly the same HTML for each page, and only the .css file replaced, you get absurdly wild pages. From serene small nothingness to 3D-scrolling cubes...

Then explain to them that the skillset needed to make the HTML, vs. the skillset for (especially extreme like those) CSS is vastly different, and that the HTML functions as the information carrier only.

A further goodie would be to install a screen reader (for the blind) - there are ones with limited free use - to show them how the same HTML "looks" when spoken aloud.

Also point out that those tools for the visually impaired are able to for example extract link texts and so on from the HTML if it is well structured, and this also makes it possible to navigate a page with keyboard only - which can be useful if one is so inclined, even if the eyesight is fine.

Finally, point out that a page with good separation of content and styling has a higher chance to work on portable devices - the key word being responsive design, where the content can freely flow into any resolution as needed.

To narrow it down, I'm looking for examples or explanations of how teaching it explicitly might make it easier for the students to style their webpages. Preferably an explanation.

As richard says, the pupils can see how one simple edit of the style can change every element.

As an example, you could let your pupils 'feel' the benefit of separation of the style from the html. Which means, give them an exercise, where they need to style some elements (e.g. color the element background) the in their html. Then let them change each element to another color. The lesson would be to let them understand that this task can be much less time-consuming if you separate the style from the html. You could then demonstrate how to change one line in the css, which changes all the elements background color.

• HI thehayro! Welcome to Computer Science Educators! – thesecretmaster Jul 30 '17 at 17:33
• Sure. That is up to the requirements where the webpage should be displayed (mobile/desktop). But the question as far as I understood it, was how to explain why and how there is a need for a separation of HTML and CSS. – thehayro Jul 30 '17 at 21:55

Well ask yourself: Why do we separate anything in any form of code?

In almost every single programming/scripting language there is separation and delegation. We do this to make sure that we are more easily able to keep track of all the code and are able to more easily identify issues (that will inevitably sprout because no programmer is infallible)

So I think that a dedicated lesson on CSS is a good idea, because it helps them understand what is responsible for which. It helps them understand that if all the HTML is correct when looking at the source, but all the makeup is still jumbled, that they need to look to the CSS.

On top of that, CSS is large, flexible and can do a lot more than just putting a nice border around things. To show the class what it can do, and how complex it can get, will drive the point further home how it's unwise to blend the HTML and CSS too deeply.

In the end, separation of CSS from HTML (or any code for that matter) is a development atticate; its not about the creation functioning (better) its about the developer having more and easier control over their creation.

Maybe on that note you want to try and make the class check each others work, it'll help them see how it's important to have clean delegated code when you work in a team.

A slightly different way of looking at it might be to introduce DRY code (Don't Repeat Yourself).

By using CSS to do the styling, you know that by simply adding a class to a HTML element, the styling should take hold. If you had to manually add it all, then when you need to change one part, you need to change many, many more.

To steal an idea of illustration from W3 Schools, if you wanted, say, paragraphs to have different background colours, you could do it this way:

<p style='background-colour:red'>Paragraph 1</p>
<p style='background-colour:blue'>Paragraph 2</p>
<p style='background-colour:red'>Paragraph 3</p>
<p style='background-colour:blue'>Paragraph 4</p>


But, if I want to change the order so it's 2,4,3,1 but keep the colouring, I then have to change all of the styles built in to each tag. If that's across multiple pages, then the work load can be come huge.

If I did it in CSS, I can do the following:

p:nth-child(odd) {
background: red;
}

p:nth-child(even) {
background: blue;
}


Now it no longer cares what the content is, I can order them how I like and the styling still works. Lots of effort changed. Ignoring the ordering, if I wanted to change them to more sensible colours so they are easily readable, I change the value in CSS once, and it's applied to each matching DOM item.

Beyond that (as CSS can be embedded in HTML in the head tag), splitting it out into a file and including that means I don't have to repeat my (now more sensible) CSS into various files, down into folder structures for each page I have. I include the CSS file in the header and the styles take effect. Now if I need to make changes to the colours or add additional styles, I get the same benefits of not needing to duplicate which I had from not using inline styles.

Another benefit from having a separate file, away from the split responsibilities, is performance. Browsers are pretty good at caching files, so if it has to download a single (ideally minified) CSS file for the site once which it can then reapply, it's one less thing for it to download for other pages. Performance should always be a consideration for people, especially with the increase in mobile browsing. If a web page has a lot of CSS in it then the source is, naturally, large. This takes longer to download and/or become usable, which may put people off it the wait becomes unacceptable to them.

We teach that there are three layers to a web page: structure, appearance, and behavior. Structure is determined by the DOM, which is created with well-formed HTML5 markup. When we learn about HTML, we immediately begin drawing the document tree, so we can understand how elements on a page relate to each other.

Appearance is determined by CSS, which accesses the DOM to format and style the page. This is kept in a separate file so that it can be shared by a related group of pages. HTML handles ad hoc situations using id or class. Using these makes maintaining pages easier, since the style for items bearing these attributes is made in one place in a CSS file.

The third layer is behavior, which should appear in a JavaScript file. JavaScript never needs to appear on a page, save for calling functions from event-handling code. Even this can be attached in a JS file. Make sure your students know about load events and onload early, so they can delay the calling of code until page elements exist.

If you install Node, you can run tests of JS code at the command line, and develop test suites for the functions you have created.

Separating the three layers keeps things neat and maximizes re-use of code.

Make a project in which the result is TWO completely different views of the same document, eg a version that looks great on a big monitor and another that looks great on an iPhone.

Using not a static webpage but computer-generated, updateable documents will drive the point home even more, since embedding style information in the document generator will make it visibly more complex - the only options to mess with style will be either changing the document generator with all the hassle involved or the stylesheet which is exactly what you intended. Even better: Assign two groups in separate corners of the room to do the document generating and the stylesheet parts - and regulate how specifications are communicated between the two.

• This is incredible. Wow. – ItamarG3 Aug 3 '17 at 11:19
• Well, make it credible then. – rackandboneman Aug 3 '17 at 12:05
• It's incredible becase it solves a problem with circumstances that I can't disclose (school stuff), but it doesn't exactly address the question... – ItamarG3 Aug 3 '17 at 12:10
• Oh, and I'm meddling in the discussion as not a teacher but an IT professional - what I described is why things are done in practice just like the theory you want to teach says :) – rackandboneman Aug 3 '17 at 13:35

It seems that many answers here are not addressing the point of inheritance on styling, as this should also be taught. The basic rule is what's read last will be applied.

the first to load is usually the external sheet in the head of the document. A style sheet linked in the head of the document will be over ridden by styles placed inline in the html body, and those in turn will also be overridden by styles placed directly on the DOM element. The !important tag can be used to alter this behaviour also.

Most will put all their css into its own file because it's easier to maintain and won't require as much work when updated/changed.

EDIT: Just to clarify a bit further, it is only the specific styles that match in the classes that will clash/override each other, if the one inline adds a style to underline text, that is not in the class in the external sheet for example it will just add that extra styling. The classes do not directly replace each other but merge into each other.

• Wow. Welcome to Computer Science Educators. This is really something I had not considered. I'd love it if you could add some examples or description that show that. (I can write them myself, but I'm more interested in seeing what you can think of). This really is an interesting answer :) – ItamarG3 Jul 31 '17 at 8:11
• Unrelated: why don't you take our tour? I'm sure you'd find it interesting. – ItamarG3 Jul 31 '17 at 8:12
• I got it slightly wrong, its external style sheet first, then document styles and then on the element, my brain is never 100% on a monday morning. :) – user1639154 Jul 31 '17 at 8:29
• forgive and forget ;). You can edit your answer. There's an edit button\link directly under your answer. While you're at it, would you like to add some example to demonstrate what your answer is addressing? It'd really make it into a much better answer :D – ItamarG3 Jul 31 '17 at 8:30
• Unfortunately i do not have time right now. I just wanted to mention inheritance of css, as it is important aspect of css. – user1639154 Jul 31 '17 at 8:49

An important reason why inline styles are bad is code readability, plain and simple. In this case, an example should be enough to prove your point:

<style>
body {
margin:0;
}
article {
margin:0.8em;
background-color:rgba(255,50,60,0.7);
}
article span {
font-family:sans-serif;
color:grey;
text-indent:5em;
}

font-size:2em;
text-decoration: underline;
background-color:rgba(20,255,20,0.4);
}
</style>
<body>
<article>
<span>This is a super great article</span>
</article>
</body>


Compared to:

<body style="padding:0; margin:0;">
<article style="margin:0.8em; background-color:rgba(255,50,60,0.7); font-family:sans-serif;">
<span style="font-family:sans-serif; color:grey; padding:0.5em; text-indent:5em;">This is a super great article</span>
</article>
</body>


In addition to this example, without using classes and ids you make the DOM much harder to manipulate using javascript and you make it impossible to use pseudo-elements and some of the really nice CSS selectors such as :nth-child() and :first-child, to name a few.

There are lots of good answers here. One point I haven't seen made yet is that content and design are often created by separate people or teams, and so having each defined with its own tools and language allows for the necessary separate workflows.

I would use an analogy. Automotive engineers don't choose car colors. Screenwriters don't generally do costume design.

• Wow. I hadn't thought of that. Would you mind expanding a bit on how I can explain this in a separate lesson about using CSS stylesheets? – ItamarG3 Aug 2 '17 at 12:39
• I would use an analogy. Automotive engineers don't choose car colors. Screenwriters don't generally do costume design. – Chris M. Aug 2 '17 at 13:14
• I see. Maybe you should include such analogies in your answer by editing the answer. – ItamarG3 Aug 2 '17 at 13:34
• Actually it is worse than that. At some large companies with an important web presence, there is a standards team sitting above both the content and layout teams. If the layout is one pixel off of the standard, you do it over. One pixel. – Buffy Aug 3 '17 at 11:28

I would completely disagree - styling should be done directly in HTML.

The primary problem is that styling is not even remotely independent of the HTML structure. Simply writing the styles in a physically separate file does not change this. A good example is mobile device support. In theory, you could make a mobile CSS file. But in reality, you probably need a completely separate UI design to produce a good experience on a mobile device, and then a separate HTML structure to support this, and then a separate set of styles. "Make the button the same but a bit smaller" only works for the smallest pieces.

Producing the correct UI involves producing the HTML structure that supports the styles you need. Since the two are in fact intimately coupled, having them be colocated just makes things easy to understand and all in one place.

Moreover, since you are presumably generating your HTML through code, there is no problem with generating HTML with duplicated styles, since your code generator can spit out styles all day long.

Having raw CSS is tremendously problematic as the styles are completely random and at global scope, and difficult to re-use. You make a class name under the hope that nobody else used it. You nest your own classes inside that element to try to solve this problem a bit but now you can't re-use these classes in other places as they're not in the right DOM structure. Then you find out that some random dude in some completely separate part of your page used your class without notifying you and now you've broken it by changing your styles. And good luck getting type checking, IDE support, etc. It's also difficult to create e.g. parameterised classes, or globally apply replacements, e.g. display: flex with display: flex and display: -webkit-flex for iOS.

The correct way to deal with styles is to deal with them as with any other code- encapsulate them in some functions.

• Hi Puppy, welcome to Computer Science Educators! If you'd like to meet another puppy, you can say hi to Buffy, who's a bulldog, in chat. This is an interesting answer, thanks for sharing your perspective here! – thesecretmaster Jul 31 '17 at 0:29
• While I do not agree with everything you say. I do see your point. Especially the last line (I think you should expand on this). Show us how you think it should be done. Even if we don't 100% agree, we could learn something. – ctrl-alt-delor Jul 31 '17 at 23:11
• @Puppy Is that so? – ItamarG3 Aug 2 '17 at 12:40
• It's definitely so – Puppy Aug 6 '17 at 23:01
• It seems like your problems are with your teams: Too many people on the project, and not enough communication. I agree that you should generate it. CSS does style and layout, keep them seperate; HTML does content and structure. The structure should be done with templates, and the content should me pulled form the database. The two combined with a program. – ctrl-alt-delor Feb 8 '18 at 0:15