cozy / cozy-ui Goto Github PK

When you scroll from the bar at the bottom, you can scroll the html container and then the layout is broken.

We should have default white background color and black text color to avoid being overwritten by browser styles. In the dark mode of Firefox, the background will be #000 by default and text will be white. So I would suggest to add these default styles directly on html:

html {
  background: white;
  color: black;
}

Not an issue but information:

An attempt to make things more consistent between Cozy apps was to provide this stylesheet in every application. https://github.com/cozy/cozy-files/blob/master/client/app/views/styles/_cozy.styl
That way we made all the cozy buttons behave the same way. They are not really pretty but it makes easier for users to learn the Cozy apps.

normalize.css sets the font-familyof certain elements, for example buttons. In cozy-ui, we rely on inheritance to propagate the default font.

This means that buttons with no extra font-declaration get the default sans-serif instead of our Lato. There are actually a few places in our v3 UIs where the wrong font is used, most notably the selection bar in files.

Not sure of the best way to fix this. Should we just declare the font-family on a lot more elements in the default styles? Ping @GoOz and @m4dz for input.

In order to allow giving special style to a spinner so you don't have use tricky selector like [class^=coz-spinner]

Suite à l'atelier de jeudi et surtout à des discussions avec @kosssi et Claire, j'ai pris conscience que nous souffrons d'un manque d'alignement quant à l'évolution de cozy-ui, d'où un quasi status quo. L'objectif de cette issue est donc d'établir une vision claire pour tous et d'en discuter les détails d'implémentation.

Quels sont nos besoins ?

