Underline is not a Decoration

[janwirth]

Font.underline is not a decoration even though it is not modifying layout.
https://ellie-app.com/6Y25dmJQWKJa1

Expected behavior
It should compile (change the type of underline to Font.underline : Attribute Never Never
OR
Add to the documentation why this is NOT a decoration.

Versions
elm-ui@1.1.5

[janwirth]

Here is a codepen comparing dimensions of text with and without underline:
https://codepen.io/franzskuffka/pen/zYYNrBZ?editors=1010

Check out the console logs.

[rlefevre]

Unfortunately it seems this can impact the layout.

For example I arbitrary added font-size: 34px to your styles and the widths now differ by one with Firefox 70.0:

console.log(withU.width == withoutU.width,withU.height == withoutU.height)
console.log(withU.width, withoutU.width, withU.height, withoutU.height)

false true
85 84 41 41

Maybe this is a bug in the browser, I don't know.

[janwirth]

@rlefevre can u share the updated codepen?

[janwirth]

With font-size: 34px I get 86.90000915527344 86.89999389648438 34.5 34.5 false true

[rlefevre]

I don't have an account, sorry. It is maybe specific to Firefox 70.
Your example now returns

false true
75 76 39 39

for me with FF 70.

PS: I used another computer with another default font previously, hence the different numbers.

[janwirth]

You do not need an account. I use FF 70.0.1

[janwirth]

Which OS? Your numbers are so different from mine.
https://codepen.io/franzskuffka/pen/zYYNrBZ - I updated the font-family.

[rlefevre]

Ubuntu 18.04. With Arial it's the same width.

[rlefevre]

I cannot save:
https://blog.codepen.io/2019/08/06/anonymous-pen-save-option-removed/

Could you try font-family 'Ubuntu', sans-serif with adding the following to head (HTML settings):

<link href="https://fonts.googleapis.com/css?family=Ubuntu&display=swap" rel="stylesheet"> 

[ebrightfield]

Is there currently a workaround for this and similar issues (e.g. putting Font.bold in a mouseOver)?

[janwirth]

Not that I'm aware off - you'll have to use a CSS class and a style tag at least.

[lydell]

Interesting discussion from Slack:

lydell
Can anyone make a demo where text-decoration: underline; visually affects layout? I’ve heard it’s the reason you can’t have underline on hover in elm-ui, but I can’t think of a way to make it cause issues.

sethro
so, why exactly can't you have underline on hover? I just came here to ask this specific question. Is there a reference for this?

dmy
Apart from the 1 pixel change with some browsers noted in the bug, I did not find anything else either. Font.strike is most likely similar too.

lydell
Is it possible to see the difference with your eye, or is it just measureable with DOM APIs?

dmy
1 pixel is visible if this misaligns borders for example. But the 1 pixel change might be a browser bug, I'm not sure. I doubt a specification forbids it though.

lydell
Can you make a demo of a misaligned border?

dmy
It seems you're right. I tried a little, and even if DOM API returns sometimes some different values with getBoundingBox() , I'm not able to make a visible example.

[janwirth]

@lydell thanks for sharing.
FYI @dmy on slack is @rlefevre :)

[lydell]

Tip from @rlefevre – fake it with a border: https://ellie-app.com/7fFKkBZH9Pra1

Note, however, that it is not possible (?) to make an underline that skips descenders, like text-decoration: underline; does by default these days (at least in Chrome and Firefox):

(See also: https://developer.mozilla.org/en-US/docs/Web/CSS/text-decoration-skip-ink)

The border approach also does not work for line-wrapped text.

[lydell]

More interesting discussion from Slack:

spell
hello! I would like to Font.strike on mouseOver, however looks like Font.strike isn't a Decoration , but why so?

dmy
I think there are technical constraints due to the use of pseudo classes.

lydell

I think there are technical constraints due to the use of pseudo classes.

What does this mean?

dmy

mgriffith
Side note, if we figure out a way to do this, we could potentially use it to avoid using :hover or :focused pseudo classes in CSS, which would make mouseOver able to take whatever attributes people want.
From a thread in #elm-ui | May 12th | View reply

lydell
Sorry, I’m not following – in turn, what does that mean? I thought the point of mouseOver was to not allow you to change the layout on hover (since it results in a jumpy experience as you move the mouse). How does replacing :hover with some other implementation allow us to use any attributes?

dmy
What this means is that it is due to a technical limitation, not preventing modifying the layout (which is actually not modified anyway by underline or strike).

lydell
I’ve never heard of there being technical limitations with :hover in CSS. Is that what you mean? Or is it some other technical limitation you’re talking about?

dmy
The limitation is not in CSS, but in the way elm-ui use them without a way (currently) to identify an element uniquely.

lydell
But if color can be changed on hover, why can’t text-decoration?

dmy
Right, for underline and strike, it's likely possible, the limitation is to allow any attribute:

mgriffith
It’s relying on pseudo classes. Allowing arbitrary attributes would require elm-ui to maintain it’s own state, right now we’re banking on browser-maintained state. Font.underline was an oversight.
From a thread in #elm-ui | May 5th | View reply

lydell
Thanks, my brain was locked thinking about text-decoration since this thread started out asking about Font.strike. Any attribute that just maps directly to a CSS declaration should work fine in mouseOver, then. Attributes requiring extra divs and stuff won’t.

dmy
I think so. So the correct answer to @spell is likely: for Font.strike and Font.underline, there isn't a reason except an oversight, and it will likely be added in the next major version. For more complex attributes that cannot be represented with CSS properties, this is not possible at the moment, but some trick maybe be found later.

Jan Wirth
Thank you for sharing this info. Does that mean that this issue is misleading?

dmy
The discussion about the impact on layout inside the issue is likely off topic indeed. I was missing some information at the time.