profile
viewpoint
Mike Reinstein mreinstein DreamingBits LLC Oakland, CA https://reinstein.me

push eventmreinstein/ecs

Mike Reinstein

commit sha f25ca06cc1fa65fd071c8730f63af7c46e92e11f

0.1.1

view details

push time in 2 days

push eventmreinstein/ecs

Mike Reinstein

commit sha ec2400ffd7c5707f5aa007bc6f4d37390f8d7847

update deps

view details

push time in 2 days

startednodegui/nodegui

started time in 2 days

push eventmreinstein/polyglot.js

Mike Reinstein

commit sha b4af03fc9f3a9a2c9aae003501becf63918fb536

3.0.3

view details

push time in 9 days

push eventmreinstein/polyglot.js

Mike Reinstein

commit sha c94c22b28c8f1cb6274b13e2aa01679759d3774a

add note about fork motivation

view details

push time in 9 days

issue commentatomiks/tippyjs

accessibility changes

oh, sorry I misunderstood your statement. Yes I can ask them.

mreinstein

comment created time in 13 days

issue commentatomiks/tippyjs

accessibility changes

Btw can you ask the accessibility people about this?

This advice was relayed directly from the accessibility people. I've already adopted the necessary changes in my fork. I'm just listing this as a courtesy here.

mreinstein

comment created time in 13 days

push eventmreinstein/standing-desk

Mike Reinstein

commit sha b255a58d1952060f54eab749b3bf52a26d098cfd

tweak visual display of history

view details

push time in 14 days

push eventmreinstein/standing-desk

Mike Reinstein

commit sha 78aa2c8615562a655f823febff0c1b3d3598fa0f

tweak visual display of history

view details

push time in 14 days

push eventmreinstein/standing-desk

Mike Reinstein

commit sha 0d875fd4d98a2be2c5ff2f1c4d4458d56a661633

fix history row rendering

view details

push time in 14 days

push eventmreinstein/standing-desk

Mike Reinstein

commit sha 62b4705271176967a5932ca53eb67c4df19a4d0d

render history whenever it changes

view details

push time in 14 days

push eventmreinstein/standing-desk

Mike Reinstein

commit sha 80ff88dd4abe261dd5d15c36601da975fffa701f

render history whenever it changes

view details

push time in 14 days

push eventmreinstein/standing-desk

Mike Reinstein

commit sha 6b421e208089140a9474df3506b73439962be5f3

cleanup history rendering

view details

push time in 14 days

push eventmreinstein/standing-desk

Mike Reinstein

commit sha 6e62b392b01ad0af9a81f1edea064a84bfe10cdf

render the history api

view details

push time in 14 days

push eventmreinstein/standing-desk

Mike Reinstein

commit sha 70571c74661e3be54eb2fef15456e862a103b7fd

render the history api

view details

push time in 14 days

push eventmreinstein/standing-desk

Mike Reinstein

commit sha 895c2837b45ba284f9c5936fc2e5ba6736cbd565

rebuild client

view details

push time in 14 days

push eventmreinstein/standing-desk

Mike Reinstein

commit sha 7c70b58a5500dccc45f70b7e56dc23f3b85e8310

rebuild client

view details

push time in 14 days

push eventmreinstein/standing-desk

Mike Reinstein

commit sha 5fe964354874b0e69dc069a9f1c89df04f6a7693

add history api call stuff

view details

push time in 14 days

pull request commentatomiks/tippyjs

[WIP] V5

I'm working on a SPA and i would like to be able to remove all events started inside a page when navigation occur (without refreshing the page)

@Wyzix33 it's not my place to demand how you write your code, but I suspect there might be a way to architect the app you're making in a way that doesn't cause so much pain. Tippy aside, you are going to be spending a lot of time tracking down dozens or even hundreds of library references. And you still might not catch all of them.

If you really need true perfect memory cleanup it might be easier to load the "guts" of your app in an iframe, and then allow the page to navigate naturally. That way your spa container will stay fixed, and you can let the browser deal with all the cleanup automatically.

Anyway just an idea, maybe it would save you some grief. :-)

atomiks

comment created time in 14 days

issue commentatomiks/tippyjs

accessibility changes

