I am trying to start grid column from half of the very first column.
I tried grid-start-column with different values but it's not working. Basically, it should be like following:
grid-column: 0.5/7
I know this is not the valid code, but just for explanation I write that.
Is it possible to start a column from the half of the column?
Is it possible to start a column from the half of the column?
No. It is not.
Let's say you have a grid container with five columns and want to start spanning from halfway inside the first column (grid-column: 1.5 / 5 ). This won't work because you're not starting at a column line. More technically, the grid-row-* and grid-column-* properties accept only integers as values.
However, there is a simple workaround:
Instead of five columns use 10 columns.
Then start spanning at the third column (grid-column: 3 / 10).
This creates an equivalent layout, which looks the same visually, but with more precise control of the columns.
More details here: Changing div heights using CSS grid
I have two columns, one of values for a variable and another of rankings of those values. The rankings column works fine; it is aligned left and 70% of the size of the values column. However, in the values column, all values in the column align right (as I want them to) except for the last value. The issue seems to be related to the number of characters in the value.
Here are the two columns
Any ideas?
It seems the last value is still aligning-right, but as you mentioned with the increased values in the left column it is pushing them together. If you are able, increasing the overall size of the column to account for increased values. (e.g. increase column padding and/or width).
I am aware of the named areas in CSS grid, which is useful but requires you specify both column and row and can not expand after that. However, I need a table with infinite rows. I want to place each row's data to its corresponding column by assigning it to its named column. I've looked up the MDN and other sources but didn't find specific knowledge. Could someone here point out a direction? Thanks.
columnA ColumnB ColumnC
dataA dataB dataC
..... ..... ....
[namedA] [namedB] [namedC]
The CSS Grid specification provides for named grid areas, as you have noted.
It also provides for unnamed grid areas.
However, there is nothing in the Grid specification that allows for named grid tracks (columns/rows).
In fact, there is nothing in CSS in general that allows for targeting columns or rows.
You'll either need to use an explicit grid (allowing for defined positioning of grid areas) or JavaScript.
I haven't been able to find the answer to this question: Where in the spec or in UA documentation is the default width of a <td> defined?
I've searched the HTML Living Standard, the HTML5 Recommendation, and various other sources.
My understanding (based on usage and observation) is that a table cell will, by default, occupy the full width of the column in which it lives. And the cell cannot be given a different width than the column if other cells exist in the column.
I'm looking for official confirmation of this behavior, preferably in W3C or user agent documentation. But any authoritative reference is acceptable.
The physical/visual width of a table cell is defined not by HTML, but by CSS. The CSS 2.1 specification has an entire section dedicated to table layout that complements HTML's description of tabular data.
Furthermore, CSS itself does not fully define how the width of a cell is calculated. It does with the fixed table layout algorithm:
In the fixed table layout algorithm, the width of each column is determined as follows:
A column element with a value other than 'auto' for the 'width' property sets the width for that column.
Otherwise, a cell in the first row with a value other than 'auto' for the 'width' property determines the width for that column. If the cell spans more than one column, the width is divided over the columns.
Any remaining columns equally divide the remaining horizontal table space (minus borders or cell spacing).
The width of the table is then the greater of the value of the 'width' property for the table element and the sum of the column widths (plus cell spacing or borders). If the table is wider than the columns, the extra space should be distributed over the columns.
but it doesn't give anything beyond a rough guideline for auto table layout, which user agents are free to follow or deviate from (it lists a step-by-step procedure not unlike that of fixed table layout, but that entire list is non-normative). Generally you can expect consistent behavior from UAs in the most common scenarios — as you observe, an auto-sized table cell generally takes up as much space as required by its content, and no more. But dig into edge cases, and you'll find all sorts of crazy.
Here's the W3C standards on calculating the width of table columns. Basically it is left up to the implementing browser/agent.
If an author specifies no width information for a column, a user agent
may not be able to incrementally format the table since it must wait
for the entire column of data to arrive in order to allot an
appropriate width.
If column widths prove to be too narrow for the contents of a
particular table cell, user agents may choose to reflow the table.
Source: http://www.w3.org/TR/html401/struct/tables.html#h-11.2.4.4
Note: this is HTML4 docs.
A table cell's minimum width is 0 or the size of the largest word or image within that cell.
Table Sizing Algorithm
The default sizing algorithm requires two passes through the table data. In the first pass, word wrapping is disabled, and the user agent keeps track of the minimum and maximum width of each cell. The maximum width is given by the widest line. As word wrap has been disabled, paragraphs are treated as long lines unless broken by elements. The minimum width is given by the widest word or image etc. taking into account leading indents and list bullets etc. In other words, if you were to format the cell's content in a window of its own, determine the minimum width you could make the window before things begin to be clipped.
The minimum and maximum cell widths are then used to determine the corresponding minimum and maximum widths for the columns. These in turn, are used to find the minimum and maximum width for the table. Note that cells can contain nested tables, but this doesn't complicate the code significantly. The next step is to assign column widths according to the current window size (more accurately - the width between the left and right margins).
The table borders and intercell margins need to be included in the assignment step. There are three cases:
The minimum table width is equal to or wider than the available space. In this case, assign the minimum widths and allow the user to scroll horizontally. For conversion to braille, it will be necessary to replace the cells by references to notes containing their full content. By convention these appear before the table.
The maximum table width fits within the available space. In this case, set the columns to their maximum widths.
The maximum width of the table is greater than the available space, but the minimum table width is smaller. In this case, find the difference between the available space and the minimum table width, lets call it W. Lets also call D the difference between maximum and minimum width of the table.
For each column, let d be the the difference between maximum and minimum width of that column. Now set the column's width to the minimum width plus d times W over D. This makes columns with lots of text wider than columns with smaller amounts.
This assignment step is then repeated for nested tables. In this case, the width of the enclosing table's cell plays the role of the current window size in the above description. This process is repeated recursively for all nested tables.
If the COLSPEC attribute specifies the column widths explicitly, the user agent can attempt to use these values. If subsequently, one of the cells overflows its column width, the two pass mechanism may be invoked to redraw the table with more appropriate widths. If the attribute specifies relative widths, then the two pass model is always needed.
The column width assignment algorithm is then modified:
Explicit widths from the COLSPEC attribute should be used when given, provided they are greater than the minimum column width, otherwise the latter should be used.
For relative widths, the surplus space W, as defined above, is divided up between the columns appropriately, ensuring that each column is given at least its minimum width. If W is zero or negative, column widths should be increased over the minimum width to meet the relative width requirements.
If the table width is specified with the WIDTH attribute, the user agent attempts to set column widths to match. The WIDTH attribute should be disregarded if this results in columns having less than their minimum widths.
In the agenda day+week view there are two separate tables for days and slots.
The days table essentially has a blank left column, x number of full height columns for each of the days with the date at the top (in a <thead> tag), and finally a right gutter with the scrollbar.
The slots table has y rows for each time slot (obviously a dynamically calculated number of rows). They have two cells per row. One for the time (12am) and one full-width cell that is only used afaik to display alternating dotted/solid horizontal borders.
My question (to the devs hopefully) is why did you make this choice, when compared to one table that contains x columns and y rows? Do you have plans to consolidate it into one table?
The reason I'm asking is because I am forking the code now to make it so that individual days+time slots are addressable (i.e. set the bgcolor on 8-10am on nov 12th to be red ... or disallow events to be dropped there).