One of the primary goals of eureka.js is to be able to handle any accessibility test we could throw at it including disabling javascript all together.

Accessibility is tricky and so is testing it. Could use all the help we could get.

The static examples are hosted at:
http://devries.jp/static/eureka/examples/index.php (drawn html first)
http://devries.jp/static/eureka/examples/muck.php (drawn with js)

but I haven't hooked my server up to auto deploy on git push yet they may get out of date. For those with local php testing environments please pull from the develop branch and test the examples folder. Otherwise, use the links above.

Screencast
A 90 second screencast of our first screen reader test
https://vimeo.com/128895951

Please log any accessibility issues or concerns
https://github.com/jpdevries/eureka/issues/new

There's a known issue where Chrome pretty much broke flexbox in v48.

Also see angular/material#6841
https://code.google.com/p/chromium/issues/detail?id=546034#c6

It looks like Eureka is firing off all of these requests when rendering the browser:

• List media sources
• List files in s=2 (nothing is selected, but I'm guessing it grabs the first media source here) for dir=undefined => should be set to / instead of undefined, otherwise that's good
• List directories in s=undefined (this one's weird)
• List directories in s=2 (first media source - this is good)
• List directories in s=3 (this one's weird, I don't think it should try to preload for non-selected media sources on render)
• List directories in s=1 (another one that I don't think is needed)
• List files in s=2 and dir=undefined again

It seems to me that it should be possible to bring that back to just this:

• List media sources
• List directories in s=2 where 2 is the first media source in the list
• List files in s=2 and dir=/

https://github.com/lazd/scopedQuerySelectorShim

There's a border-radius applied to the button element, without any eureka scope, causing a weird ")" in dropdown boxes when used in MODX/redactor. See https://secure.helpscout.net/conversation/129911402/6742/

Currently the flexbox styling is totally borked in Opera, but I think that is because flexbox is borked in Opera.

The media browser is actually screen reader friendly, but it is done using "hidden innerHTML". Switch to ARIA

https://vimeo.com/128895951

There are some features I'd like to add without necessarily having to add them to the core. For example, the 'context menus' that display Expand | Choose | Rename | Delete options aren't currently customizable. Certain options can be hidden, but you can't say add a custom Crop button or something like that.

To make Eureka.js more flexible, I'd like to somehow make the core more extendable (maybe the fact that it already is OOP with ES6 classes will help out here)

When you browse to a directory that is empty the stage area is very well, empty

Would be nice to be all Slack about it and show a clever message with a call to action to browse elsewhere, search, create a new folder, upload a file, or whatever else.

This issue proposes an option, which defaults to false, to display "caret" arrows to depict whether or not a directory is expanded or collapsed.

Note: Eureka should always expand directories when they are selected for browsing.

Eureka

• click a folder name to browse that directory
• click the folder icon to toggle visibility of sub children

MODX Native Browser

• click a folder name to browse that directory
• click the folder or caret icon to toggle visibility of sub children

So Eureka works just like the MODX Native browser with the exception that:

• eureka's folder icons visually depict whether or not a directory is expanded or collapsed
• bolded directory titles are used to show the directory currently being browsed
• eureka does not display "caret" arrows to depict whether or not a directory is expanded or collapsed

To date, eureka.js is rather read-only meaning that you fire it up, give it some settings and URLs for XHR requests, listen to some events...and that's it.

The internals haven't been exposed and references to the _model remain private. Need to determine what methods would be desirably in a first draft of a public API and then either add hooks for those through the Eureka class or simply make the _model a public model:EurekaModel so it can be accessed like:

$eureka.model.getCurrentMediaSource()

or to get real crazy with it:

$eureka.model.setCurrentDirectory('assets/uploads')

The API has an option to set the language, but it doesn't affect anything yet.

This is because the <table> is styled with flexbox so it looses it's true tabular nature and it has to be faked

Also see https://github.com/modmore/Redactor/issues/387

In our tests with Amazon S3 and MODX we've noticed that the list directories connector can time out. I'm not sure how, but perhaps the front end should be better prepared for this

Currently just directories are listed

40kb is a bit bigger than what I was shooting for with un-minified CSS size. Contributing factors to size are:

• overly specific CSS selectors
• flexbox (and other) prefixes
• long hand flexbox declarations

The overly specific CSS selectors (> is used a lot) are bad I know, but I loose sleep over flex properties being applied too loosely so I like to enforce the parent / child relationship. Even still, the selectors could probably be safely loosened.

For the overrides, once Bourbon ditches their flexbox prefixes I'm planning on removing all prefixes from the Sass and using grunt-autoprefixer to add them in the build process.

For the long handed flex declarations, I'm weary to remove those because some of they help avoid certain cross browsers bugs and I also feel they improve legibility. The spec disagrees with me on this, and recommends using the shorthand syntax.

i suppose there needs to be a ./ option listed first under each media source that switches to that media source and sets directory to ./

Firefox still has some flexbox issues, particularly when dealing with flex-direction:column. We are noticing that Firefox will allow children to be as tall as they want, rather than as tall as the flexbox spec tells them they should be. To work around this, I've had to 'hack firefox' to essentially not use the holy grail layout OR manually patch the flexbox bug using JavaScript and a nasty resize listener.

Somebody please tell us we are mistaken and just missing a Firefox prefix or something 🙏

Example

See this page in Firefox 37.0.2 to see how we are working around the flexbox bug by de-activating the holy grail layout.

See this page in Firefox 37.0.2 to see how we are working around the flexbox bug by using JavaScript rather than the above CSS hack.

Sass Hack

html.no-touch {
    .eureka-wrapper.hack-firefox {
        @include media($gtMobile) {
            > .eureka {
                @include firefox-hack() { // #janky
                    @include flex-basis(86%);
                    max-height:86%;
                }
                > .stage {
                    > .eureka-table {
                        @include firefox-hack() {
                            height:auto;
                            @include flex-basis(86%);
                            max-height:86%;
                        }
                    }
                }
            }
            > .proceed {
                @include firefox-hack() {
                    @include flex-grow(1);
                }
            }
        }
    }
}

JavaScript Hack

<script>
/*
  hopefully we are mistaken but we believe we found a use case where firefox 38 deviates from the flexbox spec
  find the patch we came up with below
*/
Modernizr.addTest('firefox', function () {
    return !!navigator.userAgent.match(/firefox/i); // who cut the user agent? shame on us...
});
(function(){
    /*
      checking the userAgent is really gross...
      so let us not and say we did...
    */
    if(!Modernizr.touch && Modernizr.firefox) { // for firefox non-touch browsers
        document.addEventListener('DOMContentLoaded', function(){ // layout the flex children the way firefox should
            /* fix the bug somehow???... */
        });
    }
})();
(function(){ 
    /*
      this is probably a more reliable way than checking the userAgent...
    */
    if(!Modernizr.touch) {
        document.addEventListener('DOMContentLoaded',function(){
            var mediaBrowser = document.getElementById('media-browser_0'); // dangerous but more optimal to not looks these up each resize
            var eurekaWrapper = mediaBrowser.parentNode;
            var eurekaTable = mediaBrowser.querySelector('.eureka-table');

            document.querySelector('.hack-firefox.eureka-wrapper').classList.remove('hack-firefox'); // remove the CSS patch :/

            if(eurekaTable.offsetHeight > eurekaWrapper.offsetHeight) { // eurekaTable might be too tall now
                try {
                    console.log('uh oh, we detect a flexbox bug');
                } catch(e) {}

                function handleResize() {       
                    // i hope i don't get in trouble for doing other browsers homework...
                    var w = Math.max(document.documentElement.clientWidth, window.innerWidth || 0);
                    var dh = (eurekaWrapper.offsetHeight - eurekaWrapper.querySelector('.eureka__topbar').offsetHeight - eurekaWrapper.querySelector('footer.proceed').offsetHeight);
                    dh -= (16*1.5); //1.5ems of margin

                    eurekaTable.style.height = eurekaTable.style.maxHeight = eurekaTable.style.flexBasis  = (w <= 768) ? null : dh + 'px'; 
                }

                window.addEventListener('resize',handleResize, false); // we'll be here all night folks...
                handleResize();
            }

        });
    }
})();
</script>

Chrome 👍

No hacks needed. Correctly laid out.

Firefox 37.0.2 👎

SCSS Hack being used to deactivate holygrail layout.

Firefox 37.0.2 👎

JS Hack being used to manually calculate holygrail layout. This is super lame because the whole point of flexbox is not to have to do things like this 😢

Flexbox Bug

The issue is rather simple. We have div.stage:

with this CSS:

.stage {
  display: flex;
  width: 100%;
  box-orient: vertical;
  flex-direction: column;
  box-lines: single;
  flex-wrap: nowrap;
  flex-grow: 1;
  flex-shrink: 1;
  flex-basis: 100%;
  -ms-flex-preferred-size: 100%;
}

So it is nice and tall and will lay it's children, div.eureka__topbar and div.eureka-table out vertically. We want .eureka__topbar to take up as much room as it needs to but not grow anymore than is necessary, and then we want .eureka-table to simply take up the remaining space.

We have div.eureka__topbar:

with this CSS:

  flex-basis:4.8rem; /* if we had to pick a certain size */
  flex-shrink:1; /* ok to shrink beyond the basis */
  flex-grow:0; /* do not grow */

Lastly, we have div.eureka-table:

with this CSS:

.eureka-table {
  flex-grow: 1; /* grow */
  flex-basis: 100%; /* be greedy */
  height: auto; 
  -ms-flex-preferred-size: auto;
}

so it will take up the remaining space.

So here's the deal, Eureka's layout uses flex-direction:column to layout flexible components vertically. This allows us to set a desired height using flex-basis on the "top bar" area that contains the search and layout buttons. In the same way, we can set a desired height for the footer.proceed component that contains the cancel and choose buttons. Then, the magic of flexbox will allow our "stage area" that contains the grid of media items to grow to be as tall as it can be given those conditions. Awesome!

Problem is, Firefox 37.0.1 still seems to have some critical flexbox bugs. I believe it deviates from the spec when it allows the stage area to grow to be as tall as needed (completely breaking our flexible layout).

So I went on a cruise for a week 🚢

and with a few browser updates the flexbox layout broke itself 👎

Making sure to really test everything cross browser before committing these tweaks.

Firefox Mac

Chrome Mac

Safari 9.0 Mac

The source scripts use an OOP MVC structure and are authored in TypeScript but they still aren't as DRY (Do not Repeat Yourself) as they could be. By DRYing things out, we should shave off some filesize but more importantly make the codebase more maintainable and testable.

muckboot.eureka.ts will compile as typescript (although it throws a few warnings) but eureka.js will not.

would be kinda cool

This would be a great feature, but it sounds like browser support isn't stable yet

See detail description at philipwalton/flexbugs#51

Currently when you say, delete an image

• eureka.js removes the image immediately from the view
• updates the model
• model dispatches appropriate event and data

idea being you listen for the event and say, make another XHR request to your API endpoint to actually delete the image from the backend.

This is just one example of where eureka.js assumes something will successfully happen. Prior to tagging a 0.1.0, I'd like to put some more thought and possibly refactoring into this.

Currently Eureka really only supports <img>. Would like to add:

• audio formats
  • mp3
• video formats
  • mp4, ogv, webm
• generic formats (thumbs for)
  • pdf, excel, word, zip, powerpoint, txt
• code formats (maybe)
  • html, css, js, php, markdown

As part of our accessibility testing I want to make sure things are focusable through tabbing and what not, but Eureka should also support keyboard shortcuts. Question is...which ones should it support and what key patterns should they use? Discuss here

Reported in support ticket 6009

Would list subdirectories as files, allowing them to accessed as if they were a file being chosen

Currently the only visual progress indicator is in the dropzone, which is only visible to .no-touch users with large enough windows. Not sure the best way to handle it, maybe just a really thin stripe at the top.

eureka.js was written in modern VanillaJS and uses some new ES6 stuff. To support older browser, something like typescript will need to be used to transpile the source code for older browsers.

Duplicate XHR Requests can cause oddities in certain environments. Cachebusting them with the current time could prevent that. There could be a cachebustXHR option that defaults to false.

See Also
https://code.google.com/p/chromium/issues/detail?id=458620

Here I had been thinking this flexbox layout was perfect and it only seems to work correctly in Safari. Likely has something to do with overflow, cross browser issues with <tbody>, or something like not setting height as well as flex basis.

Eureka uses FontAwesome as a pain free way of adding icons to the UI, and it even uses some clever a11y tricks to keep things readable to screen readers but regardless of that, icon fonts have some inherent accessibility issues:
https://twitter.com/brucel/status/616257010884059136

Should probably switch to SVG instead.

Also I would like to NOT see thumbnails in the media browser. There
should be a view that just shows file names.

modmore/Redactor#400

So currently eureka.js makes all the XHR requests itself, which is kind of nice. In the next commit or so I expect to have at least the urls it hits for each type of request as settings but one thing I haven't been able to decide on is how to handle appending headers to the requests so that eureka.js can be used in secure systems like the MODX Manager.

It seems like one option would be a way to pass in an array of additional headers to send which each request. Another would be to pull the XHRs out entirely and eureka.js just dispatches events, you make your requests, and set the new data manually to the model.

I'm not sure which one is more desirable and don't have much of a preferences

I think this may need a change to Eureka - currently the processor returns a src element which is inserted in to the page and the browser, but we'll likely need a second element supported for the src of the browser thumbnail so we can send a different url back for that. Calling it thumb should do the trick. I'll start adding it to the processor, can get it added to Eureka?

https://github.com/modmore/Redactor/issues/349

When large images receive focus the layout breaks in Firefox 39.0

always thinks files are uploaded correctly

Currently Eureka doesn't display the media source itself as the root directory in the file tree.

Because of this, a up arrow is displayed next to the media source select that when clicked goes up a directory (cd ../). This allows users to reach the absolute root without needing to display that folder in the tree.

Maybe there should be an option to display the root directory in the file tree though...

works in index.php implementation but not muck.php so must have something to do with muckboot

Currently the JS assumes the JSON it will be fed will already be sorted ASC by id. Should sort on the JS level just to be safe I guess.

{"success":true,"total":"2","results":[{"id":4,"name":"Amazon S3"},{"id":1,"name":"Filesystem"}]}

/assets/components/redactor/connector.php?action=media/directories&HTTP_MODAUTH=foobar&resource=42?s=2&headers=%5Bobject%20Object%5D

Note the question mark after &resource=42 that should be an amp

Also the headers option is being passed as [object Object] into the url?