1. Arrêter de polluer nos composants applicatifs avec des className={classNames(styles['pho-truc-bidule'], styles['pho-machin-chose']} : l'un des procès fait à React est que JSX remettrait en cause le principe du "separation of concerns" en mélangeant HTML, CSS et JS dans le même fichier. Mais ce principe ne dit pas qu'il faut forcément séparer les langages, mais simplement d'isoler dans des portions de code séparées tout ce qui concerne un aspect particulier, une facette, du code. La bonne façon de faire cette séparation avec React est donc d'isoler dans des composants dédiés tout ce qui concerne l'aspect visuel de l'app (structure HTML requise + CSS, qui peut rester dans des fichiers séparés d'ailleurs) et d'utiliser ces petits composants visuels pour construire le markup des composants applicatifs. Cela améliorerait également la lisibilité du code.

2. Régler nos problèmes de layout : plusieurs bugs nous posent pb, notamment sous Safari. Je ne sais pas exactement où en est @GoOz dans ses tentatives de résolution de ces pbs, mais nous devons trouver une solution et surtout disposer enfin de composants de layouting communs. Je vous invite donc à partager vos opinions et surtout l'avancée de vos travaux respectifs sur ce sujet.

3. Disposer d'une bibliothèque de composants d'UI avancés (comprendre : embarquant du comportement et donc du JS en plus de l'aspect visuel, donc DatePicker, AutoComplete, etc...). Jusqu'à présent nous nous sommes débrouillés en implémentant nos propres composants (mais sans penser trop à l'accessibilité :/) ou en utilisant des paquets type react-autosuggest qui doivent être adaptés au thème cozy à chaque fois. Cela nous a pris beaucoup de temps, et certaines applis comme cozy-bank ou cozy-santé vont nécessiter des composants que nous n'avons pas encore.

4. Offrir à la communauté un moyen d'utiliser autre chose que React et/ou la lib de composants d'UI que nous pourrions choisir, et donc exposer par un moyen quelconque ce qui fait le thème cozy, afin que ces développeurs puissent aisément thémer la lib de leur choix.

Ma proposition

Je vois cozy-ui en 3 couches :

1. Le thème cozy : il nous faut exposer ce qui fait le visuel cozy sous forme de variables, afin de répondre aux besoins 3 et 4. C'est la condition pour pouvoir thémer facilement une lib externe de composants, quelle qu'elle soit. Et cela pourrait même nous permettre d'intégrer ce thème dans une appli Drive native si la nécessité s'en faisant sentir...

Ces variables doivent comprendre :

• les couleurs bien sûr, mais aussi tout ce qui concerne les polices,
• les styles de bordure, d'ombres portées, adaptées à différentes tailles standard (par ex. de boutons) : small, medium, large
• tout ce qui concerne le rythme vertical de la page : margins, paddings, line-heights, ...
  A titre d'exemple, voici ce à quoi j'étais arrivé avec Bosonic. C'est évidemment un boulot à faire en étroite collaboration avec Claire, et qui bien sûr ne se fera pas en un jour : il a d'ailleurs déjà été attaqué par @ptbrowne et il conviendrait de s'appuyer sur son travail. Bien que comme @CPatchane, l'avocat des standards que je suis préfèrerais une solution à base de CSS Variables (ce qui nécessiterait néanmoins de pouvoir aussi exporter ces variables sous forme de JS(ON) ), la solution JSON retenue me va très bien dans un premier temps.

2. Une lib de composants visuels pour répondre au point 1. Je parle ici de composants encapsulant des comportements "standards" en CSS, et qui ne contiennent donc pas (ou très peu et de façon exceptionnelle) de code lié au DOM (gestion d'events, ...) : ce ne sont pas des composants avancés type DatePicker que nous n'avons pas intérêt à recoder nous même. Rebass offre quelques bons exemples : un composant Circle pouvant être utilisé pour les avatars, un composant Arrow utile pour les menus, etc... On peut aussi imaginer un ensemble de composants implémentant des patterns spécifiques avec flexbox, comme CenteredPrompt, FeatureList ou Stream... les possibilités sont nombreuses, et c'est là où un master of CSS tel que @GoOz pourrait s'éclater je pense ;) Une bonne façon de lancer ce chantier serait de s'y mettre à plusieurs un vendredi aprem' pas trop chargé (milieu de sprint plutôt donc).

C'est également dans cette couche que viendrait nos composants de layouting. Mais il nous faut pour cela résoudre les pbs cités dans le point 2, et j'attends donc un état des lieux précis et des solutions possibles de la part des personnes directement concernées (@GoOz ? @ptbrowne ? @kosssi ? d'autres ?)

3. Une lib de composants d'UI avancés (c'est le besoin 3). Comme je le disais précédemment, inutile à mon avis de réinventer la roue, d'autant plus que c'est un boulot énorme pour faire bien et accessible. @kosssi lorgnait sur react-toolbox, et pour avoir suivi de près le monde des libs de composants d'UI ces dernières années, je pense également que c'est la meilleure solution aujourd'hui. Son seul défaut est qu'il impose pour l'instant d'utiliser sass pour créer son thème, mais gardons à l'esprit que ce ne sera jamais que du glue code entre nos variables et la lib, ce n'est donc pas si grave. Il n'est bien sûr pas envisageable (ni souhaitable) de transitionner toutes nos apps d'un coup vers cette lib, @kosssi se proposait donc de POCer son utilisation sur une appli encore à l'état d'ébauche, en l'occurence cozy-santé. Si la création d'un thème ne pose pas de pb particulier et dès que ce thème est propre et stable pour cozy-santé, nous pourrons l'intégrer dans cozy-ui et petit à petit dans les apps, selon la règle du boy scout.

Y a t-il des points de contention que j'aurais omis de mentionner ? Certains ont-ils des oppositions formelles ? J'attends vos réactions à cette proposition, mais n'oubliez pas de lui donner 5 minutes ;)

I have done an Icon component for the MAIF project.

Example usage :

<Icon icon='out' />
<Icon icon='home' />
<Icon icon='phone' />

The icon's color comes from the surrounding text and you can change it via CSS.

I see that in Drive, you use background-images to display icons. The benefit I see of this approach is that you can change the icon of a button without changing the HTML/JSX code. The downside is that it is not possible (?) to color the image from the surrounding text.

The <Icon /> approach is very similar to the Font-Awesome way of doing things so external developers may be familiar with it, and you do not need to add CSS for your component to display an icon. This allows for less custom code, more reliance on cozy-ui and more coherent designs.

What do you think of this component and do you think it could be an addition to cozy-ui ?

[EDIT]
When I say "icon", I am talking about this kind of icons :

Not this kind

I started to read about managing CSS properly, but I haven't pushed it yet. I heard of "BEM" methodology, and siblings. Do you have any opinion on that kind of methodology? Do you think it would be worth it to learn and use one?

At the moment in my app, I have:

import Modal, {ModalContent} from 'cozy-ui/react/Modal'
import Button from 'cozy-ui/react/Button'
import {Tabs, TabPanels, TabPanel, TabList, Tab} from 'cozy-ui/react/Tabs'

I think it would be better if we could do :

import {
   Modal, ModalContent,
   Tabs, TabPanels, TabPanel, TabList, Tab,
   Button
} from 'cozy-ui/react'

This way we hide the internal structure of cozy-ui.

Dialogs are constraint to ()vh (

ModalTitle, ModalContent, ModalSection can take a classname props to override default style, but not the ModalCross.

It can be usefull to have this pros in the ModalCross too.to avoid this kind of trick to adjust styles of this cross.

    [class*="coz-btn-modal-close"]
        top: 4px
        right: 4px

As shown on the Styleguide : https://ptbrowne.github.io/cozy-ui/react/#spinner

• It does not show its true color : #196 (comment)
• Sometimes size is not working (property width/height being shadowd by .coz-spinner) -
• noMargin seems to do nothing.

We need to have webpack.config.cozy-ui.js files. I think it should not be the responsibility of an application to know how cozy-ui is coded so that it should know which loaders are necessary.

One solution would be to ship a built version on npm.

It would then be hard for people hacking on cozy-ui through another application to use it since they would have to build each time they make a change. Maybe cozy-ui should have a webpack file ready for people linking directly and wanting to hack on cozy-ui while they develop their application. This way, a user wanting to hack on cozy-ui could do:

const webpackConfig = merge(
  ...,
  ...,
  require(`cozy-ui/webpack`)
)

temporarily in their file ?

What do you think ?

Discussion about that : webpack/webpack#378

We need intelligent pickers for many selectors:

• date
• time
• datetime
• color

Those must display localized, intelligible contents (such as a formatted date string) and display a popover picker when clicked.

We should add a aria-checked support for the 3 defined values true, false, mixed (see https://www.w3.org/TR/wai-aria/states_and_properties#aria-checked) here : https://github.com/cozy/cozy-ui/blob/master/src/stylus/cozy-ui/app/forms.styl#L73-L84.

This way, we can support the checkbox as well as the aria-checked state.

Tip: this one shuld be converted to webcomponent when we add support for them.

I think it would be good to standardize the way we do onboarding screens. We have several screens like that in labs apps. Do you also have that in Photos, Drive ?

Introducing .hero, .hero__icon, .hero__title, .hero__subtitle could be a good way to do that.

Add a direct link to the component styleguidist page in the component readme.

The Bosonic project aims to be a nice components library, base on the standards WebComponents, and use some shinny feature such as CSS variables for tweaking and theming.

We should rely on it to declares our reusable components, such as modals, pickers, forms inputs, etc.

Par défaut les boutons sur la modale en mode mobile ne sont pas optimaux :

Je propose de les rendre comme ça :

Des remarques ? @Claiw @GoOz ?

Right now you need to have one spinner per color. On cozy-maif, I removed the fill attribute on the SVG file to be able to color the spinner with fill in CSS.

https://gitlab.cozycloud.cc/labs/cozy-maif/commit/826447c2e4f4e0670a93507a7aeb258a42d36105

What do you think of this approach ? I can make a PR.

Actuellement on ajoute dans chaque projet ses propres variables JS pour les couleurs alors que l'on a un référentiel dans palette.styl.

Nous devrions pouvoir récupérer facilement une variable :

import palette from 'cozy-ui/palette.json'
import { Icon } from 'cozy-ui/react'
<Icon icon='album-add' color={palette['cool-grey']} />

Proposition:

1. Continuer comme on fait
2. Créer rapidement des variables dans un fichier JS (du coup duplication des variables js/stylus)
3. Créer un palette.json avec les variables puis les importer dans stylus et dans un fichier JS

• the paperplane icon is not shown
• the grey and white spinners are blue

I think it would be good to add that to the default styles.

body {
  -moz-osx-font-smoothing: grayscale;
  -webkit-font-smoothing: antialiased;
}

To be clear : when the font is bolder (and ugly), font-smoothing is not active.

Create frameworks agnostics and accessibles components likes popovers and modal boxes.

Those plugins must come with their default styles (header / footer / buttons / etc) to keep appearance consistent.

It could be great to remove the padding-right of 10% on the nav component (and put it on nav-item if needed). For me, this is some useless space which can't be used.


In this last picture, the first title would be on one line without this space.

Hello !

J'ai recontré un soucis sur l'app "Mon logis", un intent est chargé dans une modale, qui a été fixée a 700px de large par le développeur. Le contenu passe donc systématiquement en mode mobile dans cette modale.

Est-ce qu'on pourrait ajouter à la doc les recommandations pour des modales qui seraient en accord avec nos breakpoints, pour éviter ce genre de soucis ?

Merci !

Should we use a base CSS framework? If yes, there is only one good candidate: http://www.knacss.com/

In cozy-edf, I needed to get a ref on the .coz-modal part of the Modal to display the inter-app modal in it. Since there is no way to attach a ref callback in the Modal, I had to replicate the structure of the Modal.

https://gitlab.cozycloud.cc/labs/cozy-edf/blob/master/src/components/IntentModal.jsx

What do you think of a modalRef prop to be added to <Modal /> ?

Add Lato font on Styleguidist since otherwise it feels different than our apps.

Icon should forward at least onClick and maybe all its props to the underlying <svg /> it is a shortcut component.

Hi,

I would like to put a Spinner in a Button.
My first guess was to add it directly as children:

<Button onClick={onClick}>
  <div>Load More {isLoading && <Spinner color="white" />}</div>
</Button>

But the children props is defined as a string. Should it be changed? Or should I changed my way of working?

cf. https://github.com/cozy/cozy-ui/blob/master/react/Button/index.jsx#L18

There is no doc for the Alerter component in styleguidist.

System may offer a notification center that can be displayed as a simple panel.

When a modal opens-up on a scrolled down window, the window scrolls up to the top.

Components that can open intents with default styling would be useful.

• IntentButton

Already been implemented in Bank and Drive

$ cozy   rg 'IntentButton'
bank/src/components/IntentButton/index.js
1:import IntentButton from './IntentButton'
4:export { IntentButton }
6:export default IntentButton

bank/src/components/IntentButton/IntentButton.jsx
10:class IntentButton extends React.Component {
50:export default IntentButton

drive/src/drive/components/Intent.jsx
9:class IntentButton extends React.Component {
74:export { IntentButton }

• IntentModal

Should take the 80% of the screen in desktop and 100% on mobile

See https://gitlab.cozycloud.cc/labs/cozy-bank/blob/master/src/components/IntentButton/Intent.styl

font-size is redefined here : https://github.com/cozy/cozy-ui/blob/5e092f964de2c2268a004250bac5eab019a5d5a0/stylus/tools/mixins.styl

It basically convert the px in em so that your px are dependent on the root font size. The primary goal dixit m4dz was to help developers that do not know about rem to have a design that was responsive and reactive to the change of root font size.

I think it is a very surprising behavior of cozy-ui, that rem fit this goal perfectly, and it does not teach people how to use properly rem.

I would be in favor of removing this mixin.

I open this issue to discuss about this property which is currently badly implemented for me according to these points:

• The naming, withCross just means nothing for me, it would be preferable to have something named like withClosingButton IMHO
• The behaviour. For me, this property should just decide if the modal should display a closing button or not and THAT'S ALL. I really think that this property should not affect the key listener and the click outside listener used to close the modal. For this specific need, we could use a better property named disallowClosing which is more appropriate for here to my mind.

#my2cents

houston we have problemz

We use JS spinners, because they are convenient (and easily customizable). But a CSS version would be very nice!

We have this component in Bank and Santé. Current behavior :

• Menu should take all screen on mobile
• Menu should be opened from the selector on Desktop
• It should have a small chevron to the right
• There should be an Overlay when opened

So it seems it is quite like a Menu except that it has an overlay and a different behavior on mobile. What do you think @GoOz ?

I am open for a different name.

Previously 's font was Lato. It is no longer the case.

I suggest:

• Export normally all components and also the main component as default

  import { MainComponent } from 'cozy-ui/react/Component' // should work
  import MainComponent from 'cozy-ui/react/Component' // should work
  import MainComponent, { other1, other2 } from 'cozy-ui/react/Component' // should work
  import other1 from 'cozy-ui/react/Component' // should NOT work

• Put clearly in the related documentation what is "importable" by the developper

List are common in use. We may have a component that can handle lists (creation / management), focusing on perfomance and cell-reuse.

See: cozy/cozy-drive@25d6bc6

The UI of the browser must disappear when we scroll.

Bootstrap comes with two versions: a CSS stylesheet and a LESS version. There are also port for other CSS pre-processor.

I think it's a good practice to build first a bunch of mixins, then to build a default stylesheet based on them: you can use the default style, and customize your own style with the mixins.

Also it makes HTMl easier to read, because you use semantic class names (your own) rather than ".cozy-btn", and so on.