oakstudios / mechanical-ragger Goto Github PK

window.getComputedStyle doesn't always return a pixel value, particularly when it evaluates to normal.

mechanical-ragger fails for this test case (since normal evaluates to NaN).

MDN suggests that the default is ~1.2, but chrome uses something closer to 1.16 🥴

normal

Depends on the user agent. Desktop browsers (including Firefox) use a default value of roughly 1.2, depending on the element's font-family.

— https://developer.mozilla.org/en-US/docs/Web/CSS/line-height#values

Either way, relying on all UAs to use a reliable default here feels risky, so maybe we should log a warning in the console and not try to render the exclusion if we can't figure out the line-height? and probably update the README to note this.

Any text I place within the <mechanical-ragger> element won't inherit the other styles on my site. For example:

<p><mechanical-ragger>
    This <a href="github.com">URL</a> won't be styled like my other links.
</mechanical-ragger></p>

As far as I understand it, mechanical-ragger creates an autonomous custom element, which won't inherit anything from other HTML elements. But I'd love to be able to integrate this tool's ragging with all my existing styles. Thanks!

should probably test a few uses of the module on every push:

• minimal react example
• minimal web component example
• web component auto-register example

just need to ensure they render, but maybe testing for the existence of the exclusion element would be useful? a visual diffing test might be ideal but maybe more trouble to set up than it's worth?

lh units might be helpful for a few different issues like #3 and #18, where browser differences in how they evaluate, report, and round line heights cause issues for us. we may get mileage out of:

1. overestimating the amount of lines that need to be rendered, then
2. generating exclusions that use lh units, which should mirror browser rendering

some nice-to-haves:
https://github.com/actions/create-release
https://github.com/actions/starter-workflows/blob/main/ci/npm-publish.yml

• #6

noted before, but this is borked

think an svg would actually be a good candidate here, because transitioning a circle's width property alongside vector-effect: non-scaling-stroke would feel a little more harmonious with the motif of the site, and svg is probably less error-prone than trying to leverage backface visibility

particularly in chrome

Noticed while working with storybook, navigating from story to story outputs some errors about elements being undefined, because the resize observer isn't disconnecting

eg:

we should leverage block/inline css properties but may have to manually switch the polygon shape based on tb/lr text direction

the basic demo with text-align: right isn't quite what we want. should make sure we know which side of the paragraph the rags (plural none if it's centered?) are going to be on

some considerations:

• RTL writing modes like for arabic.
  • is there a difference analytically between css writing-mode and inferred writing mode when you just plop RTL text into a LTR document?
• text-align: center needs two exclusions

Could just be a screenshot of the demo?