I am implementing a schedule application that displays activities as rows and time shifts as columns. It allows users to group activities and days, spanning rows and columns. I posted a mock up at http://www.volunteeryourself.com/sch.htm. Would you do this data table/layout as a CSS or table? I can make either one work, just not sure which is better.
Given some of the features and the need to allow the user to add/manipulate items, I think CSS would work best.
Sorry if this is not the type of question to post here.
I'll say what I said earlier, If you are trying to achieve the image above the tables with the table content then DIV's and CSS will be less hassle.
If you are laying out pure tabular data then use tables, but tables are normally harder to style and get positioning etc right with.
it's tabular data, therefore you should use tables.
CSS can be used for this, (or I should say, a combination of divs/spans etc), but you would be creating unnecessary work for yourself.
By all means use CSS to style the table, but the bulk of the layout should be done using semantic table markup.
Related
I am challenged to make an HTML table/grid accessible, which offers the user the possibility to select a row and perform an action on the selected row.
The following link gives an example, on how everything shall look like (without accessibility):
https://alejandro.app.fi/crud-ui-demo/simple
My problem is:
How do I make the buttons on top of the page, for performing the action on the row, accessible? How can I get the screen reader to announce the part, so that the user is able to interact with it?
In my opinion it would be a bad idea, to let the screen reader read something like "To edit this row tab back xyz times and use the buttons above the table"
I searched through the wai-aria and was hoping to find something like a "connector" to give the screen reader a connection to these buttons at the top, but could not find anything, that would fit.
Is this a bad pattern, with which I want to work with? Or how can this be solved?
A large table with internal selectability and external editing controls is inherently difficult to use, even without any disability.
Large tables are hard to get intuitive information from.
Wide tables or tables viewed in narrow windows require horizontal scrolling.
Selectability tends to be confusing, because you are focused on a cell, but when you select it you might want to select it, its row, or its column, so you need a way to distinguish these three kinds of selection. Also, it is not obvious whether selection automatically follows focus or requires a separate action.
External editing controls are distant from much table content, so when you are looking at the controls the selected row may be out of sight, making you forget which row you selected.
Screen readers have poor support for tables and often give wrong header information about cells.
If you asked what users wanted, most probably would not tell you they want to see hundreds of alphanumeric facts arranged in a grid. For editing data, most users might want (1) a way to find the desired data and (2) a way to edit those data. Displaying all the data in a table is unlikely to be a user-friendly method for achieving either #1 or #2.
Clever rendering methods may fail under common conditions. For example, above the cited table is a horizontally scrollable top list of table types. On a narrow device, the right end of the list cannot be scrolled into view.
In principle, tables can be WCAG-accessible. In practice, tables, especially if large, complex, or operable, are usually inferior to other solutions in usability and accessibility.
I'd like to create a multiple rows + multiple columns view.
I think I can either use table or grid.
Which one should I use over another and why?
Summary
Grid
Using a grid makes content appear to flow more naturally on your page.
Table
A standard table.
from Semantic-UI
Explained
Grids
The CSS Grid Layout specification is one of a few new specifications
that are redefining how we approach layout for the web. Alongside
Flexbox and the Box Alignment Module it will become part of a modern
layout system for websites and web applications.
from Grid by Example
Table
Table is just a layout, and could be complex for complex views. Just think in spreadsheets. You can merge columns and rows to get your layout.
Opinion
You can use the option you want, according to your needs. But if you are looking to organize your web content, use grids; If you need to deploy data use tables.
That all depends on the requirement. for example, If you want them to maximize the use of the page; maybe for a report with multiple columns over the whole webpage and you knew beforehand on what device your page would be rendered then use a table because you can pinpoint each and every column to exact pixels.
But if the rendering device might be any device or the rendering device info is not available then use grid because it would automatically adjust to the available layout space.
I've been developing desktop aps, so my aspx/html got a bit rusty. What I need to do is layout an aspx page with fields that look something like this (there are many fields, this is just an abstraction):
Basically, the items look like they are in rows, but not in distinctive columns (e.g. in my example, street name doesn't have to allign with street number etc...)
I want to achieve maximum compatibility with browsers - what would be best to use for this scenario? Tables, list items... divs? something else?
I'm using aspx C# 4.0.
Here's a non-table example:
http://jsfiddle.net/eRY8T/7/
The conventional wisdom is that table should be used for displaying data in tabular format, not for laying out forms.
In practice I think it is sometimes easier to use tables for forms - but this is typically when your form looks like tabular data (e.g. one column for labels, another for inputs).
In your situation, I think using divs is actually easier than tables would be. This would probably require lots of rowspan/colspan/nested tables to get right.
The other advantage of using a CSS based layout over tables is that the tab order will probably make more sense. In the example, notice how tab goes through the first column then the 2nd one. In a table it would go through every input on a given row before moving to the next row.
How about Table with 4 Rows and 7 Columns
and use corresponding colspan for better alignment.
I'm in need of some pointing in the right direction here...
I have a site with a couple of different content types. I want to display this content in a book-like layout. The book should be of a fixed width and height and the pages should be populated with as many nodes as can fit. It should be in two columns, with the left column being filled before the right one.
How should i approach this?
I have been thinking about a few solutions, don't know which are possible and which one is best or which i can combine.
I could just create a view that selects more nodes than is need. Then check how long the nodes is in the theming layer and throw away the nodes that aren't needed. Pagers need to be fixed too.
Use panels in combination with views to display one view in two columns, if this is possible. Need a way to determine the amount of nodes that is displayed on each page, based on content length.
Write a plugin/handler for views so that i can select an amount of nodes that has an maximum, predetermined, max content length.
Write a new display-style for views that shows content in two columns with fixed heights.
Write a custom module, leave views and panels out of it and do everything myself with db_queries.
Would appreciate and guidance a lot. Not looking for a finished solution, i'm not afraid to code and i will contribute back if i create something that someone else can use (like a views plugin). Just need someone to guide me in the right direction :)
The hardest thing will be to figure out how much content you need to fill out the space. There's not really a good way to do that either since, it will depend on both the markup and the styles.
The best solution I can think of is loading the nodes with javascript, or maybe just have them available as javascript variables. That way you could insert the nodes to your page one by one. You could then in the JS see the heights of all the nodes in total, and once that height is bigger than x, you only need to remove the last inserted node.
It's not a perfect solution, but I think you should look at doing this with JavaScript. The only problem is, that it wont degrade gracefully very well.
Drupal help you build fast, and it looks like promising but fails to fullfil the needs of client, designer also programmer. You need to write one module page, and some functions.
5th solution you gave has little trouble than others. Write a function that to have "teaser like" behavior, I will return formatted node according to its type. Don't lay on drupal's teaser system. If teasers will have different heights, add height to teaser function.
I don't have a direct answer, but have a few things for you to think about.
It sounds to me like what you are looking for is a combination of a CSS3 Multicolumn Layout (see http://www.quirksmode.org/css/multicolumn.html for example) and limiting the displayed content to a fixed height.
My first thought would be to create a single view that gets more than you need, display it using CSS3 columns, and set overflow: hidden; for the container, so that the extra text is just hidden.
If you need to get more particular, you may need to dig in to the views rendering system to limit the total number of nodes based on how many characters have been rendered.
But since your desired constraint is more visual than data-oriented, I think that the most practical approach will be to use javascript to detect the text height and state of overflow.
There are some things that are unclear about your requirements. What is the purpose of the 2 content types? Does one display on the left and the other on the right? Or are these just 2 different content types that should behave the same way, but we're only seeing one content type at a time on a given page? What should happen with the overflowed content? Should it appear dynamically on page 2, then 3, then 4, and so on?
One parting thought: Maybe load ALL the content that you want to page through, directly to the browser. Maybe have it start off hidden. Then use javascript to display it, formatted into columns, and use javascript to handle the paging as well.
Is it bad design to use table tags when displaying forms in html?
The accepted answer to this question in short: YES...
...but what about something like this:
I can't really think of different & better solution. The example is from SurveyMonkey and uses tables too.
Is it still bad design to use table tags for such likert type questions?
This type of question leads more to opinions than to hard and fast facts, but I would say that in this case it's definitely OK to use tables -- you're wanting a tabular display of information.
Just use the table tag and don't let people make you feel guilty for it :-)
It's not bad to use tables per se. It's just bad to use them to layout your entire site using infinitely nested tables and invisible images for space.
This is not very hard with some help.
You might look into some of the grid-based css libraries our there.
Yahoo Grids
Blueprint
960 Grid System
What everyone says is "you should only use tables for tabular data". So ... what does that mean?
Here's my criterion for when something actually is tabular data: when you can only know what something is/does by reference to its coordinates, its position in relation to column and row headers.
So, in the case above, what is the function of the ninth radio button?
There's no way of knowing what it is unless you look left to the kind of skill it refers to and look up to the kind of level you're claiming. Therefore, this is tabular data.
From the point of view of accessibility, IMHO, it would make more sense laid out as a table, with appropriate th tags etc. As Ambrose said, the coordinates of the radio buttons give them contextual meaning.
You could lay it out without a table, and maybe make sense of it using labels, titles and other devices, but the only thing you would really achieve would be to demonstrate your css-fu.