plotly.js/scratch/alexcjohnson_comments.json

The open source javascript graphing library that powers plotly

[
  {
    "body": "Excellent, looks great! This time the image tests actually ran, and for some reason `container-colorbar-vertical-w-margin` failed to render in both cases - can you try this mock on your branch and see if something really did break there? Once that passes we'll also need a baseline image for your new mock, but that's easiest to do off the artifacts in the `test-baselines` job, once we get to that point.",
    "created_at": "2025-05-16T01:26:59Z",
    "html_url": "https://github.com/plotly/plotly.js/pull/7417#issuecomment-2885400727",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/7417",
    "updated_at": "2025-05-16T01:26:59Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "@my-tien this looks great. There are some more test failures in `axes_test.js`, see https://app.circleci.com/pipelines/github/plotly/plotly.js/11937/workflows/35ad298f-0a05-44b8-95de-f8adbfef3f09/jobs/264167 - as mentioned @emilykl is working on the image test failures in #7418 but please make sure that *only* image tests are failing 😅 ",
    "created_at": "2025-05-15T14:05:00Z",
    "html_url": "https://github.com/plotly/plotly.js/pull/7417#issuecomment-2883941114",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/7417",
    "updated_at": "2025-05-15T14:05:00Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "Oh that's cool, thanks for pointing that out! We should be able to use `kbwood/world-calendars` directly rather than doing codegen from your jQuery package. I'm not sure if plotly.js has any TypeScript dependencies right now but that should not be a blocker.\n\nI'm curious what you plan for these projects going forward. Clearly it's not ideal to be maintaining two parallel codebases, perhaps there's a route to `calendars` becoming a thin jQuery wrapper around `world-calendars`?",
    "created_at": "2025-05-15T13:49:33Z",
    "html_url": "https://github.com/plotly/plotly.js/issues/7421#issuecomment-2883888463",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/7421",
    "updated_at": "2025-05-15T13:49:33Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "It isn't really possible for us to use `kbwood/calendars` directly, as it's structured as a jQuery plugin. But `world-calendars` is codegen'd from `kbwood/calendars`, we just have to rerun the codegen on the new version, and make any updates necessary for that to work. And perhaps also find a way to either pull the codegen input directly from `kbwood/calendars` or automate copying it into the `world-calendars` repo, I originally just copied the relevant files manually.\n\nI'm kind of in the same boat as @kbwood in that I don't really understand the distinction between `persian` and `iranian`, it kind of sounds like only `iranian` is in common use but perhaps we keep both and just add an explanatory note to our docs for both, something like \"`persian` and `iranian` differ only in leap year algorithm. `iranian` is the calendar in current common use in Iran.\"?",
    "created_at": "2025-05-14T19:28:06Z",
    "html_url": "https://github.com/plotly/plotly.js/issues/7421#issuecomment-2881324782",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/7421",
    "updated_at": "2025-05-14T19:28:06Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "@hmanz we (Plotly) will need to rebuild using the new version of @kbwood's calendar code in order to get the new `iranian` calendar. And again that may take some time due to the altered structure so bear with us.\n\nBut I'm still unclear on the usage of these calendars and how we can help our users to pick the correct one for their needs. @Vahid-Taheri what do you mean by \"mostly use Jalali\"? Are there specific cases where the other one is used?",
    "created_at": "2025-05-12T12:23:24Z",
    "html_url": "https://github.com/plotly/plotly.js/issues/7421#issuecomment-2872348476",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/7421",
    "updated_at": "2025-05-12T12:23:24Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "Nice find and diagnosis @my-tien! I wonder though if there's a better way to do this - specifically, adding this whole extra loop at the end, in addition to being unnecessary vs. just doing the desired thing from the start, I worry it will cause those labels to be missing later like if you drag the axis around, either during or after the drag.\r\n\r\nInstead, I wonder if we can avoid this extra step by instead of `opacity: 0 | 1` use `display: none | block` here:\r\n\r\nhttps://github.com/plotly/plotly.js/blob/8e2a5d764c6c4b4d82ba958c2631ed26b9c00cb8/src/plots/cartesian/axes.js#L3654\r\n\r\nand here:\r\n\r\nhttps://github.com/plotly/plotly.js/blob/8e2a5d764c6c4b4d82ba958c2631ed26b9c00cb8/src/plots/cartesian/axes.js#L3712-L3714\r\n\r\nBecause unlike `opacity: 0`, `display: none` causes `getBoundingClientRect` to give zero size.",
    "created_at": "2025-05-09T03:30:46Z",
    "html_url": "https://github.com/plotly/plotly.js/pull/7417#issuecomment-2864981933",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/7417",
    "updated_at": "2025-05-09T03:30:46Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "Thank you @kbwood - and I don't think we've corresponded before but let me say thank you for creating and maintaining your calendar plugin, that's been the basis of Plotly's international calendar support for nearly a decade now!\n\nIt does look like your leap year logic in [iranian.js](https://github.com/kbwood/calendars/blob/7070ac5f0985ffcfbf784e918124b80fed800b4a/src/js/jquery.calendars.iranian.js#L250-L255) matches that in [ng2-datepicker-jalali](https://github.com/mehrabisajad/ng2-datepicker-jalali/blob/d271c9ba511e84a7d0adb1a5609fa32ec4fe60f6/src/ngb-calendar-persian.ts#L201-L210). The `persian-leap` package uses a bit different logic so it's a bit hard to match up but it also has [two different calculations available](https://github.com/movahhedi/persian-leap/blob/8dcd5567509a6f3ade559f2e32bae941eac6944e/src/index.ts#L6-L22), presumably corresponding to the distinction between your Persian and Iranian calendars. Do we know if both of these calendars are in use, and if so in what contexts? We can certainly follow your lead and include both, but because they're so similar it would be useful to give users clear guidance on their usage. I see on [your docs](http://keith-wood.name/calendarsRef.html) that the Iranian calendar is \"also known as Solar Hijri calendar\" whereas the Persian is \"also known as Jalali calendar\" but the implication of this discussion is that @Vahid-Taheri considers your Iranian/Solar Hijri to be the Jalali calendar so I gather there's still some confusion.",
    "created_at": "2025-05-08T13:29:51Z",
    "html_url": "https://github.com/plotly/plotly.js/issues/7421#issuecomment-2863079720",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/7421",
    "updated_at": "2025-05-08T13:29:51Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "Hmm I was optimistic that the new upstream version would fix the issue you identified @Vahid-Taheri, especially since the latest version over there is just two months old (suspiciously close to the date this discrepancy occurs!) but it seems the `leapYear` code has not changed since then. Here's the current [kbwood code](https://github.com/kbwood/calendars/blame/master/src/js/jquery.calendars.persian.js#L81-L85) for Persian leap year and the corresponding [world-calendars code](https://github.com/alexcjohnson/world-calendars/blob/810693882512dec1b804456f8d435b962bd6cf31/dist/calendars/persian.js#L93-L97)\n\n@Vahid-Taheri is that the same code you were trying to edit? Do you have a proposed update that would give the correct leap years in all cases? Or a reference you can point us to for precisely how to decide which years are leap years?\n\nIdeally I guess this means we should open a PR upstream to fix the bug there before we update world-calendars.",
    "created_at": "2025-05-07T16:43:50Z",
    "html_url": "https://github.com/plotly/plotly.js/issues/7421#issuecomment-2859277874",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/7421",
    "updated_at": "2025-05-07T16:43:50Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "FYI back in 2016 when we pulled the original I apparently didn't find it published on NPM so I copied the source code into my repo. It now apparently is published: https://www.npmjs.com/package/kbw-calendars - but I only see up to v2.1.0 published there while the latest in https://github.com/kbwood/calendars is v2.2.0, so I guess best is to still copy in the source code. Also note that in v2.1.0 kbwood reorganized the repo, so there will likely be a bunch of work to get the codegen working again.",
    "created_at": "2025-05-07T16:27:25Z",
    "html_url": "https://github.com/plotly/plotly.js/issues/7421#issuecomment-2859232850",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/7421",
    "updated_at": "2025-05-07T16:27:25Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "Hi @Vahid-Taheri, thanks for pointing this out! [`world-calendars`](https://github.com/alexcjohnson/world-calendars) is a package we created specifically for plotly.js, though apparently it's still housed in my personal GH account (@gvwilson FYI I'm happy to keep it or transfer to the plotly org at your discretion). It hasn't been updated in 8 years because nobody has reported any issues with it during that time, until now. Originally the project was codegen'd from [this JQuery plugin](https://github.com/kbwood/calendars) by @kbwood, which I see has had some updates since we pulled it in 2016, so perhaps your issue has already been fixed upstream and we should just rebuild and pull it through? Alternatively we could break that link and inline the code in plotly.js, or we could move the codegen into plotly.js - though there are apparently [a few non-plotly.js dependents](https://www.npmjs.com/browse/depended/world-calendars) on world-calendars so the best overall would be to fix it in place.",
    "created_at": "2025-05-07T15:45:25Z",
    "html_url": "https://github.com/plotly/plotly.js/issues/7421#issuecomment-2859111954",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/7421",
    "updated_at": "2025-05-07T15:45:25Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "Neat! The code looks promising, I’ll give it a try and see how well it works",
    "created_at": "2025-03-19T20:29:54Z",
    "html_url": "https://github.com/plotly/plotly.js/pull/7392#issuecomment-2738031687",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/7392",
    "updated_at": "2025-03-19T20:29:54Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "I'm not aware of Plotly ever promoting the use of jsdelivr. I personally have no experience with it or why it would be preferred over cdn.plot.ly, which works with all these versions. (to be clear I'm not saying there's no reason - I just don't know what it is) \n\nSo I feel like the most productive path forward here would be for someone who's actually interested in using plotly.js via jsdelivr to contact the jsdelivr team and see if they can track down the issue on their side.\n\nIf this effort uncovers something we could do on our side to play nicer with jsdelivr - particularly if it comes with a test so we know we're continuing to abide by whatever constraint this is going forward - then we'd be happy to accept a PR and commit to keeping that test passing going forward. I'll note this does NOT mean we'd be committing to keeping jsdelivr working - we can't do that because we have no control over what they do.",
    "created_at": "2025-03-13T14:46:32Z",
    "html_url": "https://github.com/plotly/plotly.js/issues/7322#issuecomment-2721525384",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/7322",
    "updated_at": "2025-03-13T14:46:32Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "Also #4838",
    "created_at": "2025-03-08T00:05:22Z",
    "html_url": "https://github.com/plotly/plotly.js/issues/7384#issuecomment-2707754677",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/7384",
    "updated_at": "2025-03-08T00:05:22Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "Closed by #7325 in 3.0.1",
    "created_at": "2025-02-21T04:33:34Z",
    "html_url": "https://github.com/plotly/plotly.js/issues/6760#issuecomment-2673390601",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/6760",
    "updated_at": "2025-02-21T04:33:34Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "Good point. Maybe this would be clearer as a container with booleans in it, rather than a flaglist? That would also be more extensible, since those booleans could default to `true` which you can't do with a flaglist. This would work with a flaglist of buttons to _disable_, but that seems even more confusing.\r\n\r\nSo perhaps:\r\n```js\r\nmodebarbuttons: {\r\n    autoscale: false,\r\n    zoominout: false\r\n}\r\n```\r\nThat's more verbose when you want to disable both, but seems clearer about exactly what it applies to. Thoughts?",
    "created_at": "2025-02-19T14:30:12Z",
    "html_url": "https://github.com/plotly/plotly.js/pull/7358#issuecomment-2668823925",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/7358",
    "updated_at": "2025-02-19T14:30:12Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "@snowPu we typically don't expose direct DOM access to elements inside plots, because the plots then stop being portable. Ideally everything should be configurable through the figure object. Can you say a little more about what you're trying to accomplish?",
    "created_at": "2025-02-18T21:36:43Z",
    "html_url": "https://github.com/plotly/plotly.js/issues/7370#issuecomment-2666980700",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/7370",
    "updated_at": "2025-02-18T21:36:43Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "Excellent, thanks! Let’s use the `require().default` form for now, until we get a chance to do more extensive testing. There are a lot of ways people include this library in their projects - lots of build tools and lots of environments - so it’s not a small task to convince ourselves that a change in how files link is OK. ",
    "created_at": "2025-02-18T12:46:25Z",
    "html_url": "https://github.com/plotly/plotly.js/pull/7325#issuecomment-2665616871",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/7325",
    "updated_at": "2025-02-18T12:46:25Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "I'd love to update from `require` to `import` but I'm nervous to do just one unless we do a bunch of extra manual testing, especially given the other bundling issues we've encountered that only show up in certain environments (like #7361 and https://github.com/plotly/plotly.py/issues/5027, that we just fixed with #7367).\r\n\r\nI wonder if instead it would work to change to `var rgba = require('color-rgba').default;`?\r\n\r\ncc @marthacryan",
    "created_at": "2025-02-17T22:49:27Z",
    "html_url": "https://github.com/plotly/plotly.js/pull/7325#issuecomment-2664188324",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/7325",
    "updated_at": "2025-02-17T22:49:27Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "@Lexachoc I merged master since there have been some changes particularly with testing recently, but that didn't fix the failures we're seeing on CI, would you be able to look into it? In particular it's showing messages like `TypeError: rgba3 is not a function` from every test that tries to make a `parcoords` plot, looks like there may have been a breaking change in the API between v2 and v3? Presumably that'll be an easy fix, then we can see if there's anything left (maybe the change altered the colors in some of our baseline images? That would likely be an improvement but would still need updating in the tests, I can help with that part.",
    "created_at": "2025-02-14T22:47:16Z",
    "html_url": "https://github.com/plotly/plotly.js/pull/7325#issuecomment-2660420658",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/7325",
    "updated_at": "2025-02-14T22:47:16Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "Still an issue in 3.0 and it's become a blocker for me, I'm going to see if I can fix it.",
    "created_at": "2025-02-07T20:07:16Z",
    "html_url": "https://github.com/plotly/plotly.js/issues/6108#issuecomment-2644025893",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/6108",
    "updated_at": "2025-02-07T20:07:16Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "Curious what you want this for? We don’t generally consider DOM structure like this to be part of the public API so in principle it’s subject to change at any time, though in practice it has likely been very stable. ",
    "created_at": "2025-01-07T14:58:39Z",
    "html_url": "https://github.com/plotly/plotly.js/pull/7329#issuecomment-2575509184",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/7329",
    "updated_at": "2025-01-07T14:58:39Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "That's correct, as of v2.0 we are no longer updating `plotly-latest`. It's stuck at the end of v1.x, so that breaking changes in new major versions don't impact users of `plotly-latest`. We considered creating a new bundle that tracks the latest release (`plotly-latest-v2` or some such) but ultimately decided against it on the grounds that it's better to update explicitly so that you get a chance to test the new version.\n\n@archmoj at some point we discussed adding a console warning or some such to `plotly-latest` describing this behavior... @LiamConnors is this documented anywhere else?",
    "created_at": "2024-12-16T13:48:55Z",
    "html_url": "https://github.com/plotly/plotly.js/issues/7315#issuecomment-2545680557",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/7315",
    "updated_at": "2024-12-16T13:48:55Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "FYI apparently virtual-webgl has compatibility issues with Bokeh too, though I haven't investigated myself https://github.com/holoviz/panel/issues/7375",
    "created_at": "2024-12-06T23:10:34Z",
    "html_url": "https://github.com/plotly/plotly.js/issues/7298#issuecomment-2524587949",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/7298",
    "updated_at": "2024-12-06T23:10:34Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "Hmph I guess we DO have image animation? Investigating the test failure...",
    "created_at": "2024-11-21T01:44:10Z",
    "html_url": "https://github.com/plotly/plotly.js/pull/7277#issuecomment-2489893764",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/7277",
    "updated_at": "2024-11-21T01:44:10Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "This was merged with a failing test, but I put a fix in https://github.com/plotly/plotly.js/pull/7277",
    "created_at": "2024-11-21T00:49:31Z",
    "html_url": "https://github.com/plotly/plotly.js/pull/7273#issuecomment-2489838816",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/7273",
    "updated_at": "2024-11-21T00:49:31Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "LGTM, thanks @dberardi99! It’ll need a draftlog entry, I’d call it an addition rather than a bug fix. @archmoj I see you have this slotted for the next release after 3.0, sounds reasonable, I’ll defer to you for a final review",
    "created_at": "2024-10-25T12:31:40Z",
    "html_url": "https://github.com/plotly/plotly.js/pull/7249#issuecomment-2437657671",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/7249",
    "updated_at": "2024-10-25T12:31:40Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "Yep that’s exactly the kind of thing it tends to do unless your data is either gridded or equivalent to gridded, the real solution here is to write a triangulation contour algorithm. ",
    "created_at": "2024-10-18T20:25:55Z",
    "html_url": "https://github.com/plotly/plotly.js/issues/7239#issuecomment-2423182329",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/7239",
    "updated_at": "2024-10-18T20:25:55Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "`connectgaps` defaults to `True` when you provide 1D arrays for all the data, because we don’t have real triangulation so we make a grid, and it’s too easy to wind up with weird holes with 1D data. But you can try turning it off and maybe it’ll give the behavior you want. Better yet, grid your own data and provide z as 2D, x and y as 1D. Better still let’s put in the time to render data like this using triangulation 😉 \n\nhttps://plotly.com/python/reference/contour/#contour-connectgaps",
    "created_at": "2024-10-18T18:32:21Z",
    "html_url": "https://github.com/plotly/plotly.js/issues/7239#issuecomment-2423023570",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/7239",
    "updated_at": "2024-10-18T18:32:21Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "Yes, this is clearly a bug. All of these traces have `y=[1,1,1]` so they should each get a height of 1 no matter what else is done.\r\n\r\nIt seems that setting `zorder` confuses them about which other traces they're stacked on - each trace gets the right total y values, so they definitely know at that point what's stacked below them, but then when it comes time to draw the fills they go to the wrong place.",
    "created_at": "2024-10-18T03:54:43Z",
    "html_url": "https://github.com/plotly/plotly.js/issues/7235#issuecomment-2421280968",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/7235",
    "updated_at": "2024-10-18T03:54:43Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "@archmoj one of the tests that fails with my change is `should remove the image tag if an invalid source`. Instead we see the browser's \"broken image\" icon if it fails to load. I think this is useful behavior for chart creators so I'm inclined to leave it this way and adapt the test (run as-is in `staticPlot` mode but verify that the image points to the source unchanged in interactive mode), do you agree or do you want to call this a breaking change that I should fix?\r\n\r\nHere's me intentionally breaking the first image of the `layout-images` mock:\r\n<img width=\"786\" alt=\"Screenshot 2024-10-07 at 16 06 18\" src=\"https://github.com/user-attachments/assets/87e8d19e-5a2b-4e83-ba22-79220694aaca\">\r\n\r\nFYI we've demonstrated that this greatly improves the experience for our tile-server-in-a-graph app - using `relayout` data to decide which images to show, so overall it's definitely a win!",
    "created_at": "2024-10-07T20:36:01Z",
    "html_url": "https://github.com/plotly/plotly.js/pull/7199#issuecomment-2397844147",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/7199",
    "updated_at": "2024-10-07T20:36:01Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "Several years ago we expanded all the `title` attributes from strings to dicts, with the original string moved to the `text` field inside the dict. But we kept it backward compatible, so a figure supplied with a string gets converted to the dict form automatically. This leads to confusion, both because people will see examples done both ways and because anyone using the old one will then inspect their graphs and see something else in them, so it’s probably time to remove this compatibility layer. ",
    "created_at": "2024-10-01T18:37:11Z",
    "html_url": "https://github.com/plotly/plotly.js/issues/7177#issuecomment-2386703587",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/7177",
    "updated_at": "2024-10-01T18:37:11Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "fixed in the 2.35.3 branch",
    "created_at": "2024-09-20T21:32:13Z",
    "html_url": "https://github.com/plotly/plotly.js/issues/7166#issuecomment-2364645204",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/7166",
    "updated_at": "2024-09-20T21:32:13Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "You can also set `layout.autotypenumbers = 'strict'` (which is currently in the default plotly.py template, but in plain plotly.js the default is `'convert types'`) https://plotly.com/javascript/reference/layout/#layout-autotypenumbers",
    "created_at": "2024-09-10T21:02:24Z",
    "html_url": "https://github.com/plotly/plotly.js/issues/7147#issuecomment-2342004938",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/7147",
    "updated_at": "2024-09-10T21:02:24Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "Great! I’m afraid I don’t know much about `@types/react-plotly.js` though, that’s not made by Plotly. ",
    "created_at": "2024-09-06T02:14:01Z",
    "html_url": "https://github.com/plotly/plotly.js/issues/6025#issuecomment-2333054974",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/6025",
    "updated_at": "2024-09-06T02:14:01Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "I believe what you’re looking for is `autotickangles` https://plotly.com/python/reference/layout/xaxis/#layout-xaxis-autotickangles - implemented about 6 months ago by @my-tien 😄 ",
    "created_at": "2024-09-04T12:15:07Z",
    "html_url": "https://github.com/plotly/plotly.js/issues/6025#issuecomment-2328817490",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/6025",
    "updated_at": "2024-09-04T12:15:07Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "Yes, somewhere we need more complete documentation of what `alignmentgroup` and `offsetgroup` really mean and do (cc @LiamConnors - also in writing this up I found a bug https://github.com/plotly/plotly.js/issues/7133). Let me take a shot at it here:\r\n- Traces of any type in the same `alignmentgroup` take each other into account when determining their width (for all but scatter) and position. Traces with _different_ `alignmentgroup` will not influence each other's width or position in any way.\r\n- Within one `alignmentgroup`, the available width is divided up according to the number of distinct `offsetgroup` values found among the traces in that `alignmentgroup`.\r\n  - All traces of any type (other than scatter) in the same `alignmentgroup` are given the same width.\r\n  - All traces of any type in the same `alignmentgroup` AND `offsetgroup` are given the same position.\r\n  - The available width is the minimum difference between any of the distinct position coordinates among all traces of any type in that `alignmentgroup`, reduced by the appropriate `gap` value.\r\n\r\n> I am a little bit unsure about the intended interaction between different trace types and their bar/scatter/box...modes. As far as I understand it, across traces we have the implicit behavior of \"overlay\" (with the exception of bars and histograms, because histograms also use barmode). Is this correct?\r\n\r\nThe default for `scattermode`, `boxmode`, and `violinmode` is `overlay` - and currently in that case all of this grouping is ignored, you need to explicitly set them to `group` for any of this to matter. I'm not sure that's the _right_ behavior, particularly given your goal here of allowing stacking and grouping simultaneously for bars, but I think it's OK to leave as is for those three types since they only have two `mode` values (`overlay` and `group`) and in `group` mode you can recover `overlay` behavior for an individual trace by giving it a unique `alignmentgroup`. If you don't provide any `offsetgroup` values it makes the most sense to put one trace of each type into each implicit `offsetgroup`, rather than making a new `offsetgroup` for each trace regardless of type, because typically different trace types are used to show different information about the same underlying objects. I would also say that no trace with a missing `offsetgroup` or `alignmentgroup` should be implicitly given the same value as an explicitly-provided `offsetgroup` or `alignmentgroup`.\r\n\r\n> How should alignmentgroup work exactly? The description in the documentation wasn't clear to me.\r\n> And should alignmentgroups only matter among traces of the same type? And should alignmentgroups only matter among traces of the same type? I was experimenting with bars and boxplots in this codepen and saw some interaction. Boxplots become invisible when a bar shares its alignmentgroup:\r\nhttps://codepen.io/toffi-fee/pen/zYVaKrB\r\n\r\nBoth of those look wrong to me based on the rules above:\r\n\r\nClearly something is wrong if the boxes in the same `alignmentgroup` as the bar disappear. But it's also wrong if the bar doesn't have a consistent width with the boxes, and if no `offsetgroup`s are provided, the bar trace should be aligned with the first box trace. If I take your codepen, put everything into the same `alignmentgroup`, and provide all traces with explicit `offsetgroup`s, the bar matching the first box trace, I get what I consider correct behavior (with the exception that the bar and box widths and alignment are a little off - this is bug #7133 again - because the default `boxgap` is `0.3` whereas the default `bargap` is 0.2). https://codepen.io/alexcjohnson/pen/xxozBJb?editors=0010\r\n<img width=\"426\" alt=\"Screenshot 2024-08-27 at 11 22 58\" src=\"https://github.com/user-attachments/assets/4b84cd5a-24d2-4ff8-8cef-6a34279c33e6\">\r\n\r\nExplicitly setting `boxgap=0.2` it looks exactly correct:\r\n<img width=\"439\" alt=\"Screenshot 2024-08-27 at 11 23 33\" src=\"https://github.com/user-attachments/assets/c3eb598f-7c26-4af4-804e-c2d454466a52\">\r\n\r\nAlso, clearly something is wrong if boxes with different `alignmentgroup` influence each other's position and width - as is the case in your codepen since the third box trace is in `alignmentgroup=\"2\"` whereas the other two are in `alignmentgroup=\"1\"`. Again, providing explicit `offsetgroup`s makes this look correct to me, in that the last box trace takes up the whole width because it's the only one in its `alignmentgroup`, and the other three split the width evenly because they're all in the same `alignmentgroup` with different `offsetgroup` (again, except for #7133) - so I think the root bug here is just how we deal with missing `offsetgroup`s. https://codepen.io/alexcjohnson/pen/MWMXxxR?editors=0010\r\n<img width=\"426\" alt=\"Screenshot 2024-08-27 at 11 31 29\" src=\"https://github.com/user-attachments/assets/8c557720-f162-480c-8abd-579564d1e4b4\">\r\nThis last one is what I think your codepen, exactly as it's written right now, should look like if we fixed this bug.",
    "created_at": "2024-08-27T15:39:08Z",
    "html_url": "https://github.com/plotly/plotly.js/pull/7009#issuecomment-2312907403",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/7009",
    "updated_at": "2024-08-28T12:12:12Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "@my-tien yes, that’s all correct, and thank you for catching my error, I will fix it above. ",
    "created_at": "2024-08-28T12:11:13Z",
    "html_url": "https://github.com/plotly/plotly.js/pull/7009#issuecomment-2315154289",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/7009",
    "updated_at": "2024-08-28T12:11:13Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "Ah, I missed that @drderiv reworked this in line with my suggestion - thank you! This looks great. I haven't tested it, but assuming it works as intended I'm quite happy to accept this.\r\n\r\nI suspect adding a programmatic test of this will be tough - and the change is only in the non-default setting anyway, so manual testing may be the best way to handle this one.",
    "created_at": "2024-08-22T13:27:57Z",
    "html_url": "https://github.com/plotly/plotly.js/pull/6682#issuecomment-2304676482",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/6682",
    "updated_at": "2024-08-22T13:27:57Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "@archmoj don’t worry about my contributions, I just kicked it off but the vast majority of the work is from you guys - do whatever gets the PR done quickest 😎 ",
    "created_at": "2024-08-20T02:41:21Z",
    "html_url": "https://github.com/plotly/plotly.js/pull/7120#issuecomment-2297856195",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/7120",
    "updated_at": "2024-08-20T02:41:21Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "Given that we can support users back to npm v7 (older node 16 versions) I think it's reasonable to make this switch now and not consider it a breaking change. It'll require _contributors_ to be on later node/npm versions at least if they're touching dependencies, but that's fine, we've never considered contributor requirement changes as breaking. Also I'll note we already describe later node/npm as a requirement for custom bundling:\r\n\r\nhttps://github.com/plotly/plotly.js/blob/74dedd4888748083da45cdc0548dafaae9784bcd/CUSTOM_BUNDLE.md?plain=1#L4-L7",
    "created_at": "2024-08-14T14:48:47Z",
    "html_url": "https://github.com/plotly/plotly.js/pull/7099#issuecomment-2289027446",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/7099",
    "updated_at": "2024-08-14T14:48:47Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "There are two separate issues here.\r\n\r\nThe original one (2022, GL-specific on Apple silicon) looks like a variant of https://github.com/plotly/plotly.js/issues/6820 so may have been fixed by https://github.com/plotly/plotly.js/pull/6830, we'd need to test this on Apple silicon (which would be much easier if we had a codepen than a repo that needs cloning and building)\r\n\r\nThe newer one (2024, not dependent on GL or Apple silicon) looks to me like it's an unpleasant interaction between axis automargin and scroll zoom. I see it happening when the length of the longest y-axis tick label changes, and this is what triggers automargin to change. I don't think the solution is to call `dragTail` immediately, that'll seriously degrade performance for plots with more data. Really what we want, I think, is to somehow prevent automargin from running until the `redrawTimer` function finally runs after you're done scrolling.",
    "created_at": "2024-08-09T21:58:45Z",
    "html_url": "https://github.com/plotly/plotly.js/issues/6235#issuecomment-2278805433",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/6235",
    "updated_at": "2024-08-09T21:58:45Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "No, not the expected behavior... but if I update the plotly.js version in that codepen to the latest 2.34.0 it seems like this was fixed at some point.",
    "created_at": "2024-08-09T21:34:03Z",
    "html_url": "https://github.com/plotly/plotly.js/issues/6693#issuecomment-2278784194",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/6693",
    "updated_at": "2024-08-09T21:34:03Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "I don’t know all the implications of what’s being proposed here, but the primary goal is to ensure we always draw the SVG elements in a space where 1 unit is 1 pixel exactly. If we lose that, lots of things will start to look terrible, like lines for which we’ve disabled antialiasing via crisp rendering occasionally disappearing if they end up sub-pixel in width.\r\n\r\nIf we can accomplish that goal in a different way that’s more responsive then great! The current system was created long ago when we needed to support a lot of browsers that are no longer relevant today, so I’m sure there are modern features we aren’t taking advantage of. Any change we make will need very thorough enumeration of cases we currently support (there are more than you might think!), to ensure they still behave the same. ",
    "created_at": "2024-07-26T21:33:09Z",
    "html_url": "https://github.com/plotly/plotly.js/issues/7064#issuecomment-2253536646",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/7064",
    "updated_at": "2024-07-26T21:33:09Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "I wonder if it would be more intuitive to specify this as something like `ticklabeloffset: {x: 20, y: 10}` ie a number of pixels to move the labels in the x direction (positive to the right, negative to the left) and the y direction (positive up, negative down)?\r\n\r\n`standoff` is clear to me that it refers to moving orthogonal to the axis and away from the line or tick marks. But `runoff` I find confusing, and I can't think of another name that clearly refers to motion in that direction, which is what led me to suggest changing both of them.",
    "created_at": "2024-06-26T14:00:41Z",
    "html_url": "https://github.com/plotly/plotly.js/pull/7006#issuecomment-2191787982",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/7006",
    "updated_at": "2024-06-26T14:00:41Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "Ok great, just wanted to confirm that this is truly the intent. So yes, let’s keep the behavior as implemented.\r\n\r\nI’d still like to discuss the name, as to me `drawminorticklabel` implies adding extra labels rather than moving the already expected labels. It’s also a bit long: @etpinard had what I think is a great rule that no attribute name should concatenate more than three words and this is four. \r\n\r\nWhat about `minor.shiftlabels`? ie put it inside the `minor` container since it only applies when there are minor ticks, but we don’t label minor ticks so it’s clear the shift applies to major tick labels. ",
    "created_at": "2024-06-26T12:20:42Z",
    "html_url": "https://github.com/plotly/plotly.js/pull/7036#issuecomment-2191551597",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/7036",
    "updated_at": "2024-06-26T12:20:42Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "I see, that’s reasonable. And in this case moving all the tick labels to Q2 is the desired behavior, not just a side effect? Ie would you ideally prefer Q1 to be labeled on all the earlier years (and possibly also 2024) and just label Q2 on 2024, or is what you’ve drawn with every Q2 labeled in fact the goal?",
    "created_at": "2024-06-26T11:47:20Z",
    "html_url": "https://github.com/plotly/plotly.js/pull/7036#issuecomment-2191492260",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/7036",
    "updated_at": "2024-06-26T11:47:20Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "I thought based on the attribute name that this would be about labeling ALL the minor ticks, but it’s just about shifting the label away from the major tick. Is there a use case other than period ticks, where the label is already shifted but now you want to shift it the other way? If that’s the only purpose I’d suggest making this specific to period ticks, something like `labelminorperiod=“first”|”last”`?",
    "created_at": "2024-06-26T04:45:09Z",
    "html_url": "https://github.com/plotly/plotly.js/pull/7036#issuecomment-2190693234",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/7036",
    "updated_at": "2024-06-26T04:45:09Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "Is this already solved by the new `font.shadow` attributes? https://github.com/plotly/plotly.js/pull/6983 ?",
    "created_at": "2024-06-10T14:47:01Z",
    "html_url": "https://github.com/plotly/plotly.js/issues/1597#issuecomment-2158568267",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/1597",
    "updated_at": "2024-06-10T14:47:01Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "To my knowledge foreignObject does not work outside browsers - so this would break SVG export",
    "created_at": "2024-06-05T19:14:18Z",
    "html_url": "https://github.com/plotly/plotly.js/issues/382#issuecomment-2150779504",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/382",
    "updated_at": "2024-06-05T19:14:18Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "To me it feels a little limiting to put these attributes on the axes rather than in each shape. What if you want a rectangle outlining one bar (or bar group), a line going from the middle of one category to the middle of another, and a circle around a single scatter point?\r\n\r\nThe name is also awfully long. What about just `x0shift`?",
    "created_at": "2024-06-04T14:36:20Z",
    "html_url": "https://github.com/plotly/plotly.js/pull/7010#issuecomment-2147702403",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/7010",
    "updated_at": "2024-06-04T14:36:20Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "> I think it should go inside `layout.title` object instead of `layout`. It reminds of when we added `minor` ticks in #6166.\r\n> \r\n> That would also allow adding multiple titles and subtitles later on.\r\n\r\nI think that’s right. Also makes it clear that it inherits positioning from the title (presumably with optional overrides to at least the spacing relative to the main title) and it can inherit the main title font (but smaller, and remove bold if you bolder the main font?)",
    "created_at": "2024-05-17T03:02:11Z",
    "html_url": "https://github.com/plotly/plotly.js/issues/6856#issuecomment-2116543146",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/6856",
    "updated_at": "2024-05-17T03:02:11Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "Is `diagonal` not already enough of a container? Everything in there, including `type`, is trace attributes for what you show on the diagonal, with the caveat that the one existing attribute there, `visible`, also controls whether we even create that subplot, but that seems OK to me. ",
    "created_at": "2024-05-08T21:37:29Z",
    "html_url": "https://github.com/plotly/plotly.js/issues/6991#issuecomment-2101522872",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/6991",
    "updated_at": "2024-05-08T21:37:29Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "@archmoj very cool!\r\n\r\nI'm not totally set on either way, but a couple other arguments in favor of making this a subtype of `treemap`:\r\n- The name \"treemap\" itself doesn't say anything about how the regions are packed, so this could just be a different packing type (and we could add others, like [circle packing](https://www.google.com/search?q=circle+packing+treemap&sca_esv=a69b8a5a4d8be7ee&sca_upv=1&udm=2&biw=1440&bih=692&ei=nEkyZt-1N7SsptQPss2iwA0&ved=0ahUKEwjf8_mdzeyFAxU0lokEHbKmCNgQ4dUDCBE&uact=5&oq=circle+packing+treemap&gs_lp=Egxnd3Mtd2l6LXNlcnAiFmNpcmNsZSBwYWNraW5nIHRyZWVtYXBI6ilQwQhYlChwBHgAkAEBmAG-AaAB4wyqAQQxNi4zuAEDyAEA-AEBmAIQoAKCCMICChAAGIAEGEMYigXCAgcQABiABBgYwgIIEAAYgAQYsQPCAg4QABiABBixAxiDARiKBcICBRAAGIAEwgILEAAYgAQYsQMYgwGYAwCIBgGSBwQxNS4xoAeEPw&sclient=gws-wiz-serp#vhid=Cb85qwrJCiwx8M&vssid=mosaic))\r\n- We have other uses of the voronoi / delaunay algorithm in plotly.js today (eg `delaunayaxis` in `mesh3d`) and eventually we should support this in more places - for example I'd love to make contour maps for arbitrary xyz triplet data using delaunay triangulation. Calling this \"the voronoi trace\" implies that this is the only place we're using that algorithm.\r\n\r\nAnd to @emilykl's comment \"The multiple levels of hierarchy sort of blend together visually\" - I agree, with the parents only visible in the gaps between children, I find it hard to really see the hierarchy. One option would be to expand the parent nodes so that they actually surround their children, similar to how `treemap` works. I know this breaks the exact correspondence between area and data value, but that was true for treemap as well and we chose clarity over fidelity for the same reason. Or perhaps for voronoi packing we don't show the parent nodes at all, we just decrease the line width as the nesting level increases? That's the approach [I see most often elsewhere](https://www.google.com/search?sca_esv=a69b8a5a4d8be7ee&sca_upv=1&q=voronoi+treemap&uds=AMwkrPt8eR8Q1gfQGx0g1guoVKhM8EQYLMwTJWdzQc0V-wprfDeBcAgeyEqWmUXOZUTbamPVCjL16FyQK3IIcGSvQG5NMDmgUyfyt-1pjsKpP98vaZYWEo5b8-TXXJsj8Ucq-3RuQ3Ra1xze4HDA0ZEByPET-6NvFWoJRcLWblTlW1qn_u7ZG2mkcvgRxDWjku1yI_ZIiYkeLSxJYl_MN3wrAjp2Iqe5GsQfNLP3ot8zna_HmgcSngvZrxCgv68q8iIxi9O37TrSa2zohBftNqb5Q3UFpDIHmwTjKyb0DUthWqvm7TrOl4pnzIxYNdaCgL3aPJQDoFX6&udm=2&prmd=ivsnmbt&sa=X&ved=2ahUKEwiKuOyUz-yFAxVTtokEHao0BcYQtKgLegQIFRAB&cshid=1714572206598499&biw=1440&bih=692&dpr=2), and I think it makes sense. As a side-effect though, since we don't have a place to display text for the parent nodes I think the proportions need to be relative to the entire data set rather than each parent. In the image in @emilykl's comment https://github.com/plotly/plotly.js/pull/6987#issuecomment-2083823697 there are nine 33% and eight 50% labels but unless we find a way to label the intermediate parents and THEIR proportions, all those numbers should sum to 100% rather than summing to 100% within each subset.",
    "created_at": "2024-05-01T14:14:18Z",
    "html_url": "https://github.com/plotly/plotly.js/pull/6987#issuecomment-2088526164",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/6987",
    "updated_at": "2024-05-01T14:14:18Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "By ancient I meant my response came 3 years after the question, so was probably not much use to the original poster. But that’s correct, we do not intend to implement this. ",
    "created_at": "2024-04-24T01:58:08Z",
    "html_url": "https://github.com/plotly/plotly.js/issues/4840#issuecomment-2073853489",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/4840",
    "updated_at": "2024-04-24T01:58:08Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "How about `layout.hoversubplots` with values (eventually, wouldn’t need to implement all of these now) `single` (just the axis pair of the primary point), `overlaying` (all subplots using the main axis and occupying the same space), `axis` (also include stacked subplots using the same axis) and `matching` (also include other axes matching the main axis)",
    "created_at": "2024-04-06T16:13:39Z",
    "html_url": "https://github.com/plotly/plotly.js/pull/6947#issuecomment-2041128431",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/6947",
    "updated_at": "2024-04-06T16:13:39Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "@Sharpz7 good point - TBH I’ve forgotten the rationale behind the original two modes and their names, but if we were designing the API today, the new version would probably have been called `absolute`.  But we have a bit of a conundrum since that’s already taken. \r\n\r\n@archmoj i haven’t played with this much, but if I’m understanding it correctly, `absolute` scales all the sizes up or down so they don’t intersect, leaving the ratios between different sized cones unchanged. Whereas `scaled` makes the largest cone the same size as `absolute` but the smaller ones may be larger than they would have been, so that you can still see their directions even if their real magnitudes are much smaller, is that right?\r\n\r\nIf I have that right, I might suggest `raw` as the name for the new one. That’s about the only word I can think of that implies “even less processed than absolute”",
    "created_at": "2024-03-27T23:09:31Z",
    "html_url": "https://github.com/plotly/plotly.js/pull/6938#issuecomment-2024130917",
    "issue_url": "https://api.github.com/repos/plotly/plotly.js/issues/6938",
    "updated_at": "2024-03-27T23:09:31Z",
    "user": {
      "login": "alexcjohnson"
    }
  },
  {
    "body": "> Let's add some `Plotly.react` tests\r\n\r\nAbsolutely. Also perhaps a `Plotly.restyle` test doing the same.\r\n\r\nAnd a question: does `zindex` affect the stack order of bar traces or stacked area traces? Should it?\r\n\r\n> In terms of naming the other alternative is zorder as noted in https://github.com/plotly/plotly.py/issues/2345 known to matplotlib users.\r\n\r\nI think the only other places we use `order` in an attribute name it refers to \"which algorithm should we use to set the order\" - `axis.categoryorder` or `legend.traceorder`; whereas `index` is used only in one rather obscure place (`parcats.dimensions[i].displayindex`) in the sense we're using here \"a number that alters where this item appears in the order\". So I'd call that a very weak vote in favor of `zindex` but if anyone feels strongly in favor of `zorder` that's