Link: display blue outline on focus

[NazimHAli]

This change: (check at least one)

• Adds a new feature
• Fixes a bug
• Improves maintainability
• Improves documentation
• Is a release activity

Is this a breaking change? (check one)

• Yes
• No

Is the: (complete all)

• Title of this pull request clear, concise, and indicative of the issue number it addresses, if any?
• Test suite(s) passing?
• Code coverage maximal?
• Changeset added?
• Component status page up to date?

What does this change address?
Resolves accessibility/display issue #485

Blue outline not rendered in Chrome when focusing on a link with a nested heading.

How does this change work?
Sets the display value to inline-block so that it renders the layout and elements dimensions (margin/padding) are applied properly.

[changeset-bot]

🦋 Changeset detected

Latest commit: 3a75d66

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@ithaka/pharos	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[github-actions]

size-limit report 📦

Path	Size
packages/pharos/lib/index.js	47.84 KB (+0.02% 🔺)

[chrisjbrown]

nice. works for me 👍

[daneah]

@NazimHAli can you think of ways that links going from inline to inline-block could break existing usages?

[NazimHAli]

@NazimHAli can you think of ways that links going from inline to inline-block could break existing usages?

I was thinking about this and tried to find examples to determine if this was a breaking change. One change that I can think of are possibly dimensions. With inline, the default width of the link element is set to auto, but with inline-block, it will be set to the width of the elements content.

The current inline:

With inline-block:

[daneah]

@NazimHAli That's a good one to think about. What I'm interpreting there is that headings that are linked will have their default block value forced to inline-block, which I don't think is right for headings. Is that accurate?

[NazimHAli]

@NazimHAli That's a good one to think about. What I'm interpreting there is that headings that are linked will have their default block value forced to inline-block, which I don't think is right for headings. Is that accurate?

It's for the link element, not the header. Another idea is setting it only for links with nested header. It could be the case where the layout isn't rendered instead of all links.

[daneah]

@NazimHAli I understand, I was wondering if the heading gets wrapped in the link which affects its display status in turn.

[NazimHAli]

@daneah I ran into another oddity, replacing outline style solid with auto on 243

pharos/packages/pharos/src/utils/scss/_mixins.scss

Lines 241 to 246 in e50a0f5

	@mixin interactive-focus {
	&:focus {
	outline: 2px solid var(--pharos-color-focus);
	outline-offset: 2px;
	}
	}

Renders a different outline, makes me wonder if there's some other styling issue:

[chrisjbrown]

What was the problem with inline-block for the link element? that looks correct for me with pharos-heading div span just text slotted in

[daneah]

@chrisjbrown a native link around a native heading behaves differently, keeping the full block nature of the heading:

I am not inclined to deviate from this as it will not match people's general expectations.

[chrisjbrown]

@chrisjbrown a native link around a native heading behaves differently, keeping the full block nature of the heading:
I am not inclined to deviate from this as it will not match people's general expectations.

🤔 i see

[chrisjbrown]

playing around here.
https://stackblitz.com/edit/pharos-repro-sandbox-4zb9ny?file=src/App.vue

still not sure why pharos doesn't "just work" as is 😕

[NazimHAli]

@daneah @chrisjbrown any reason we shouldn't set the default display for#link-element to block instead of inline-block here?

Another option is to create a variant for header links and scope the CSS for it only in this case.

[daneah]

@NazimHAli I think setting links to display: block is even more likely to significantly break (almost all?) current usage, as links are typically display: inline. Unless you're saying the host element will still be display: inline?

[NazimHAli]

Unless you're saying the host element will still be display: inline?

Yes, that's what I mean. Keep :host as is, and update #link-element to have display: block.

[NazimHAli]

@daneah setting just the element as a block did not work as I'd hoped, it still affects links in general. The only scalable solutions I can think of right now is to create a variant that sets the display for this use case.