Aggragated bug & misc tracking

[Rhaoma]

Hi again

Opening this issue to track various small implementation details inconsistent with the official specification, as well as other bugs, as discussed previously.
Comprehensive issues can be expanded to their own separate discussion if need be.

[Rhaoma]

Issues relating to the Navigation Rail @m3e/nav-rail

When nesting the optional FAB the elevation should be 0 per the spec.

When nested within another component, such as the navigation rail, the FAB's resting elevation should be level 0.

Set the elevation level with a ::slotted(m3-fab) selector.
It seems the FAB doesn't have a general css variable for the elevation level, only variant specific such as: --m3e-primary-container-fab-container-elevation.
We would have to individually set: normal, focused, disabled, pressed and hovered levels for each variant of the FAB. Thats 7x5 css variables (we could also set --md-sys-elevation-level3 but that feels very wrong).
I believe this is applies to many other components in the library (please correct me if wrong)
Why don't we have general unset fallback variables for each state applicable to all variants, such as --m3e-fab-elevation, --m3e-fab-hover-elevation etc...
It would be easy to style the entirety of the component, but still allows users to specifically target a variant if needed.

[Rhaoma]

Issues relating to the Navigation Rail @m3e/nav-rail

It would be nice to implement modality of the navigation rail as per the spec for smaller window sizes.
On a similar note, what about transitions between collapsed and expanded states?
I don't think it has priority, but just wanted your thoughts on it.

Another question entirely. I'm not familiar with TypeScript and have newer written anything in it, neither do i use Git/Github, but if I wanted to contribute directly instead if opening issues, what would be the easiest way to get started?

[Rhaoma]

Issues relating to the Icon Button @m3e/icon-button

I believe that the toggleable outlined variant of the icon button should have no outline in it's selected state.
I think the spec is difficult to interpret.
As I read it, the Tokens & Specs section outlines design tokens for the outline color for the untoggleable and toggleable-selected states.
I interpret the omission of outline design tokens for the toggleable selected state as there being no outline.
This is congruent with the later state pictures under Outline button states -> Toggle and the Figma Library (see below)

[Rhaoma]

Issues relating to the Focus Ring @m3e/core

I have noticed that the focus indicator is crooked/uncentered around elements, e.g the icon button, at least on my screen. The official Material Web implementation does not suffer from this.

M3E demo:

Material Web demo:

The offset in M3E is determined by:

outline-offset: calc(var(--m3e-focus-ring-thickness, 0.1875rem) / var(--m3e-focus-ring-growth-factor, 2));

which with the default root font size of 16px shakes out to:

0,1875 x 16px = 3 px;

When dividing this by 2, we get the uneven alignment 1px at block- & inline-start, then 2px at the end

I can't find the official spec at https://m3.material.io (let me know), but the Figma Focus Indicator has an offset of 2px all round.
Applied to the demo page - M3E demo (fix applied):

We get the desired look.

General

Generally what is the rationale for utilizing rem in the fixed size spec?
I get that it it useful for certain parts of a component, but why not use fixed units for fixed values such as offsets, max.widths etc?

[Rhaoma]

Issues relating to the Split Button @m3e/split-button

Hovered and pressed state for the leading split button element, has the same corner radius. Thus i would expect when hovering and pressing the leading button to see no change in the radius. However there is a short instant when releasing the press, where the border radius seems to go to 0. See below video:

Recording.2026-02-24.000609.mp4

I am not 100% sure of the cause, but digging around it might be that the -resting and -pressed class is applied at the same time for a short instant.
I dug into the css and noticed border radius values for border-start-start-radius and border-end-start-radius akin to:

--_button-start-shape-pressed-morph: var(--_leading-button-shape, var(--md-sys-shape-corner-full, 624.9375rem));

Why use this hyper specific value? I believe this might be affecting the values of border-start-end-radius and border-end-end-radius. When setting the previous values to half the height, the following is achieved:

Recording.2026-02-24.001907.mp4

There is no flash of an unset border radius.

That said I do not understand the choice of 624.9375rem, so i might be overlooking something

[matraic]

Thanks for the detailed aggregation. Pulling all these together adds real value to the project.

[Rhaoma]

Issues relating to the Form/Text Fields @m3e/form-field

I believe the line-height should be inherit, rather than initial in the following selector:

::slotted(input), ::slotted(textarea), ::slotted(select) {
  outline: unset;
  border: unset;
  background-color: transparent;
  box-shadow: none;
  font-family: inherit;
  font-size: inherit;
  color: var(--_form-field-input-color, inherit);
  flex: 1 1 auto;
  min-width: 0px;
  padding: unset;
  line-height: initial;
  letter-spacing: inherit;
}

I also wonder why the outline variant originally has the following CSS:

:host([variant="outlined"]) .pseudo-label {
  ...
  margin-inline-end: 0.25rem;
  ...

Leading missing spacing at the end

I believe it should be a margin-inline afffecting both ends equally. Ideally:

:host([variant="outlined"]) .pseudo-label {
  margin-inline: 4px; //or 0.25rem

This brings focus to my previous question about the usage of variable rem units instead of px for fixed size measurements.
I don't necessarily see the point of them, when the spec to my knowledge doesn't shift measurements based on base font size.
I think it's a bigger discussion

Edit
This also ties into me previous comment about the uneven focus indicator, which I think is an important fix

[Rhaoma]

Issues relating to the Form/Text Fields @m3e/form-field

More of an open question, but i noticed that pressing the supporting-text e.g hint/error message, triggers the pressed state on the field:

20260227-1406-56.3727456.mp4

I don't reckon it is documented in the spec but I personally think it would be nicer to only trigger the pressed state, when actually clicking the input box.
I imagine its a PressedController registered at the root, so i imagine it could just be moved to the <div class="base"/>