Calendar-based Sprint lengths are the norm. The Scrum Guide does not explicitly prohibit capacity-based durations, but says:
Sprints have consistent durations throughout a development effort.
Scrum employs an iterative, incremental approach to optimize predictability and control risk.
Sprints enable predictability by ensuring inspection and adaptation of progress toward a Sprint Goal at least every calendar month.
Calendar-based predictability is strongly implied, but not specifically called out as a framework requirement. However, any attempt to use capacity-based Sprint lengths with variable start/stop scheduling runs the risk of violating key objectives for predictability, reliable cadence, and long-term forecasting.
Predictable Cadence Trumps Fixed Capacity
A key goal for Scrum (and other agile methodologies) is to create organizational confidence through predictability. This includes predictability in event scheduling, as well as long-term predictability about when increments of work will be delivered and inspected. Calendar-based planning is also fundamental to predictable release planning in Scrum!
There's no rule that says you can't maintain a 10-day cadence rather than a two calendar-week cadence, but in pragmatic terms this results in less predictability for standard events. Is the Sprint Review on Thursday this week, or Friday? Or possibly next Monday? And how can stakeholders reliably clear their calendars for a repeating event for the next six months in advance, especially when the dates are likely to change?
In Scrum, as with many agile frameworks, you are optimizing for a predictable cadence, and not for a fixed capacity each Sprint. Team size changes Sprint-to-Sprint as people get sick, take vacation, or join/leave the team. If you take the fixed-capacity approach, you will find yourself forever moving the core Scrum events around in a vain attempt to maintain a stable capacity.
Instead, you should strive to maintain a predictable cadence with variable capacity. This gives the team and stakeholders confidence that the time box is stable, and that the framework events will happen on a reliable schedule even when there are scope or capacity changes.
That doesn't mean you can't shift things for a major holiday or other business reasons. But in practice, you should handle such things by shortening the Sprint to reduce capacity. This makes the reduced capacity visible, creates process transparency, and pays the technical debt of reduced capacity right now rather than hiding it within a variable schedule or "kicking the can down the road."