montagejs / digit Goto Github PK

The focus styles are unclear.

• If you tab over the fields (using the keyboard) there should be a bigger difference in focus styles
• The radio and checkboxes get skipped altogether; this is an accessibility problem

@aadsm: "too dark..."

Add styles so that the Button also can be used with an <a> element.

In the enclosed screenshot, when attempting to selection "Bounding Box" it is actually "Play Animation" that is selected. This happens if the mouse pointer is not completely "inside" under Play Animation but when overlapping. It would be expected that the checkbox being on top of the "hand" icon is selected, not the on the bottom.

You can repro using this test-application:[email protected]:fabrobinet/glTF-webgl-viewer.git and please use the branch called dev-1, otherwise it won't be the same UI.

In Safari 6.1 (8537.59).
http://screencast.com/t/mV5eytQyBJ

It’s okay in Chrome and Firefox.

Currently we use an data-montage-skin attribute selector to apply a Skin to child components. Like [data-montage-skin="dark"] .montage-Button. Should we use a Class instead?

The main reason was to somewhat separate it from the rest of CSS classes and it fits well with data-montage-id. But Classes have better performance. By how much is still something to be researched more.

To be tested:
[data-montage-skin="dark"] .montage-Button vs .montage-skin-dark .montage-Button

• https://www.npmjs.com/package/digit

Now that iOS 7 also supports the new Flexbox and Chrome, Firefox, Opera already dropped the prefix, see caniuse.. I think the timing is right to start using it for layout components. At least for Digit.

So I was thinking instead of some kind of global thing or layout backed into every component, we should just start doing it on a component level, one by one. That way we can test things out and also make it custom for each situation. So how about we start with a Header component?

Features

By default if you add child components into a Header, those child components get distributed evenly left to right. Then you have the option to override it so they all move to the left, center or right.

Serialization

You could just use CSS classes and add the variations to the markup.. like digit-Header--center. But if we also wanna do it through the serialization, we could use something like "layout": "<", see this gif:

By using those "emojis", it would be similar to the bindings. But I'm not sure. Typing the word left is pretty fast too and maybe even easier to remember. Also, trying to find "emojis" for other components, like bottom-right could be pretty hard without using special character that you have to copy paste.. So yeah.. it was just a cool idea, but using words is probably still better in practice. Like:

"layout": "left"
"layout": "center"
"layout": "right"

Next steps

Should I go ahead and do the CSS part? And then somebody could help out with the JS? Not sure what our priorities are. /cc @asolove @aadsm

http://screencast.com/t/5pv7pXJUfw

I cloned the project and did npm install.

The README states:

To preview the components, add a symlink that points to Montage at /node_modules/montage and then you should see them if you visit /overview on your local server.

Why do this if you are using npm? Am I missing a command? Do I need a specific server?

Currently all Skin styles (Skeleton, Light and Dark) are in the same CSS file.

It works fine, but if we wanna optimize it a bit more, it would make sense to separate them into their own files.. maybe like:

toggle.css
toggle-light.css
toggle-dark.css
toggle.html
toggle.js

So toggle.css would only have the minimal default (Skeleton) styles. If you gonna custom style the whole app yourself.. that's all what you would need to load. And only if you want to use dark and/or light, Montage would load/mop those styles as well. That should save some file size and increase CSS selector performance. All just a drop on a hot stone and at the end of the "optimizing list", but maybe still something to consider?

The initial inline transform on digit-Slider-thumbTrack doesn't get applied on load, just when clicking on the thumb, which makes it jump. See GIF:

Also if you set an initial value in the serialization there is no transform set.

When a NumberField is used inside a <label> element, then you can't click inside the input. It gets immediately de-selected. Plus/minus buttons still work.

See test MFiddle: http://montagejs.github.io/mfiddle/#!/7229077

I guess it has something to do that <label>s select checkbox or radio when inside?

See https://github.com/montagejs/digit/blob/master/progress.reel/progress.css#L11

.montage-Progress > .montage-Progress-bar {} is a bit over specified. .montage-Progress-bar {} would be enough.

The knob should not move at all until there's a mouse move.

Current state of nesting skins is as follow: You can nest a dark skin inside a light one, but no more further. Basically once you use the dark skin, that's already the end.

Do we want to add deeper nesting? Maybe for now, if you really need, you could just add the skin attribute to smaller areas.

test/select/select-test.html:

Labels are empty.

Trying to pick a default font family for Digit and came across this list of system fonts of different mobile platforms: http://www.jordanm.co.uk/tinytype And looks like Android only supports Droid Sans and later Roboto. So it's impossible to pick one that is the same across all of them.

We could embed a custom font, but currently there is no concept of global styles and shared assets in Montage, so we would have to embed the font in every single component which is totally overkill.

So I think there are 3 options, we would add in every component's CSS selector:

1. font-family: inherit - in this case a developer HAS to define or add a custom font in the app. If not it just goes to the default Times New Roman, which is not that great.
2. font-family: sans-serif - In this case I think iOS would use Helvetica, Android -> Roboto, Windows -> Segoe UI, BlackBerry -> Slate Pro. So would look everywhere different, but true to the platform.
3. font-family: "Trebuchet MS", sans-serif Trebuchet looks good in small sizes, has real italics and is supported in iOS, Windows, Blackberry. Android would use Roboto. Alternatives would be: Arial, Verdana.

ps. problem with 2 + 3 is that IF you wanna use a different font or a custom one, you have to override it in every single component.. basically a huge selector chain that becomes hard to manage. or something ugly like * { font-family: "custom" !important }

The progress component should have determinate and indeterminate states, and when animated, should stop when it reaches 100%. See montagejs/montage#994.

Testing:

1. MFiddle:Examples/2-way-binding
2. type in the number box 99
3. first time 9 key is pressed, the value entered is 09, & the sliders jump to the left
4. second 9, the intended value of 99 is fully entered, & sliders jump to right

Though here only 2 sliders are affected, but imagine a large spreadsheet that graphs results? That could be alot of jumpiness in the SPA.
In another platform, we would prevent jumpy values (& reduce CPU usage) by having a global 'heartbeat' function. Please let me know if you want a demo/explanation (bit long to explain).

Not sure why 4 is shown everywhere, probably b/c WIP. There are actually only 3: wireframe, light and dark

Also need to fix in docs repo