44

Here's a thread to catalog any minor DOM updates we do throughout 2023 just to give folks in the user community a bit of a heads up and an official source of documentation around any DOM changes.

fellow hackers

This is a "best effort" source and we will try to note any changes here that will impact user scripts as best we can. Unfortunately, we can't promise that we'll catch everything that might break your scripts.

If you're a script maintainer or heavy user of scripts, we encourage you follow the answer, so you get notifications of changes.

Improve this question
3
  • 2
    Thanks. meta.stackexchange.com/questions/331476/… ..... ?
    – 4b0
    Feb 4 at 4:19
  • 7
    As one of the userscript developers I'd like to say - thank you for making good on the promise of making the lives of script devs easier! Having the changes to the DOM catalogued is a very nice step up from us having to figure out what changed when scripts suddenly stop working as intended.
    – Oleg Valter is with Ukraine
    Feb 4 at 7:54
  • 2
    This is amazing outreach; thank you! Can this also be updated when Stacks.css changes are made? E.g. when a selector is replaced with a more specific one?
    – TylerH
    Feb 8 at 16:48

1 Answer 1

Reset to default
30

DOM Changelog

Date Change
2023‑01‑09 Update .comment-up-undo to .js-comment-up-undo to be inline with our js-* naming standard
2023-02-03 Update .comment-up to .js-comment-up to be inline with our js-* naming standard
2023-02-09 Removed Svg.* icons from global window object.

If you need icons, please import @stackoverflow/stacks-icons, which can also be done via unkpg.

Then Svg.Eye → StacksIcons.Icons.IconEye
Improve this answer
11
  • 1
    Out of curiosity, why would css classes start with js-?
    – Stephen Ostermiller on Strike
    Feb 3 at 20:32
  • 8
    @StephenOstermiller stackoverflow.design/product/guidelines/javascript/…
    – Kyle Pollard StaffMod
    Feb 3 at 20:33
  • 7
    We use that to distinguish that the only layer that should care about this class is JS to add event listeners / dom manipulation or something. This makes it easier to reason about changing the styles of something like .comment-active, knowing changing the class won't break any JavaScript.
    – KyleMit StaffMod
    Feb 3 at 20:33
  • 6
    Just a word of advice, I'd highly recommend publishing advance notice when doing so, which can most easily be done when pushing the change into source control before the build deploys to the public sites, but preferably a few days' notice. This way, script authors can update their scripts so there's no downtime for script users. Some user scripts are important for content curation so having them be broken for 6-8 days while waiting for the script author to update it can be annoying. (A similar thing is already done today for translations.)
    – Sonic the Anonymous Hedgehog
    Feb 3 at 20:38
  • 6
    I share the sentiment and goal @SonictheAnonymousHedgehog, and hopefully we can provide some degree of lead time, but PRs sitting in the queue for 6-8 days is gonna really hurt in a 2 wk sprint cycle. Most of these are updated under the "clean beach principle" while working on a related ticket.
    – KyleMit StaffMod
    Feb 3 at 21:44
  • @StephenOstermiller to add to what's been said above, it's a well-known naming convention for CSS classes that are used by JS logic to match elements rather than to style things.
    – Oleg Valter is with Ukraine
    Feb 4 at 7:51
  • 2
    It seems that somple properties of the global Svg object are now not exposed. Is this intentional?
    – double-beep
    Feb 9 at 18:05
  • @double-beep, we recently did swap out our svg icons to point to StackExchange/Stacks-Icons, but I'm not sure that impacted the windows.Svg object got touched (It's possible though). We still have some icons explicitly wrapped as properties. Do you know what you're missing?
    – KyleMit StaffMod
    Feb 9 at 18:31
  • 2
    @KyleMit the list used to be much longer (200+ icons). For example. Svg.Gear() and Svg.Eye() are missing.
    – double-beep
    Feb 9 at 19:02
  • 2
    @double-beep, ah, yeah, I see the PR - one previous to the one I was looking at. Looking into it. We refactored it to an imported method because our long term goal in is to not rely on global scope in scripts. But also want to see if we can produce an artifact on the global scope.
    – KyleMit StaffMod
    Feb 9 at 19:22
  • 2
    Hey @double-beep, had a quick discussion internally about this and we're not quite in easy "rollback" territory since this was a intentional move to refactor to an external icon package in order to not maintain the property list in two places - which always required two separate PRs to add icons. Added to the changelog with a workaround to use unkpg to get icons - which is the same package we're building from internally, so guaranteed to be the same. Thanks for pointing out and hopefully this helps
    – KyleMit StaffMod
    Feb 9 at 19:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .