Same for disabledHover. It should extend disabledStyle.

I noticed I made this mistake at the Select. There might be other places. We should double-check.

• fix hoverStyle behaviour in Select
• fix focusStyle behaviour in Select
• deprecate duplicated styles definitions in style.select.hoverStyle, style.select.activeStyle, style.select.focusStyle
• investigate if other components have the same issue
• update documentation to explain how psuedoClass styles work in Belle

When a user does a mouseDown or touchStart at the ComboBox we should provide an activeStyle. While this is not necessary for the default belle styling we have right now it is for different themes e.g Bootstrap.

Running
npm install belle

on Windows 8.1, I get the following error:

545 error Windows_NT 6.3.9600
546 error argv "C:\Program Files (x86)\nodejs\node.exe" "C:\Program Files (x86)\nodejs\node_modules\npm\bin\npm-cli.js" "install" "belle"
547 error node v0.12.2
548 error npm v2.7.4
549 error code ELIFECYCLE
550 error [email protected] postinstall: rm -rf node_modules/react/ && rm -rf node_modules/underscore/
550 error Exit status 1
551 error Failed at the [email protected] postinstall script 'rm -rf node_modules/react/ && rm -rf node_modules/underscore/'.
551 error This is most likely a problem with the belle package,
551 error not with npm itself.
551 error Tell the author that this fails on your system:
551 error rm -rf node_modules/react/ && rm -rf node_modules/underscore/
551 error You can get their info via:
551 error npm owner ls belle
551 error There is likely additional logging output above.

Apparently, as for line 551, it tries to execute this command :
rm -rf node_modules/react/ && rm -rf node_modules/underscore/

which of course is not valid on Windows.

Have anyone had better luck installing it?

In here an issue with resizing probably was discovered. This would need investigation. At best an example or a test.

https://github.com/andreypopp/react-textarea-autosize/pull/19/files#diff-b6daa83603fc3d6476742289658c4ebeR62

We used checked as it made sense to mimic the checkbox API. Since we are moving to onUpdate it's better to align the APIs & use value instead.

This is more experimental, but for example when fading from hover/default state to active state we could leverage animations to give the components a better feeling.

Also switching from default state to hover could be a slide colour fade.

Would be good if both behave the same way. Let's see if there is a good path towards that goal.

I'm running chrome 43.0.2357.134m on windows.

How to: Put Select, TextInput, ComboBox next to each other and make sure the Text and border bottom are the same horizontal lines

