Related
I've been tasked with explaining to a few colleagues why you shouldn't always use <table> elements for positioning things in HTML. There are a lot of places on the internet where it says you shouldn't use <table> elements for layout but none actually provide a definition for what "layout" is. So, it's easy to tell someone "don't use tables for layout" but if we don't actually provide a working definition of "layout" that cannot functionally include <table> elements, then what's stopping that person from coming up with their own definition?
Here's one definition of "layout" from geeksforgeeks.org (https://www.geeksforgeeks.org/html-layout/):
Page layout is the part of graphic design that deals with the
arrangement of visual elements on a page.
The problem with this definition is that <table> elements can indeed be used to arrange visual elements on a page, so it is confusing to beginners when they're told they shouldn't use <table> elements--the definition itself doesn't seem to exclude them, so why not?
Here's another assertion from w3schools.com that you shouldn't use <table> elements for layout, but it fails to define "layout" (https://www.w3schools.com/html/html_layout.asp):
The <table> element was not designed to be a layout tool! The
purpose of the <table> element is to display tabular data. So, do not
use tables for your page layout!
Once again, what is "layout" to a beginner? Technically, everything on the page could be considered layout, even the tabular data parts, since tabular data can also be presented using <div> elements. Therefore, saying "don't use tables for layout" means nothing and isn't helpful, because layout is everything on the page (even tabular data is layout; it's data displayed in a tabular layout).
In closing, I'm curious if there is a definition of "layout" that cannot be interpreted as being anything on a web page. If there is no definition, perhaps we can formulate one here.
There is no reason to define layout to exclude tables so that tables aren't used for layout. Those aren't the same thing.
Like it or not, layout is the placing of elements on a page or screen. The term comes from when pieces of type, photos, rules (lines), and other elements were pasted into position on a layout sheet that was printed with grid lines. You literally laid out the page.
The reason to avoid tables is because there are better ways in HTML to arrange elements, namely, cascading style sheets, which include grid and flexbox.
Long ago, wax replaced rubber cement for laying out newspaper and magazine pages. Wax was was a lot less messy, easier to apply, and didn't require thinner that made people high and gave them headaches. Using CSS is exactly the same. Tables are messy and give you headaches. They lock the content into a rigid layout that can't adapt to changing screen sizes.
One of the primary rules of web design is don't hard-code the styling into the HTML content -- CSS separates style from content, and that's why it's the right thing to use.
I propose a definition of "layout" that cannot functionally include <table> elements:
"Layout" as it pertains to a web page is any visual element whose horizontal children can become vertical upon screen resizing, and vice versa (think responsive elements, i.e. Bootstrap).
<table> elements will never fit this definition, because table rows can never become horizontal, and table cells (of a given row) can never become vertical.
I found a list of ALL bootstrap classes courtesy of a post here. Hooray. Except it is not complete. In the last 2 hours, in Stackoverflow, I have found examples of class="span4; clear:both; content-heading; paragraphs; " (these were not in a list)
What's div class="paragraphs" ? Is content-heading similar to .lead (which I think is a style).
Is there any listing of all the STYLES?
I love w3schools - I live 20 miles W of MIT, and MIT was one the schools that accepted me 50 years ago. I love the mission and execution of w3. But I have poured through their tutorials and references and I cannot find simple rules like:
class elements can be strung together, semi-colons in-between. They
end in a quote mark, but the last entry can be followed by a
semi-colon with or w/o a space. Numbers, like height, can have
leading spaces.
Is there some place that lays out this stuff? I've looked at many other bootstrap sites, but w3 seems the best. I still don't quite grasp Github, but they have lots of info.
I would recommend you to have a look at the official bootstrap documentation
http://getbootstrap.com/ for the latest version
http://getbootstrap.com/2.3.2/ for the older version
In the example you are looking, paragraphs and content-heading classes might be a user defined.
It is also worth noting that bootstrap evolved over time. Bootstrap 2x to 3x was a major change. So note that the examples you are looking at might correspond to an older version of bootstrap.
The release history can be found here on github
https://github.com/twbs/bootstrap/releases
and Bootstrap 2x to 3x migration guide can be found here
http://getbootstrap.com/migration/
Hope it helps
There is no such thing as a "class element". You can attach class names to HTML element nodes by listing them in the node's class attribute.
Multiple class names are separated by white space, the whole list of class names enclosed in quotes, single or double makes no difference. Example: <div class="first-class second-class"/>. A single class name does not require surrounding quotes, however it's advisable to always enclose attribute values in quotes, to avoid mistakingly omitting them when they are required. The order of class names in the attribute value is irrelevant.
A valid class name can consist of upper and lowercase letters, numbers, hyphens (-) and underbars (_). However the name must start with a letter, hyphen or underbar. See this more complete answer for more on this subject.
Styles for class names are defined in style sheets, for the web its CSS (Cascading Style Sheets). The cascade is defined by the order styles are introduced in the style sheet; succinctly and simplified: later values trump earlier values, when the selectors are of equal importance.
In CSS, properties and their value is separated by a colon. The value is followed by a semi-colon. A block of styles is surrounded in curly braces, and are preceded by a selector. The selector can be a tag name, id, class name as well as a combination of the three, combinators and pseudo-elements.
An example:
/* Styles applied to the body tag and all its child nodes */
body {
background-color: white;
color: black;
}
/* This block defines that when the class name "error"
* applies, the text should be red */
.error {
color: red;
}
For a friendly tutorial in HTML and CSS, see e.g. CodeAcademy. For reasons why one should not hold W3Schools in very high regard see W3Fools.com.
I'm taking some classes on Web Programming and no one in the class including the instructor can say what the difference is between the frame values box and border when it comes to html tables. Here is an example of what I am talking about.
<table frame="border">
<!-- some basic table data -->
</table>
<table frame="box">
<!-- some basic table data -->
</table>
These two tables as far as I can tell will render the same way as one another. Are there any underlying differences that may not be apparent at first or is there a right or wrong way to use them?
There is no difference; they're aliases of each other. From the HTML 4.01 spec:
This attribute specifies which sides of the frame surrounding a table will be visible. Possible values:
...
box: All four sides.
border: All four sides.
Today, pretty much the only right way to use them is to not use them. Table border styles should be defined using CSS instead of presentational attributes, of which frame is an example, albeit a rather obscure one. Browser support for this attribute seems quite patchy anyway, again owing to its obscurity.
box The outside borders are shown on all four sides
border The outside borders are shown on all four sides
i.e. they are the same
http://www.w3schools.com/tags/att_table_frame.asp
As has already been stated they do the same thing, and you shouldn't be using the frame attribute anyway.
To understand why there were two different values for the same thing, it's necessary to read RFC 1942 HTML Tables which says:
The value "Border" is included for backwards compatibility with
deployed browsers. If a document includes <TABLE BORDER> the user
agent will see FRAME=BORDER and BORDER=implied. If the document
includes <TABLE BORDER=_n_> then the user agent should treat this as
FRAME=BORDER except if n=0 for which FRAME=VOID is appropriate.
Note: it would have been preferable to choose values for FRAME
consistent with the RULES attribute and the values used for alignment.
For instance: none, top, bottom, topbot, left, right, leftright, all.
Unfortunately, SGML requires enumerated attribute values to be unique
for each element, independent of the attribute name. This causes
immediate problems for "none", "left", "right" and "all". The values
for FRAME have been chosen to avoid clashes with the RULES, ALIGN and
VALIGN attributes. This provides a measure of future proofing, as it
is anticipated that that the FRAME and RULES attributes will be added
to other table elements in future revisions to this specification. An
alternative would be to make FRAME a CDATA attribute. The consensus of
the HTML-WG was that the benefits of being able to use SGML validation
tools to check attributes based on enumerated values outweighs the
need for consistent names.
So "border" was already in use by browsers before the spec was written but wasn't compatible with a subtlety of SGML, so "box" was added to provide an SGML compatible way of doing the same thing.
Because browsers don't actually follow SGML rules, it's not easy to see an effect of the above, but the pre-HTML5 validators did, and it is possible to see a small effect. Consider this markup:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<title>Test</title>
<table border border=5>
<tr><td>Test</td></tr>
</table>
Normally having two attributes with the same name will cause an error to be reported by the validator, but try this at the W3C HTML validator and you will see that it passes validation. That because the validator sees the first border attribute as a short form of frame="border" and so there's no name collision.
Browsers, on the other hand, do see a name collision and will ignore the border=5 attribute.
They are the nearly same, but since they are different in name context they are depended on different browser supports.
frame means that there should be all four borders, while box is the same but it can be used with rules. like this: rules="none"
When naming classes and IDs for CSS what is the best method to use. In this case I need there to be some kind of naming convention so that other people can pick up rules and understand how to name their own ids and classes using the same pattern. Any suggestions? Some of the sites we create can get pretty complex but use an overall structure header, content and footer. The naming must be efficient too.
I am not new to CSS. I am aware of giving them names that represent their structure etc., but just want to know people opinions really and ways of doing this.
The best advice is to use class with semantics in mind
Good names don't change
Think about why you want something to
look a certain way, and not really
about how it should look. Looks can
always change but the reasons for
giving something a look stay the same.
Good names
warning, important, downloadableImage and submenu are all
good names. They describe what a
certain element represents, and they
are not likely to change. A warning
will always remain a warning, no
matter how much the look of the page
changes.
Bad names
border4px, lighttext and prettybackground are all examples of bad
names. You might fatten that border to
a whopping 5 pixels, or the background
may look pretty old after a while, and
not pretty at all. An advantage of
using CSS is that you won't have to
change much in order to change the
looks of your website. If you have to
change all light text into dark text,
and thus change all classes lighttext
to darktext in all your HTML pages,
you're likely to miss a few.
from this article
IDs can only be used once per page, so they are useful for major structural elements like "header" and "footer" (until HTML5 comes in and replaces those with native elements).
Classes can be used multiple times, and you can use multiple classes per element. They should be kept fairly generic - so instead of, say, warningMessage you could create one style message with the basic layout style, and then warning, info, and error styles with different colours. Then use <div class="message warning">etc</div>
You should also use HTML elements where applicable. Instead of <span class="title">, use a heading tag like <h2>.
As others have said, you can use underscores or hyphens or camel case - i.e. my_style or my-style or myStyle. Just choose a convention and stick to it (personally I use my-style). Jitendra suggested in a comment that lowercase is better when you're using gzip compression, which is true all round - for font names, hex colours, and it's worth naming files (e.g. background images) in lowercase anyway.
Sometimes coming up with good names can be hard. Think about other places you might use the same formatting. For example, if you want to put the author and date of an article below the title in smaller grey text, you might use .authorAndDate, but a better way would be .byline. This is still quite descriptive, and can be used in other places too, say, image captions.
header
footer
container
.post
.title
Those are the ones which come up in most of my projects but obviously it depends what you're doing. Just try to keep it logical.
be descriptive and name your ids and classes in a semantic way, give them meaning
There is no real naming convention. Just agree on one with your team and keep it consistent. For instance don't mix camel case and snake case.
Try to be as description as possible when naming a class. Example:
.menu: bad
.head_menu: better
.wrapper: very bad
.main_content_wrapper: better
edit; Worse naming convention I saw is using the actual content of the styling. For instance:
.redButton
... because when I got to the code (legacy code), but "red button" was not red but blue (or something like that).
Try to use something that will not likely change, like the purpose of the class.
The rules for naming an id or class attribute are simple. Keep it short, keep it consistent (i.e. if you use hyphens, underscores, or CamelCase for one, use the same format for the others), and make sure the name is based on the function or meaning of the element, NOT the style to be applied.
e.g.
<span class="warningMessage">, <span class="warning-message">, <span class="warning-message"> are all perfectly acceptable.
<span class="red-text"> would not be ... what happens when you change the colour to blue?
I name my ids and classes for their purpose. I try not to use descriptions that use color or direction.
For example, if I have a sidebar that is on the left, but it's for the main menu, I may name it #main or #mainMenu. The right sidebar in the same site would be #altSidebar or #subMenu.
I have many more classes than id's so naming them is a little harder.
Personally, I like to name IDs and Classes with lower-case names ranging from 1 to 3. Example would be ...
.user
.user-profile
.user-profile-picture
And if I want to style another user using classes ...
.user-2
.user-2-profile
.user-2-profile-picture
Like the others have said, you should not use attributes as names, rather, you should use elements like ...
user, picture, header, message, text, input, output.
And so on.
Do not use attributes, like ...
red, big, left, dark, light ...
These are bad because they could change from red to blue for example. But user will always be user.
The span element seems to be exactly like a div, but at the in-line level rather than at the block level. However, I can't seem to think of any beneficial logical divisions that the span element can provide.
A single sentence, or word if not contained in a sentence, seems to be the smallest logical part. Ignoring CSS, since CSS is only for layout and not for semantic meaning, when does span provide additional semantic value by chopping up a sentence or string of words?
It seems that in all cases, other elements are better suited to adding semantic value, making span a purely layout element. Is this true?
Span can be used to add semantic meaning that falls outside the scope of HTML. This can be done by using classes which identify certain attributes. For example, if you are writing a science-fiction novel you can use span to identify made-up words, because you may want to format those differently, or because you may want the spell-checker to ignore them:
Then the wizard called upon the <span class="wizardword">gravenwist</span> and bade it attack the approaching army. The <span class="wizardword">gavenwist</span> resisted but the wizard's <span class="wizardword">wistwand</span> was too powerful.
This could render as
Then the wizard called upon the gravenwist and bade it attack the approaching army. The gavenwist resisted but the wizard's wistwand was too powerful.
Another good example of this sort of thing are microformats, which allow the creation of arbitrary structure within HTML:
<span class="tel">
<span class="type">home</span>:
<span class="value">+1.415.555.1212</span>
</span>
The advantage of span, versus div, is that spans can appear almost everywhere because they are inline content, and divs are block elements, so they can only occur inside certain other elements.
A very useful benefit would be to mark changes in language. E.g.
<p>Welcome to Audi UK, <span lang="de">Vorsprung durch Technik</span>.</p>
Screen readers with multiple language capabilities could make use of this.
So they're not presentational, just generic. In fact, spans are rarely presentational, providing a semantically-meaningful class name is used, like "spelling-mistake" and not "bold-red-text".
<div class="name">
<span class="firstname">John</span>
<span class="lastname">Doe</span>
</div>
It depends completely on what you want to express. If marking up the first name is of semantic value to you (be it just to have a hook for CSS to format first names or to extract them using some scripting language), then you can use a span.
I use SPAN a lot when I want to have JavaScript parse the element and insert some value inside the tag, for example:
<span datafield="firstname"></span>
Would have a value inserted into it later, so in that case it does have meaning, though only a meaning that I decide to give it. The fact that span otherwise has no effect on the layout is ideal in that case.
spans can actually be carriers for semantic information in form of class attributes. This is used by microformats.
span tags need a class or id attribute to give them meaning.
e.g. <span class="personal_phone_number">0123 456789</span>
Ignoring CSS, since that will give the
semantic meaning, when does span
provide additional semantic value by
chopping up a sentence or string of
words?
Ignoring CSS (and other non-HTML markup), never. A <span>'s only purpose in life is to carry markup that you can't express in HTML. Markup such as <span style="dropCap">, which doesn't have an equivalent in HTML but has existed in print publishing for hundreds of years, and which is always applied to just one character - the first letter of an item (article, whatever), without causing a word-break (or any larger break).
It seems that in all cases, other
elements are better suited to adding
semantic value, making span a purely
layout element. Is this true?
Yes and no. The only real value of <span> is that it is semantically neutral. That is, unlike for example <p>, it doesn't do anything that you might want to have it not do when you're using it to carry other markup. And there are times, like <span style="dropCap"> above, when you don't want any other effects.
If you want to apply formatting rules to part of the contents (for example a single word or sentence) of a tag. You can use the span tag. It is sometimes called tagless formatting.
I use spans in my EBNF -> XHTML converter to apply a different format to literals and tokens.
SPAN (and DIV) elements by themselves are generally considered to be semantically neutral. A good approach is to use semantic markup as much as appropriately possible, but sometimes you run into situations where the existing html elements that do provide semantic meaning (EM, STRONG, ABBR, ACRONYM, etc, etc) aren't the right fit semantically for your content. So the next step is to use a semantically neutral SPAN or DIV with a semantically meaningful id or class.
I think he's asking about the difference between a div and a span, and there really isn't one, other than the default behavior.
It's a matter of convention. When using styling, div is typically used to demarcate divisions of content, while span is used to demarcate inline text. You could just as easily use div everywhere or use span everywhere, but it's helpful to think of them as different, even if it's only by convention.
In HTML could be used for microformats. But since actual HTML specification is XHTML, there is no point.
Instead of:
<P>Hello, my name is <SPAN class="name"> Joe Sixpack </SPAN></P>
I'd rather use:
<P>Hello, my name is <FOAF:name> Joe Sixpack </FOAF:name></P>
The meaning of SPAN is "this is a (generic) span of (e.g., text) content". Compare to DIV, which means "this is a logical division (i.e., a generic document section)".
SPAN is mainly a hook for hanging styles off of (so you can use <span style='color:blue'> instead of <font color='blue'>).
From the spec:
The DIV and SPAN elements, in conjunction with the id and class attributes, offer a generic mechanism for adding structure to documents. These elements define content to be inline (SPAN) or block-level (DIV) but impose no other presentational idioms on the content. Thus, authors may use these elements in conjunction with style sheets, the lang attribute, etc., to tailor HTML to their own needs and tastes.
Suppose, for example, that we wanted to generate an HTML document based on a database of client information. Since HTML does not include elements that identify objects such as "client", "telephone number", "email address", etc., we use DIV and SPAN to achieve the desired structural and presentational effects. We might use the TABLE element as follows to structure the information:
<!-- Example of data from the client database: -->
<!-- Name: Stephane Boyera, Tel: (212) 555-1212, Email: sb#foo.org -->
<DIV id="client-boyera" class="client">
<P><SPAN class="client-title">Client information:</SPAN>
<TABLE class="client-data">
<TR><TH>Last name:<TD>Boyera</TR>
<TR><TH>First name:<TD>Stephane</TR>
<TR><TH>Tel:<TD>(212) 555-1212</TR>
<TR><TH>Email:<TD>sb#foo.org</TR>
</TABLE>
</DIV>
<DIV id="client-lafon" class="client">
<P><SPAN class="client-title">Client information:</SPAN>
<TABLE class="client-data">
<TR><TH>Last name:<TD>Lafon</TR>
<TR><TH>First name:<TD>Yves</TR>
<TR><TH>Tel:<TD>(617) 555-1212</TR>
<TR><TH>Email:<TD>yves#coucou.com</TR>
</TABLE>
</DIV>