so one thing I discovered though this accessibility evaluation: When setting up aria-controls it needs to be on a stable element. (the it needs to be in the dom ahead of time so the screen reader can associate them. Here's the dom markup that is accessible:

<button aria-controls="acmeinc-storypoints-callout-popper-1"> ... </button>
<div id="acmeinc-storypoints-callout-popper-1"> ... </div>

And then the setup code:

const storypointId = 'acmeinc-storypoints-callout-popper-1';
const storypointDom = document.createElement('div');
storypointDom.id = storypointId;

const tippyConfig = {
   appendTo: storypointDom,
   // ...
}

Something to consider, maybe worth updating the accessbility docs to account for this.

mreinstein

comment created time in 16 days

issue closedatomiks/tippyjs

scrolling the item that opened the tippy out of view doesn't close it

Bug description

If the reference element scrolls out of the viewport, I'd expect the tippy to close automatically

Reproduction

  1. click on a reference element, which opens a tippy
  2. scroll way down the page
  3. notice the tippy is still open

scroll

closed time in 16 days

mreinstein

issue commentatomiks/tippyjs

scrolling the item that opened the tippy out of view doesn't close it

answered my own question, seems to be .acmeinc-popper[x-out-of-boundaries] does the trick. Thanks!

mreinstein

comment created time in 16 days

issue commentatomiks/tippyjs

scrolling the item that opened the tippy out of view doesn't close it

question, how does the css change if I'm prefixing my css (e.g., acmeinc) ? Is it .acmeinc-tippy-popper or .acmeinc-popper, or something else?

mreinstein

comment created time in 16 days

issue commentatomiks/tippyjs

scrolling the item that opened the tippy out of view doesn't close it

oh, hmmm. What does escapeWithReference mean?

mreinstein

comment created time in 16 days

issue commentatomiks/tippyjs

scrolling the item that opened the tippy out of view doesn't close it

is it possible to specify this from the tippy options when creating a new instance, or does it have to be done via declaring css?

mreinstein

comment created time in 16 days

issue commentatomiks/tippyjs

scrolling the item that opened the tippy out of view doesn't close it

so you're saying define these css rules and the behavior will be activated?

Curious, why is this behavior not active by default? Is it the cost of continuously observing intersection with the viewport?

mreinstein

comment created time in 16 days

issue commentatomiks/tippyjs

scrolling the item that opened the tippy out of view doesn't close it

btw this probably gives you an idea of why I was saying this stuff will be in front of millions of eyeballs :)

mreinstein

comment created time in 16 days

issue openedatomiks/tippyjs

scrolling the item that opened the tippy out of view doesn't close it

Bug description

If the reference element scrolls out of the viewport, I'd expect the tippy to close automatically

Reproduction

  1. click on a reference element, which opens a tippy
  2. scroll way down the page
  3. notice the tippy is still open

scroll

created time in 16 days

PR opened ThePacielloGroup/CCAe

prevent accidental publish to npm

the package is named CCA but this doesn't appear to be in npm, I'm assuming intentionally. Adding "private": true will prevent it from an accidental publish.

+1 -0

0 comment

1 changed file

pr created time in 19 days

push eventmreinstein/CCAe

Mike Reinstein

commit sha 81076ecb3cd93a2e85d249185423d7047134a84a

prevent accidental publish to npm the package is named `CCA` but this doesn't appear to be in npm, I'm assuming intentionally. Adding `"private": true` will prevent it from an accidental publish.

view details

push time in 19 days

fork mreinstein/CCAe

The Colour Contrast Analyser (CCA) helps you determine the legibility of text and the contrast of visual elements, such as graphical controls and visual indicators.

http://www.paciellogroup.com/resources/contrastanalyser/

fork in 19 days

startedThePacielloGroup/CCAe

started time in 19 days

push eventmreinstein/standing-desk

Mike Reinstein

commit sha 5457f90e797bd729773ca550bde4fff480dee182

add armv6 node install instructions for raspberry pi zero w

view details

push time in 20 days

push eventmreinstein/standing-desk

Mike Reinstein

commit sha 37b2d6e7477ff3fe4cd842447acb9167c7dcfaa0

allow unattended install of nginx

view details

push time in 20 days

push eventmreinstein/standing-desk

Mike Reinstein

commit sha 47376654f7effd5c2a71089d5a6e6651b32dfffa

disable problematic boot config instructions for now

view details

push time in 20 days

push eventmreinstein/standing-desk

Mike Reinstein

commit sha 0b81fb18a4e2ef2ca4facf75182a4c320f2abb71

add blue tooth disable instructions

view details

push time in 20 days

push eventmreinstein/standing-desk

Mike Reinstein

commit sha 3f8a4f043fad76189a713b4b7feada6a2cab1fd1

update node to v12

view details

push time in 20 days

push eventmreinstein/standing-desk

Mike Reinstein

commit sha 2add9090beb3c7a78a9d4c664887272bbb2adc7a

add logging

view details

push time in 20 days

push eventmreinstein/standing-desk

Mike Reinstein

commit sha 62edf43835ecc5f6b347fcf3ffe868317e18a5b6

tweak styling

view details

push time in 21 days

push eventmreinstein/standing-desk

Mike Reinstein

commit sha 12eafb22870218aace9020a7253ba60c7e6bbb33

tweak styling and remove debug comment

view details

push time in 21 days

push eventmreinstein/standing-desk

Mike Reinstein

commit sha 100b83dc4933c46cc5771e529f2d402971cdf433

fix set height button

view details

push time in 21 days

push eventmreinstein/standing-desk

Mike Reinstein

commit sha a0dfc31bbda290cb9502087cf8cff52182e7c3fa

remove debug messages

view details

push time in 21 days

push eventmreinstein/standing-desk

Mike Reinstein

commit sha 7ce4d163193874434696bdfc93fca417eb5b0d4b

normalize height calculation

view details

push time in 21 days

push eventmreinstein/standing-desk

Mike Reinstein

commit sha 8c5aac22afd4e27d6e77c3b92b8f44a89b2a5bc5

update code

view details

push time in 21 days

