Explaining why styling should not be done directly in HTML

Question

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.

Answer 1

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.

Answer 2

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).

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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 {
  padding:0;
  margin:0;
}
article {
  margin:0.8em;
  background-color:rgba(255,50,60,0.7);
}
article span {
  font-family:sans-serif;
  color:grey;
  padding:0.5em;
  text-indent:5em;
}

header {
  font-size:2em;
  text-decoration: underline;
  background-color:rgba(20,255,20,0.4);
  padding:0.3em;
}
</style>
<body>
  <article>
    <header>The Title</header>
    <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;">
    <header style="font-size:2em; text-decoration: underline; background-color:rgba(20,255,20,0.4); padding:0.3em;">The Title</header>
    <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.

Answer 12

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.

Answer 13

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.