There are many layers of consideration here, which is that adding active states only applies to items that appear within the primary menu nav. If one visits a page not within those items hierarchy (which is common) then there is no way to indicate an active state, thus creating either no active state, or trying to pick one that might match. This is poor UX on both fronts.
If a site has every page present within the primary menu nav then it can be more readily easy to add active states because now they have appropriate page existence and structure parity. This is not always the case, and as Vocabulary is a design system that should have shared behaviors across its implementations having this behavior on one site and not on another may create non-cohesive conventions that might be perceived as being broken, and again results in poor UX.
Any explorations here that would be successful would need to account for the two above situations. It is generally best practice to avoid active states unless they add helpful UX that can provide appropriate coverage across page existence and structure. It is unclear if that is possible to do within Vocabulary given the varying Information Architectures of creativecommons' sites.
Alternatives
Do not provide visual active state to the primary menu nav, but do not the reasoning behind this within documentation.
Additional Context
Active states tend to work best when they can provide full coverage and be consistent, such as with a section based menu in a sidebar for a longer page. This works well because the sidebar is tied to that page's structure and therefore the items would provide full coverage of the sections in a useful way. This is no always the case with a primary nav menu on a site with a larger subset of pages.
Implementation
[x] I would be interested in implementing this feature.
Problem
A recurring note that has been documented in several Issues, most recently:
Description
There are many layers of consideration here, which is that adding active states only applies to items that appear within the
primary menu nav. If one visits a page not within those items hierarchy (which is common) then there is no way to indicate an active state, thus creating either no active state, or trying to pick one that might match. This is poor UX on both fronts.If a site has every page present within the
primary menu navthen it can be more readily easy to add active states because now they have appropriate page existence and structure parity. This is not always the case, and as Vocabulary is a design system that should have shared behaviors across its implementations having this behavior on one site and not on another may create non-cohesive conventions that might be perceived as being broken, and again results in poor UX.Any explorations here that would be successful would need to account for the two above situations. It is generally best practice to avoid active states unless they add helpful UX that can provide appropriate coverage across page existence and structure. It is unclear if that is possible to do within Vocabulary given the varying Information Architectures of creativecommons' sites.
Alternatives
Do not provide visual
activestate to theprimary menu nav, but do not the reasoning behind this within documentation.Additional Context
Active states tend to work best when they can provide full coverage and be consistent, such as with a section based menu in a sidebar for a longer page. This works well because the sidebar is tied to that page's structure and therefore the items would provide full coverage of the sections in a useful way. This is no always the case with a primary nav menu on a site with a larger subset of pages.
Implementation