push eventmreinstein/standing-desk

Mike Reinstein

commit sha ca3741026ad5999776e9373759019a921a6bd4a2

update code

view details

push time in 21 days

push eventmreinstein/standing-desk

Mike Reinstein

commit sha 77707d183aa99f841e63263b5a249c1bee986959

update code

view details

push time in 21 days

push eventmreinstein/standing-desk

Mike Reinstein

commit sha b9a6783cd4f381ed8b6d28c93625d24a505a6347

move to snabbdom rendering. support enter key in text element

view details

push time in 21 days

pull request commentatomiks/tippyjs

[WIP] V5

Like I said, I'm ok with either at this point. Maybe this really won't be a problem. If v5's current setup does end up being a problem you'll hear about it pretty quickly.

atomiks

comment created time in 21 days

pull request commentatomiks/tippyjs

[WIP] V5

that sounds like it could be a big problem for users not using the popular bundlers. But in practice is it?

I would say so, yes. I mean the thing that kills me is tippy < v5 works everywhere, regardless of what bundler or dev environment used. v5 becomes a lot more opinionated and takes a pretty brutal stance on web development.... "I use react and webpack or parcel and it works for me, so fuck you". <- btw I'm being super dramatic, I know you're not really saying this but that's essentially the ethos that this philosophy exudes. And it doesn't have to be this choice, tippy just needs to ship a bundle in npm that has that stuff stripped out and we're good. It's an unnecessary choice.

I also don't think tippy.js is a common sub dependency like that where the user is totally unaware of its existence (unlike say corejs), making the problem less severe.

I definitely agree with that, unlike a more low-level package (like str_pad for example) which has millions of dependents, a ui library will not be imported as much. but we also can't assume that nothing depends on tippy either. In fact looking at npm, I see 113 different packages that directly import tippy ( https://www.npmjs.com/package/tippy.js ) If you add up your package, plus all the packages that depend on those 113 in some way, could easily snowball to a pretty large amount of affected code. :o

atomiks

comment created time in 21 days

pull request commentatomiks/tippyjs

[WIP] V5

it's kind of miniscule. But, library authors have massive size constraints put on them

That's true, and I definitely strive to reduce unneeded payload as much as possible. But there's a tradeoff point (it's hard to give an exact measurement of where it is) where adding complexity to a build process is not worth the bytes it saves.

A couple minutes fixing it sounds worth it to me...? ... you are experiencing trouble with, just a minor build error.

I don't think you're getting how severe this problem could be, depending on the dependency tree of some app that depends on tippy. Consider this sample module dependency tree:

├─a/
├─b/
└─c/
  └─d/
    └─e/
      └─f/
        └─tippy.js@5/

c, d, e, f all depend on tippy in some way, either indirectly or indirectly. Any code that imports these 4 modules are going to result in broken code that does not run in the browser, unless the app user happens to know that they need to put some special code into their build process to clean out the process.env stuff from tippy (and possibly other modules in the tree.)

this turns into a potentially massive amount of code that suddenly breaks, because someone way way downstream in the dependency graph has no idea that tippy is even used in a sub-sub-sub-sub dependency somewhere, and now they need to alter their build process to account for something really far removed from their own system.

atomiks

comment created time in 21 days

pull request commentatomiks/tippyjs

[WIP] V5

Can I ask why you'd stick to v4 given the numerous improvements in v5

For me, the improvements amount to reductions in css and javascript size, and some tweaks to the way animations are handled. In exchange for a build process that is broken for me. The amount of bytes saved from the changes to css and javascript are smaller than the size of one optimized .jpeg file.

Do you not think little extra effort to move the chunked files over, and the replace plugin is worth it for you?

This is just my opinion, but for me probably not.

atomiks

comment created time in 21 days

pull request commentatomiks/tippyjs

[WIP] V5

What I'd actually suggest is that you publish this v5 architecture as-is. One of 2 things will happen:

1 - you are completely right, in which case I'm blowing this out of proportion and it won't affect many people. If that's true it's not worth spending more time discussing it. I'm planning to use v4 now and for the foreseeable future, so it's not a problem for me.

2 - this will be an issue, or some similar/related one as we've discussed quite thoroughly, and there will be information in this thread on some ideas about how to fix it.

Either way I think things will work out fine. Best of luck!

atomiks

comment created time in 21 days

pull request commentatomiks/tippyjs

[WIP] V5

In the interests of seeing this from a user perspective, I've created 2 sample issues, of what will happen with the given setup.

from the perspective of a user directly trying to use tippy@v5 directly in their code: https://github.com/atomiks/tippyjs/issues/551

from the perspective of a module author, that imports tippy v5 into their own module: https://github.com/atomiks/tippyjs/issues/552

This was based on the most bare minimum of setup, and actually tested locally on my machine in both of these scenarios.

I don't normally put sample issues into the github issue tracker (I at least immediately closed them so they don't show up as noise alongside the real issues tippy has,) but I hope this gives more perspective as an outsider to the tippy project on the 2 likely classes of issues you're going to run into from shipping node globals in the npm distributed code.

atomiks

comment created time in 21 days

issue closedatomiks/tippyjs

