When use categorical axis, the grid still drew in the middle of a category which you can find in here. By the way, the striped-rows style would be great for this situation(Yes, it is a table, but it can be used in plots right?).
Good point, ticks and gridlines halfway between the category labels is often better than aligned with the labels, as they are for numeric or date axes. Not always, for example label-aligned may be better for scatter/bubble plots. Also I'm not sure what the right behavior is when categories get too dense and we can't show them all...
Striped rows is interesting, I see a few examples of it elsewhere, like here - it's not an effect I'd use myself, I think it makes interpreting the data harder. But we'd entertain a PR to add it 馃槃
striped rows but striped columns, so the two adjacent category can distinguish easily
Nice, I'd call that the same feature (just applied to the x axis instead of y) but that does seem like a more useful application of it. Note that if you zoom out in your example you can see the issue I was worried about, when categories get too dense and the stripes (and/or ticks/lines) get put in what's suddenly a weird place:

Another advance would be the category region hover highlight
interesting, kind of a generalization of the idea of spikelines https://github.com/plotly/plotly.js/pull/1461 - perhaps this could fit into that framework.
In my opinion, for the dense data, user/developer should change their design like zoom their axis or change the plot type like this one

When there are too much bar, then you should use polar coordinates, so I think the stripe style should be an option weather for xaxis or yaxis, but the user/developer should consider is it fix to their work.
Basically here we just want a new ticksbetweenlabels boolean to start right?
Yep, a simple switch of some sort, at least for category axes. But ticksbetweenlabels: true sounds to me as though it could be enabling minor ticks, rather than just moving the existing ticks. How about boundaryticks: true? Or tickson: ('labels'|'boundaries')?
I think the desired behavior is unambiguous for category axes - the labels always align with the data points, and ticks (and gridlines, and stripes if we do that) always go half a category to the left (NOT necessarily halfway between the ticks, in case dtick !== 1, see https://github.com/plotly/plotly.js/issues/2601#issuecomment-386312022). But for date axes (which I realize we need not support now, just want to ensure our solution will extend) there are two cases of ticks not aligning with the labels, based on the ambiguity over whether a date/time value represents an instant (eg the timestamp midnight January 1) or an entire time period (eg the month of January - and in fact the period in question could be anything as well - a day, month, quarter, year... I suppose period of < 1 day is also possible but once you have a time in the data it's implied you're describing exact instants):
['2018-01', '2018-02', ...] but this represents each calendar month, not the instant each month starts, so you want labels January, February... but ticks half a month before the labels. If you were to zoom out on this data so you only get year labels, the ticks must still be shifted half a month left, not half a year, but also the year labels should be shifted to the middle of the year.You could imagine combining period and timestamp data, or data of different period, on the same date axis; for example you have monthly sales data (period is a month) and you overlay it with daily weather data (period is a day, or precisely timestamped). For this reason it seems to me that for date axes, the right way to do this is very different from category axes:
trace.x, there should also be a trace.xperiod, and we might try to automatically determine its default value - if the data is all truncated to months we can infer xperiod: 'M1' for example.I don't see a reason to extend this behavior to numeric axes; seems to me if someone wants behavior like this for numbers of some sort they can just display those numbers on a category axis. Can anyone think of a situation in which this wouldn't work?
I think what you propose makes sense but for now I would just get a flag that works for categorical axes :)
for now I would just get a flag that works for categorical axes
Hence my comment:
which I realize we need not support now, just want to ensure our solution will extend
As I was thinking it through, I initially thought a different approach would be needed for dates, in which case for consistency we'd have wanted to change categories too. But in the end I believe ^^ (with whatever terminology we settle on) will work for both cases 馃帀
Most helpful comment
Hence my comment:
As I was thinking it through, I initially thought a different approach would be needed for dates, in which case for consistency we'd have wanted to change categories too. But in the end I believe ^^ (with whatever terminology we settle on) will work for both cases 馃帀