No selectors for CSS?

[syranide]

https://github.com/reactjs/react-future/blob/master/04%20-%20Layout/Inline%20Style%20Extension.md#no-selectors

What about hover (etc) styles for descendants? This seems like a major issue with the current approach, unless I'm missing something.

.button:hover > .label {
  top: 1px;
  font-weight: bold;
}

Also, if you're really intending for these to be supplied as styles, as opposed to classNames, I'm pretty sure that would destroy the overall performance.

[sebmarkbage]

That's the intension. So, let's make React and applying styles super fast. :)

[syranide]

@sebmarkbage Full speed ahead! 👍

[jacobrask]

I'm not sure I understand what the suggestion is for pseudo classes and descendants?

I built my own library for the use case outlined in the Inline Styles proposal, since I saw objections to that proposal in some React tickets. You've probably already thought more about this than me, but if you're interested, it works like this:

var className = mx.style({
  color: "yellow",
  padding: 10, // optional auto units
  ":hover": { color: "black" }, // object value, treat key as selector
  "> span": { fontWeight: "bold" } // object value, treat key as selector
});

The function adds rules to a stylesheet and returns a class name.

.mx__0 { color: yellow; padding: 10px }
.mx__0:hover { color: black }
.mx__0 > span { font-weight: bold }

[syranide]

@jacobrask I think the idea is to forgoe selectors entirely in-favor of making everything explicit in components, if a sub-component needs to be hover-styled when the parent is hovered. It should have an associated prop and should define its own style, the parent shouldn't define the style for the child (to give an example).

[parshap]

@jacobrask I think the idea is to forgoe selectors entirely in-favor of making everything explicit in components, if a sub-component needs to be hover-styled when the parent is hovered. It should have an associated prop and should define its own style, the parent shouldn't define the style for the child (to give an example).

You can't have hover styles without the css pseudo selector :hover. Selectors are also needed to style the shadow dom and pseudo elements. An alternative is to use DOM event handlers and modify the style attribute (e.g., on hover), but it is not possible to implement many css features this way (e.g., :visited, :first-line).

What @jacobrask proposes is something I've thought about before and it makes a lot of sense to me: provide an api to declare those missing bits of css in javascript and "compile" them to generated class names and css that is added to the dom. This can still be done through the style prop.

There is also an opportunity for React to optimize the generated class names and css for payload size and polyfill some css features (e.g., :nth-child() in ie8).

[vjeux]

For hover you can implement it with events such as onMouseOver and change your state.

For visited and first-line it's indeed not possible in pure CSS but those are --extremely-- rare. It's okay to use CSS for those kind of rules we cannot do in pure JS.

In this proposal, we don't want to support ::before and ::after, styling shadow dom ... You don't need those in a pure React-world because it's super easy to shape the DOM the way you need it for styling.

On Nov 6, 2014, at 2:54 AM, Parsha Pourkhomami notifications@github.com wrote:

@jacobrask I think the idea is to forgoe selectors entirely in-favor of making everything explicit in components, if a sub-component needs to be hover-styled when the parent is hovered. It should have an associated prop and should define its own style, the parent shouldn't define the style for the child (to give an example).

You can't have hover styles without the css pseudo selector :hover. Selectors are also needed to style the shadow dom and pseudo elements. An alternative is to use DOM event handlers and modify the style attribute (e.g., on hover), but it is not possible to implement many css features this way (e.g., :visited, :first-line).

What @jacobrask proposes is something I've thought about before and it makes a lot of sense to me: provide an api to declare those missing bits of css in javascript and "compile" them to generated class names and css that is added to the dom. This can still be done through the style prop.

There is also an opportunity for React to optimize the generated class names and css for payload size and polyfill some css features (e.g., :nth-child() in ie8).

—
Reply to this email directly or view it on GitHub.

[emmagamma]

@vjeux that doesn't seem very elegant... browsers already have functionality implemented for managing hover state in css, why not tap into what's already there by default anyway?

It seems to me that there are probably multiple ways of simply providing some decent JS sugar to utilize things like :hover. Obviously there are lots of react styling frameworks now, but it doesn't seem totally unreasonable to expect a 'React way' of doing this included in the library that we can all (read: 'most') agree on... lol

[geyang]

What about for layout options, such as flex box and position relative? Say I want to have a container element with the display: flex-box and want the child elements to have flex: 0 0 auto. I would prefer to have these styles applied by the parent element and be grouped together, instead of splitting it between the parent and the child.