[sample] v5: "process not defined" is getting thrown in the browser when my module is imported

Bug description

I author a popular module called my-module. It's a time keeping widget specifically for remote workers that live in Antartica. Tippy is great! I use it to show a popup window in some parts of the widget. Recently I updated to v5, and I'm seeing some errors in the browser console when people include my-module in their own apps.

Reproduction

my module is actually pretty simple, here are all the files:

import tippy from 'tippy.js'

export default function myModule () {
	const dom = document.createElement('div')
	console.log('yes!')
         // tippy related setup code is here...
	return { dom }
}

I'm using rollup to generate the distributable code for my-module. rollup.config.js:

import resolve from 'rollup-plugin-node-resolve'
 

export default {
  input: 'index.js',
  output: {
    file: 'dist/my-module.esm.js',
    format: 'esm',
    name: 'MyModule'
  },
  plugins: [
    resolve()
  ]
}

before I npm publish on this, I run the build step to produce the packaged versions:

npx rollup -c rollup.config.js

Screen Shot 2019-08-03 at 5 45 38 PM

nice, ok it seems to build still without errors. I npm publish this sucker.

Now, when people pull in my new version of my-module they get this error in their browser:

Screen Shot 2019-08-03 at 5 47 24 PM

I'm getting a lot of angry messages from people that use my-module that their apps are broken. What gives?

closed time in 21 days

mreinstein

issue openedatomiks/tippyjs

[sample] v5: "process not defined" is getting thrown in the browser when my module is imported

Bug description

I author a popular module called my-module. It's a time keeping widget specifically for remote workers that live in Antartica. Tippy is great! I use it to show a popup window in some parts of the widget. Recently I updated to v5, and I'm seeing some errors in the browser console when people include my-module in their own apps.

Reproduction

my module is actually pretty simple, here are all the files:

import tippy from 'tippy.js'

export default function myModule () {
	const dom = document.createElement('div')
	console.log('yes!')
         // tippy related setup code is here...
	return { dom }
}

I'm using rollup to generate the distributable code for my-module. rollup.config.js:

import resolve from 'rollup-plugin-node-resolve'
 

export default {
  input: 'index.js',
  output: {
    file: 'dist/my-module.esm.js',
    format: 'esm',
    name: 'MyModule'
  },
  plugins: [
    resolve()
  ]
}

before I npm publish on this, I run the build step to produce the packaged versions:

npx rollup -c rollup.config.js

Screen Shot 2019-08-03 at 5 45 38 PM

nice, ok it seems to build still without errors. I npm publish this sucker.

Now, when people pull in my new version of my-module they get this error in their browser:

Screen Shot 2019-08-03 at 5 47 24 PM

I'm getting a lot of angry messages from people that use my-module that their apps are broken. What gives?

created time in 21 days

issue closedatomiks/tippyjs

[sample] tippy v5: "process not defined" error when people

Bug description

When building my code that imports tippy, the code builds with no errors but I get an error when I run the bundle in my browser:

Screen Shot 2019-08-03 at 5 22 42 PM

Reproduction

index.js:

import tippy from 'tippy.js'

console.log('ok nice!', tippy)

rollup.config.js:

import resolve from 'rollup-plugin-node-resolve'
 
export default {
  input: 'index.js',
  output: {
    file: 'bundle.js',
    format: 'iife',
    name: 'myApplication'
  },
  plugins: [
    resolve()
  ]
}

index.html:

<!DOCTYPE html>
<html>
<body>  <script src="bundle.js"></script>  </body>
</html>

I build the command with this:

rollup -c rollup.config.js

great, bundles with no errors 👍 :

Screen Shot 2019-08-03 at 5 29 51 PM

Then I open index.html in my browser, and in the dev console I see that red error. What gives? Am I doing something wrong?

closed time in 21 days

mreinstein

issue openedatomiks/tippyjs

[sample] tippy v5: "process not defined" error when people

Bug description

When building my code that imports tippy, the code builds with no errors but I get an error when I run the bundle in my browser:

Screen Shot 2019-08-03 at 5 22 42 PM

Reproduction

index.js:

import tippy from 'tippy.js'

console.log('ok nice!', tippy)

rollup.config.js:

import resolve from 'rollup-plugin-node-resolve'
 
export default {
  input: 'index.js',
  output: {
    file: 'bundle.js',
    format: 'iife',
    name: 'myApplication'
  },
  plugins: [
    resolve()
  ]
}

index.html:

<!DOCTYPE html>
<html>
<body>  <script src="bundle.js"></script>  </body>
</html>

I build the command with this:

rollup -c rollup.config.js

great, bundles with no errors 👍 :

Screen Shot 2019-08-03 at 5 29 51 PM

Then I open index.html in my browser, and in the dev console I see that red error. What gives? Am I doing something wrong?

created time in 21 days

pull request commentatomiks/tippyjs

[WIP] V5

It felt like everything I wrote was pointless and fell on deaf ears no matter how hard I tried to make valid and coherent points.

Despite not achieving consensus, I think it was great discussion. It may not seem like it right now, but the fact that we're able to go back and forth on this stuff and attack each other's ideas without attacking each other personally is a strength, and is a healthy component of effective open source. It's something to celebrate! 🎊