I like your code and I would love to see jss (https://github.com/jsstyles/jss) to be used for styling. It would simplify the code in some places and you can get rid of some helper functions. It has also react integration https://github.com/jsstyles/react-jss which basically ensures you have only sheets rendered into document, which are also in use by rendered components. Also jss styles can't clash.

This feature was really a bold move & there are still some issues. Question is if we should deprecate it at all.

Helpful resources:

• https://github.com/rackt/react-a11y
• https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_listbox_role

While a lot of people use underscore, some use lowdash or just go with ImmutableJS. In order to pre-subscribe belle users to underscore we might want to create little micro library only with the functions we really need.

Proposed way of tackling this:

1. Collect all the functions we use
2. Copy them from underscore into a microlib and use this lib instead

Open question:

• Change name? DatePicker to Calendar - no
• Separate config file for i18n? - yes
• focus of days (yes/no) - maybe split component into datepicker & calendar - discussed

Todos:

• Nik: styling
• Styling API
• change aria tags
• sanitizing and passing user props like other components - props added for wrapper and day
• Review behavior of ReadOnly date picker
• Nik, Jyoti - review whole code/ logic to improve/ simplify it
• Default belle animated focus styles for wrapper, Bootstrap and belle-with-default-focus styling for datepicker in docs
• Update docs/configuration page after styling api is finalized

Suggestions

• Treat Days & Prev/Next navigation likes buttons with custom focus behaviour (maybe build a custom click/touchable area/button).
• make other month days clickable as well (switch to that month after the click)
• update focus based on hover (when I hover a box it should be focused)
• Focus for days does not maps to the DOM focus event, it is a state that is maintained at react component level. The trouble can come if user whats to attach a callback to focus, blur or keyDown of days, right now we donot handle these events at day level but at wrapper level and we take action for days also depending on what is value of currentFocusedDay. Possible fixes:
• Leave it as open issue for now and we will think of a solution only if someone really needs.
• We can add 3 props onDayFocus(), onDayBlur() and onDayKeyDown() and call them passing them the wrapper event object and currentFocusedDay value, whenever the event occurs for wrapper and there is some day focused.

The reason for keep the focus state independent from DOM focus was WAI-ARIA specification that current date should be focused as date picker of focused. And focus behavior while tabbling which was not achievable with DOM focus.

• refactor focusedDateKey behaviour
• fix weekend, disabled, readOnly style style
• maybe min date / max date? - is this really needed (Jyoti)
• try an date range example
• investigate possible timezone issues - I did thought about it initially but I think time-zone will have no impact on date-picker, only locale will have and that too in respect of look and feel of date-picker.(Jyoti)
• check if touch cancel is nowhere missing anymore
• export prev/next arrows to style
• make sure each element has a props entry to be overwritten (depcrecate the classname overwrites) - hey Nik I really wonder if anyone will ever need that (Jyoti)
• improve test suite - In Progress (Jyoti)
• bootstrap styles for the datepicker
• update docs
• code comments
• ask for feedback: Jyoti, Andrey, Andraz, Valentin
• ask for feedback: people who wrote the aria recommendations - Very good idea (Jyoti)
• other month day select works even if its configured to be hidden in date-picker (Jyoti)
• Why are we using this, onClick of <ActionArea> rather than touchStart or mouseDown ?

Bugs

• Focus should stay on the Datepicker when clicking a Day
• Focus should become active when you click anywhere in the datepicker
• All standard events we overwrite should have callbacks e.g. onFocus
• Somethings odd with collapsed stylings (1px less on the right side)
• Jumping with the keys to a date from the next year doesn't work
• Jumping with the keys to a date from the previous year doesn't work
• focused style not distinguishable from weekend style
• When today is selected its color should remain blue.
• When I select a day its kind of pressed like button, but it does not comes up again - thats kind of not expected. I think there is no reason for selected day to remain pressed.
• How about more distinguishable styling for selected/ hovered days.
• Other month days are not distinguishable in disabled date-picker.
• May be it will be nice to have a little border in modified hoverFocus style so that users will know intuitively that day is focused also.
• Left and Right date navigations should be reversed for locales with RTL true.

Initially we were striving to build components that behave exactly like HTML native ones, but with additional features & more control over them. This idea was mainly driven by React's concept of "Learn once, write anywhere". This would have included getting all the events right. So we aimed to implement the onChange callback to return an object that would look like:

{
  target: domNode(with value),
  currentTarget: domNode of current target,
  …
}

At the React Europe conference I talk to some of the React core contributors what they would recommend. The feedback was not trying to mimic the current API. One reason is that after the 0.14 beta announcement we see React going in a direction with a React core & different packages to render to different targets. We might even see a future where components work for multiple targets. This would mean the API should be designed in a way to work on different targets. Putting DOM events in there would be the wrong direction. Another reason is that I don't even know if it's possible to get it right in all the browsers. It's more of a gut feeling, as I haven't really tried apart from the target property.

After Jyoti & I decided we won't mimic the API we needed to come up with our own that can be applied consistently. We didn't even need to think about it. It was obvious the changed value is the relevant information. Luckily we got another good advice on the conference: "Whenever you create an event like callback wrap it into an object. You never know what you might want to add in the future and you don't want to break the API". While we won't add anything from the beginning I already can imagine how beneficial this advice was. We ended up with this structure { value: value }.

Last but not least we needed a name for the callback. OnChange came naturally as we already had it in the code. Unfortunately there was an issue. We didn't feel comfortable using the same name as React does, but applying different behaviour. As a developer coming from HTML/JS you already had to learn that onChange behaves differently than in the specs. Should we break with this behaviour once again? I wasn't happy about it. Even someone from the React core team told me something like: "Maybe it wasn't the best choice we picked the name onChange". So we saw an opportunity here. If we don't mimic the original API, we don't want to add confusion. So we decided to go with onUpdate. An alternative name would have been onModify. If you think that would have been better for some reason let us know.

The final API:

this.props.onUpdate({ value: value });

Did we miss something? Should we do it in another way? Let us know what you think?

Originally this came up in this discussion: #60

@jpuri I noticed when clicking mouseDown on a star of the Rating component, then drag & release somewhere else the stars are not set. Not even the old value is there.

Short demo video: https://youtu.be/8ZxPsG4KMj0

Add one more pseudoClass style disabledStyle. It can either leverage the same style injection as active or be updated based on the props (Probably the second one). Keep in mind to provide a version for the primary button as well.

• Feature list on the front-page (Mobile first, Aria-Support, Style-able, Theme Support, custom props)
• Better navigation for mobile
• logo + favicon
• light colour theme
• theming guide
• better way to switch between themes
• add team (+ emails)
• improve philosophy text
• better props explanation (split into groups, expand/collapse, more examples)
• quotes
• guide/article with belle introduction / why belle
• analytics (google, segment)
• open graph description
• test repository with an example of server side rendering
• test repository with an example of webpack usage: https://github.com/nikgraf/react-starter-with-belle
• test repository with an example of browserify usage

The Toggle is larger enough, but when sliding in one direction, but moving back it's very easy to loose track of the Toggle. The field of where touch events are allowed should be bit bigger.

My first guess is that we should add the height on the top & bottom as sliding area.

Hi Nikgraf,

Cool branch off! One note - there might be a memory/element leak somewhere. I noticed that after typing in the demo textbox (http://nikgraf.github.io/belle/#text-input) my browser tends to go ballistic and adds hundreds of new DOM elements on key keystroke, which brings it to a halt and introduces a lengthy lag between keydown and character appearing on the screen. After a few lines document.getElementsByTagName('*') reporting 20,000 elements (vs 300 at the start).

I didn't have a chance to investigate whether the problem is with the textbox itself or the page wrapping or any external change listeners.

This could make it way easier for people to understand this huge list of properties.

I thought of these groups

• Base Properties (value, valueLink, defaultValue, disabled, allowNewline, …)
• Style Properties (style, hoverStyle, handleStyle, …)
• Advanced Properties (handleProps, wrapperProps, …)

What do you think? I'm open to any other grouping suggestions. /cc @jpuri

In some situation I noticed the contrast is too little and you barely can see which option you chose.

When a user does a mouseDown or touchStart at the Select we should provide an activeStyle. While this is not necessary for the default belle styling we have right now it is for different themes e.g Bootstrap.

Documentation Select:

• Focus animation is not working in some IE (can't remember)
• IE 11, IE 10: Input field with Placeholder has height of 0
• IE 11, IE 10: Vacation select opens, but when clicking it doesn't allow to select an Option with mouseDown
  (with the Keyboard it works) - also with Bootstrap styles
• IE 9: Combobox is not focusable (seems like the underlaying input is on top)

Combobox

• IE 10: You can only click on the placeholder (in general there seems to be a height issue with all inputs)
• IE 11, IE 10: there is an "x" in every input. Investigate how to hide it.

Toggle

• IE11 and lower: With Bootstrap styles there is an issue at the border/background top of the handle
• IE11 and lower: On Belle with classic focus style you can see the Toggle is loosing focus

Minor issues:

• IE11 and lower: The textinput autogrows is bit laggy on IE.
• IE11 and lower: The select menu positioning is a bit off.
• IE9 Toggle is not animated onClick (that's ok)
• IE9 Rating has now textShadow (that's ok)
• IE8 Failing with some React internals (that's ok)

Right now if you switch themes some styles seem to not be applied e.g. focusStyle on Rating

Brainstorming with @crtvhd

Toggle

• should support true/false -> why not take a checkbox?
• support Strings & Numbers as choices?
• fancy animation
• button should be draggable
• should be able to change the style (true false)
• Icon support?
• should validate children count (only 2)
• should work with label-tag -> pipe id to input checkbox to allow using label for="input-id"
• Default toggle has a ✓ (green) & x (grey)
• Disabled style
• Smooth dragging (as smooth as possible with javascript)
• Active state for handle on mousedown
• Add touch events

Example

<Toggle />


<label>
  <Toggle />g
  Hello
</label>
--> by default is checkbox

<Toggle>
  <Choice id="yes" className="first-choice">On</Choice>
  <Choice id="no" className="first-choice">Off</Choice>
</Toggle>



<Toggle>
  <Choice className="first-choice">On</Choice>
  <Choice style={{ color: red }}>Off</Choice>
</Toggle>

Yes/No
<label>
  <Toggle
    defaultChecked={this.state.baconIsReady}
    onChange={this.handleBaconChange} />
  <span>Wrapper label tag</span>
</label>

<Toggle>
  <Choice id="" className="first-choice">On</Choice>
  <Choice style={{ color: red }}>Off</Choice>
</Toggle>

Inspiration

• http://instructure-react.github.io/react-toggle/
• http://www.queness.com/post/14585/toggle-switches-in-web-development

As you can't slide the toggle the component anyway touching the handle I wonder why this is needed. /cc @jpuri

I think we should have this, it will be useful esp. if number of options in select to too long.

This might required to update babel.

Basic example

<ComboBox>
  <Option value="apple">Apple</Option>
  <Option value="orange">Orange</Option>
<ComboBox>

Behavior

• By default next to input there is a caret which will show all options, but the developer can disable it.
• By default the autocomplete shows an not entry found placeholder. This placeholder can be customized by providing a NoEntryPlaceholder component as child.

<Autocomplete>
  <NoEntryPlaceholder>No entry found.</NoEntryPlaceholder>
  <Option value="apple">Apple</Option>
  <Option value="orange">Orange</Option>
<Autocomplete>

• By default the autocomplete is enabled, but can be disabled with an disabled property. When disabled is active the input cannot be changed & styling is indicating that this component is disabled.
• By default the autocomplete is not case-sensitive & it finds matches everywhere in the string, but the developer can overwrite the matching function by providing the property: filter (typeOf func)
• By default all matched options are shown, but the matchedOptions can be limited via a parameter: maxOptions
• If the property placeholder (text) it will be used as placeholder for the input.
• If the property defaultValue (text) is defined the initial input value is set & can be changed.

Behavior to be discussed

• Highlight the matched characters? Especially if we match parts of the string in the middle of it this can be really helpful to the user. Open question: how to do it with provided options? Inject a span?
  Could be an optional feature.
  http://jsfiddle.net/adamboduch/jhZ6E/
• If we limit the amount of options we might want to display a hint about more options after the last one. Could be an optional feature.
• onChange function
  Should the callback onChange fire once the user selected an option and return the value of the Option.
  or
  Should onChange fire once you type a new character into the input & we add a new callback onSelect for a selected option?

Internal structure

<div>

  <input type="text">

  optional: <span>carret</span> 

  <ul>
    <li>
      <Option />
    </li>
    …

    optional: no entry found placeholder
  </ul>

</div>

This is needed in case the screen width becomes smaller than the TextInput width & eventually the content will flow into the next line.

Add one more pseudoClass style disabledStyle. It can either leverage the same style injection as active or be updated based on the props (Probably the second one). Keep in mind to provide a version for the primary button as well.

Right now updating the styles will cause issues with the height calculations as the styles are cached & not updated.

• active style should be fixed
• the rounded corner causes rendering issues (make the toggle move 1px over the border)