Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Post History
In addition to what Moshi already told you: Among web designers, W3Schools has a somewhat tainted reputation, because it often makes things simpler than they really are. In my experience, this lac...
Answer
#1: Initial revision
In addition to what Moshi already told you: Among web designers, W3Schools has a somewhat tainted reputation, because it often makes things simpler than they really are. In my experience, this lack of accuracy often causes more wasted work than reading a more reputable source to begin with. My go-to sources are: * MDN, for solving practical problems. * The W3C standards for understanding why things work the way they do. Since Moshi has already quoted MDN, all that remains is [the W3C standard](https://www.w3.org/TR/CSS2/tables.html#columns): > **17.3 Columns** > > Table cells may belong to two contexts: rows and columns. However, in the source document cells are descendants of rows, never of columns. Nevertheless, some aspects of cells can be influenced by setting properties on columns. > > The following properties apply to column and column-group elements: > > * `border` > The various border properties apply to columns only if 'border-collapse' is set to 'collapse' on the table element. In that case, borders set on columns and column groups are input to the conflict resolution algorithm that selects the border styles at every cell edge. > * `background` > The background properties set the background for cells in the column, but only if both the cell and row have transparent backgrounds. See "Table layers and transparency." > * `width` > The 'width' property gives the minimum width for the column. > * `visibility` > If the 'visibility' of a column is set to 'collapse', none of the cells in the column are rendered, and cells that span into other columns are clipped. In addition, the width of the table is diminished by the width the column would have taken up. See "Dynamic effects" below. Other values for 'visibility' have no effect. As you can see, `text-align` is not among these properties, and the explanation of the other properties hints at the reason: To ensure interoperability each column property comes with a conflict resolution algorithm that defines what happens if the property is in conflict with properties specified on other elements. Now, you might argue that such an algorithm is trivial, for instance like: > the text align of a cell is the property of the cell, row, or column, in that order of preference. but it's not quite that easy. For instance, what happens if I have a rule like: th { text-align: center; } but my column says it should be right aligned. One could argue that the column should win, because the rule is specific to that column. Or that the th should win, because it is specific to the kind of cell. Either could be the author's intent. In contrast, if the author identifies the cells to be formatted using CSS selectors instead, he can express the relative priority of the various rules as usual in CSS. For instance, he could say: table.numeric th, table.numeric td { text-align: right; } table.numeric th[colspan] { text-align: center; } table.numeric > tbody > tr > th:first-child { text-align: left; /* row headers */ } which also allows for much better reuse of layout rules across tables, aiding in achieving a consistent layout. Ok, with that I'll stop trying to read the minds of the working group. I just wanted to demonstrate that primary sources often contain hints that are invaluable in understanding why things are the way they are.