Especially getting downvoted without any counterarguments after spending 20 minutes writing 4 valid points was just silly

I'm the only person that 👎'd some of your decisions, and if I had known that it would upset you I honestly wouldn't have done it, as that wasn't my intention. I was trying to convey that I don't agree with the decisions, not make any decision on you personally. I hope that comes through. I also just assumed that the reasons behind my thumbs-down would be obvious given the stuff I'd written in the rest of the thread.

Deleting all the debate helps me forget all of it and maybe look at it with a fresh take so we can resolve this faster.

For me this was the only part that caused true anguish. I was a little disappointed that we couldn't reach consensus, but at least we had some insightful discussions, and that sometimes is valuable later on, even if it doesn't seem so at the moment. Deleting conversations is really getting into dangerous territory, because less even-tempered people might perceive this as attempting censorship, re-writing history, etc. I'm pretty confident that this wasn't your goal, just want to point this out for future open source/collaborative work.

atomiks

comment created time in 21 days

push eventmreinstein/standing-desk

Mike Reinstein

commit sha 54cc44f7c497bd2ce51073445f15eef6009f82fd

add nginx reverse proxy instructions

view details

push time in 21 days

push eventmreinstein/content-editor

Mike Reinstein

commit sha 6e97e8fa4902f2585adb1600f4596e48cae14824

update README

view details

push time in 22 days

push eventmreinstein/content-editor

Mike Reinstein

commit sha 720f01b231a3ece634a3f9d6f3abc734f62ba525

initial commit

view details

push time in 22 days

pull request commentatomiks/tippyjs

[WIP] V5

it was relevant conversation on very real concerns that I and at least one other person had surfaced specific to this PR. The whole point of PRs chat is to discuss these things. It's not like it's cluttering anything; at some point you'll merge the PR and it'll be closed, but it would at least be there for historical value. And there is some, in any long term open source project. Even if it's not known up-front.

atomiks

comment created time in 22 days

pull request commentatomiks/tippyjs

[WIP] V5

I don't see what value they provided.

I don't think you're trying to do it, but you're essentially suppressing dissent that you don't agree with.

atomiks

comment created time in 22 days

pull request commentatomiks/tippyjs

[WIP] V5

I've deleted all the debate comments

That is disappointing and frustrating on so many levels.

atomiks

comment created time in 22 days

pull request commentatomiks/tippyjs

[WIP] V5

Anyway it's kinda crazy how much you've argued this point

Yes, it was time consuming. Truthfully I was trying to save you headache later, because I suspect @rwwagner90 and I won't be the only ones complaining about this. Figured we could solve this now, but we've reached an impasse. I suspect you're going to hear more about this, from other users. But maybe not! Maybe I'm simply blowing this out of proportion.

Best of luck!

atomiks

comment created time in 22 days

pull request commentatomiks/tippyjs

[WIP] V5

We're solving a whole lot of super neat future-looking problems that I don't have as an end user with tippy v4, damn the consequences.

atomiks

comment created time in 22 days

pull request commentatomiks/tippyjs

[WIP] V5

I still think shipping an additional, prebuilt, es6 import compatible version fixes this issue

100% agreed! I'm not asking anyone to ditch their dev copies or throw away debugging code. I just want the distributed versions that show up in the npm install to be usable out of the box. 🙏

atomiks

comment created time in 22 days

pull request commentatomiks/tippyjs

[WIP] V5

Isn't that kind of entitled?

No it's not entitled, that's how the whole npm ecosystem works, and it's how tippy v4 and below work. tippy v5 is in the minority here. If anything expecting people to have to know the internal details of how tippy works is entitled, not the other way around.

atomiks

comment created time in 22 days

pull request commentatomiks/tippyjs

[WIP] V5

Thank you for the actual counter-points instead of random downvotes this time.

I assure you, they're not random. ;)

Uh, but if you're using the ESM or CJS versions, you are already "building it".

You can't make that assumption universally for everyone. Some people genuinely do not use bundlers. nodejs apps do not use bundlers. esm is natively supported in most browsers now, enabling modules without a bunder. This assumption is part of what alienates tippy users.

Yes, but it has the downside of bloated file size (no treeshaking) and no DEV messages

I would gladly accept tippy v4 file sizes if the thing actually works when you install it. Those dev messages are specifically valuable to people that maintain tippy, not me, and not most of your users.

There's no solution for being able to use popper.js (external dependency) with native script tag modules without bundling it in ... That's why no one uses them!

Again, another assumption about how people include modules. It is definitely possible, and it's where things are headed in browser land, deno, and other envs.

So we're not meant to try and push forward very beneficial change that requires pretty minimal work on the installer's end to fix the issue?

We keep getting hung up on what is possible vs what is a good idea. Is it possible for me to create a litttle build tooling to strip out tippy's dev code? Yes, absolutely. You're not considering things from the perspective of a consumer of tippy. Most people installing packages have thousands of packages they're dealing with. What happens if 20 other packages decide they want to ship dev code in their distribution, and they set up that dev code in 15 different ways? I now have to know the internal details of how those projects are built, and add all of the 15 workarounds to my bundler, all the while hoping none of them conflict with each other.

atomiks

comment created time in 22 days

pull request commentatomiks/tippyjs

[WIP] V5

out of the box DEV messages for the majority of users

The majority of tippy.js users are not going to be building tippy. They expect the module to have already been built. That is essentially the difference between cloning a github repo vs using npm install.

It's not like I'm trying to make this difficult to use on purpose..

I know you're not trying to make it difficult on purpose. I appreciate the amazing work and time you've put into this. From an end-user perspective, I am frustrated because tippy v4 works great, is usable in cjs, esm, iife, and umd formats, without any issues. Now with v5 I'm told that this is the only way, and the entire way that npm packages are installed/use is wrong and out of date, and too bad for me for not using webpack or parcel. It feels like we have a pre-conceived notion and we're just looking to defend it rather than question why.

Almost everyone these days is using webpack

provably false. I've worked at a number of companies that don't use webpack. Rollup has something like 200k stars on github.

Thinking about those tools these days is like supporting IE9.

Right now, if you look at almost every single package in npm, you can do npm install and it just works, without having to add a special line to your own project's build process to strip out dev code. That's not an archaic build process, that is the current state of affairs in the npm ecosystem. Archaic or not is the current reality.

If they really can't use tippy.js with an archaic setup with no way to replace the process variables,

Ok, if we really want to talk about archaic process, consider that <script type="module"> works in almost every browser except ie, and I can't import tippy from '/tippy.js' Tippy wants to be future looking, I think that's great, but we're not able to use tippy as-is in native script modules (no bundler) or deno and that's definitely where things are headed.

atomiks

comment created time in 22 days

issue commentatomiks/tippyjs

accessibility changes

I pointed our accessibility experts at this thread, to get a 3rd opinion. From someone that is an authority on actual a11y issues. Here is what they said:

Heydon's article on aria-controls has some valid points, but the conclusion in the article is overstated and dismissive. It is frustrating that aria-controls is only fully supported in JAWS, but that's a large user-base that will be familiar with the interaction pattern. Correctly using the aria-controls attribute has no negative consequences at all, and greatly aids some assistive technology users. It is part of the standard design for a disclosure widget, defined in the WAI-ARIA authoring practices: https://www.w3.org/TR/wai-aria-practices-1.1/#disclosure

Regarding the point about closing the panels if a user navigates out of the panel being problematic for screen reader users navigating back and expecting to navigate into the panel: If focus management is handled correctly, this is not an issue. Navigating backwards would take the user to the button that triggered the disclosure panel, and they would hear that it has been closed, and can open it again. However, focus going to elements behind the panel is a serious issue, and a failure of WCAG 2.1 2.4.7 focus visible: https://www.w3.org/TR/WCAG/#focus-visible
mreinstein

comment created time in 23 days

issue commentatomiks/tippyjs

sticky: true repaints frequently

that said, if you want to backport the theme customization to v4, that would be pretty amazing. That would reduce the size of the css that gets bundled and eliminate a manual step in the tippy.js customization process

mreinstein

comment created time in 23 days

issue commentatomiks/tippyjs

sticky: true repaints frequently

yep! That said almost everyone else is probably using the default tippy.js npm package and would probably like the improvements you've made in a new release.

mreinstein

comment created time in 23 days

issue commentatomiks/tippyjs

sticky: true repaints frequently

my build process:

git clone git@github.com:atomiks/tippyjs.git
cd tippyjs
git checkout bc64e239e7635ca3ca6fe42286da344befb89c05
npm install
NAMESPACE=acmeinc npm run build
cp umd/index.all.min.js ~/Sites/acmeinc/scripts/lib/tippy/index.all.min.js
mreinstein

comment created time in 23 days

issue commentatomiks/tippyjs

sticky: true repaints frequently

I'll try and do a release for this (and all the other fixes made) today

No rush from my perspective, I'm not able to use the npm distribution of this package anyway because I need to run the build process with my own namespacing so everything gets prefixed.

mreinstein

comment created time in 23 days

issue closedatomiks/tippyjs

sticky: true repaints frequently

Bug description

setting sticky: true and trigger: click on an element, it seems to repaint the document rather frequently, so much so that the dom can't be edited from dev console.

(This is happening in chrome, but might be happening in other browsers too.)

Reproduction

  1. visit https://test-tippy-obddnsfyyn.now.sh/

  2. click the button

  3. inspect the tippy element

  4. notice that various dom elements in the dev console are flickering and un-editable:

ScreenRecording2019-07-18at7

closed time in 23 days

mreinstein

pull request commentatomiks/tippyjs

backport position: sticky perf improvement to master #543

thanks for merging this! 👍

mreinstein

comment created time in 24 days

issue closedatomiks/tippyjs

accessibility changes

My employer has recently hired very talented consultants to evaluate how accessible our software is. They've also evaluated tippy since it's part of that product. Mostly the review came back pretty clean, but they flagged a few issues related to some aria-* property declarations.

Would this feedback be something you'd be interested in? I'm happy to forward the tippy specific stuff if you'd find that useful.

closed time in 24 days

mreinstein

issue commentatomiks/tippyjs

accessibility changes

am I missing something? I'm getting a bit of a defensive vibe here.

I asked you if you wanted feedback on the parts of the accessibility audit that tippy has failed at. If you don't wish to apply them that's certainly up to you, but I can tell you that these extra bits in userland will need to be applied to pass wcag 2.0 guidelines for website accessibility every time a tippy is employed.

mreinstein

comment created time in 24 days

issue commentatomiks/tippyjs

accessibility changes

The instance has an id property though?

That only gives the id of the popper, not the id attribute of it's associated dom element

mreinstein

comment created time in 24 days

issue commentatomiks/tippyjs

accessibility changes

they're only considering JAWS screanreaders

Yes, the only known screen reader that supports aria-controls right now is Jaws.

I would argue though there is no downside to including this attribute. 50% of the existing screen readers out there will be able to use it today and get a better experience. The other screen readers will simply ignore this attribute.

It very likely may get added to other screen readers in the near future (NVDA is the 2nd most popular, and it has an open issue to add it, which has some interest https://github.com/nvaccess/nvda/issues/8983)

The problem with doing this in user land is the user needs to resort to some detection of what the id of it's associated tippy element is. (it's not exposed anywhere.) It would be a lot easier if tippy simply set this on it's reference element, since there's no downside.

All of the other issues would be nice to have but not critical.

mreinstein

comment created time in 24 days

issue commentatomiks/tippyjs

accessibility changes

Is this article still relevant?

I can't speak to that article, but here is the feedback verbatim from our accessibility experts:

Use the aria-controls attribute to programmatically define the relationship between
the button and the controlled popover. This allows assistive technologies to move
focus to the associated panel. For example, JAWS (most widely used screen reader)
announces, “Use JAWS key + ALT + M to move to controlled element”

I think it's not actually necessary. GitHub doesn't automatically close the popover either

I can't speak to how accessible github's popover experience is, but according to the accessbility experts we spoke to here is their guidance, verbatim:

When users navigate out of popovers, focus goes to content behind the panel
and there is no visible indication of focus. 
If users navigate out of the disclosure panel, close the panel so that the user’s
focus is not masked by the panel.
mreinstein

comment created time in 24 days

PR opened atomiks/tippyjs

backport position: sticky perf improvement to master #543
+38 -30

0 comment

2 changed files

pr created time in 24 days

push eventmreinstein/tippyjs

Carbon Copy

commit sha 2f19c4b482b46e7edc87f6008a2df7762da7a5e7

backport position: sticky perf improvement to master #543

view details

push time in 24 days

fork mreinstein/tippyjs

Highly customizable tooltip and popover library

https://atomiks.github.io/tippyjs/

fork in 24 days

pull request commentatomiks/tippyjs

[WIP] V5

perhaps we could just ship both dev and prod versions in the dist for those who do not want to run all the manual build stuff to fix the process issue?

Yes, yes, 1000 times yes. :) This is what almost every module packaged for distribution does.

I can't speak to webpack, or parcel, or what react modules typically do, but in rollup, it's very common to ignore the node_modules/ directory and not process it. A common convention for someone publishing a module is to already have a working bundled version of the library in cjs and/or esm, ready to go with no additional build steps.

dist/tippy.bundle.esm.js, dist/tippy.bundle.cjs, dist/tippy.bundle.iife.js and minified variants of these would be fantastic!

atomiks

comment created time in 24 days

issue commentatomiks/tippyjs

accessibility changes

There was one additional bit of feedback, regarding making sure that when the focus leaves the tippy popover, the tippy automatically closes. I don't know if there's a way to do this programmatically. In my code I basically find the last element in the tippy content, attach an onblur event listener, and close the tippy.

That might be brittle to try to code into tippy itself. Perhaps it just gets added to the accessibility documentation section on the tippy website so we're at least setting people up for success?

mreinstein

comment created time in 24 days

issue commentatomiks/tippyjs

accessibility changes

Can that safely be applied to any reference element type (not just button)?

I believe we can uniformly apply aria-expanded to the reference element. Right now the accessibility sample code on tippy's doc website (https://atomiks.github.io/tippyjs/accessibility/) shows wiring up this state manually via onMount and onHide. This could be internalized to tippy's guts, but it doesn't have to be. The example accessibility code works correctly as-is.

I think believe this is the set of functionality that should change (pseudocode):

referenceElement.setAttribute('aria-controls', tippyElement.id)

if (options.interactive) {
   tippyElement.removeAttribute('role')
} else {
   tippyElement.setAttribute('role', 'tooltip')
}

/*
optional: toggle aria-hidden attribute on referenceElement based on
the visibility of it's associated tippyElement
*/
mreinstein

comment created time in 24 days

issue commentatomiks/tippyjs

accessibility changes

In my particular use case, I have a group of buttons, and clicking each one opens a tippy next to it's associated button.

Some of those tippy elements are not interactive (they just have static text in them or an image) and some of them are interactive (they embed a carousel/item slider, or a video, etc.)

For the non-interactive tippy + button pair, the markup looks like this:

<button aria-label="travel friendly"
        aria-expanded="true">
        <!-- icon button's svg element -->
        <svg aria-hidden="true" focusable="false" viewBox="0 0 470 470"> ...</svg>
</button>

<!-- the element managed by tippy -->
<div class="acmeinc-popper" 
        id="acmeinc-3"
        role="tooltip"
        tabindex="-1"
        x-placement="right"
        style="...">
        ...
</div>
  • the role="tooltip" should be set on non-interactive tippy elements
  • aria-expanded should be set to true or false based on if the tippy is open or not

For interactive tippys, the markup looks like this:

<button aria-label="travel friendly"
        aria-expanded="true"
        aria-controls="acmeinc-2">
        <!-- icon button's svg element -->
        <svg aria-hidden="true" focusable="false" viewBox="0 0 470 470"> ...</svg>
</button>

<!-- the element managed by tippy -->
<div class="acmeinc-popper" 
        id="acmeinc-2"
        role="tooltip"
        tabindex="-1"
        x-placement="right"
        style="...">
        ...
</div>
  • no role attribute is needed on a tippy with interactive element
  • aria-expanded should be set to true or false based on if the tippy is open or not
  • aria-controls references the id of it's tippy, so screen readers can associate the button to it's tippy content.
mreinstein

comment created time in 24 days

issue openedatomiks/tippyjs

accessibility changes

My employer has recently hired very talented consultants to evaluate how accessible our software is. They've also evaluated tippy since it's part of that product. Mostly the review came back pretty clean, but they flagged a few issues related to some aria-* property declarations.

Would this feedback be something you'd be interested in? I'm happy to forward the tippy specific stuff if you'd find that useful.

created time in 25 days

pull request commentatomiks/tippyjs

[WIP] V5

The problem is I've run out of time to explore this beta, and I can't ship this in something that's going to prod. I'm going to have to stick with v4 for the time being. Even with this issue aside, my boss is not going to be happy if I put beta software in a production release, especially when it's going out to literally millions of eyeballs.

atomiks

comment created time in 25 days

pull request commentatomiks/tippyjs

[WIP] V5

I'm going to stick with v4 for now. The biggest thing that would help me is to get get the position: sticky fix backported to v4, since that's the latest stable release, and I have to get my own release out the door before I start getting yelled at. :-(

atomiks

comment created time in 25 days

pull request commentatomiks/tippyjs

[WIP] V5

It's fine. I feel like you're getting frustrated with this, and it's not my intention to upset you. I appreciate all the hard work you've done on this project. It's a great module!

atomiks

comment created time in 25 days

issue commentatomiks/tippyjs

sticky: true repaints frequently

can we backport this bugfix to v4?

mreinstein

comment created time in 25 days

pull request commentatomiks/tippyjs

[WIP] V5

at this point you might have to just trust that it's right since other libraries are doing the same thing without problems

Most users of this module are not looking to build their own customized version of tippy. 99% of your users are going to want to do this:

npm install tippy.js

Then they'll want to include it in their app:

import tippy from 'tippy.js`;

// *OR*

const tippy = require('tippy.js');

As far as I can tell, this does not work. :(

atomiks

comment created time in 25 days

pull request commentatomiks/tippyjs

[WIP] V5

all of your questions are answered in the convo I had with @rwwagner90 in the issue 😉

I read that convo, twice actually. I actually fully agree with @rwwagner90 in that issue. The current structure doesn't make sense. built versions of tippy (whether they are built manually from git, or by npm install`) should work "out of the box".

It doesn't make sense that I need to install the library, then run a 2nd build step on it. None of the npm packages work that way. tippy v4 doesn't even work that way. Am I missing something?

atomiks

comment created time in 25 days

pull request commentatomiks/tippyjs

[WIP] V5

I must sleep now it's 1am but open for more discussion if that's helpful tomorrow. Thanks for your help on this stuff! 🌃

atomiks

comment created time in 25 days

pull request commentatomiks/tippyjs

[WIP] V5

btw are you on gitter or some other chat? might be faster to discuss there

atomiks

comment created time in 25 days

pull request commentatomiks/tippyjs

[WIP] V5

it's stranger if you aren't handling NODE_ENV production/development versions, since almost every build tool (like create-react-app) has this set up so you get warnings/error messages in development, but strips them out for production upon build.

I guess where I'm confused is, I'm running your build tool. if I download tippy.js, and I run npm run build, it should output a usable commonjs or es module from that. Why is running tippy's own build process producing bundled output code with process.env in it? Isn't that the whole job of rollup in the tippy project, to produce a usable bundle ?

atomiks

comment created time in 25 days

pull request commentatomiks/tippyjs

[WIP] V5

It's there to help your dev experience and there isn't a better way to do it.

If that is true, why is v4 of tippy packaged traditionally? When I look in index.all.min.js In v4, it is packaged in a typical way:

import t from"popper.js";

// tippy implementation code in here, no references to process in here, just vanilla javascript

export default ut;

^ this works, and is a typical esm module. The way v5 is packaged, you're saying I have to modify the build process to not produce node variables? Doesn't that seem strange?

atomiks

comment created time in 25 days

more