[TextView] [CSS] text-transform support?

[grabbou]

Hey,
Given recent updates to text-decoration implementation, I was wondering if this would've been in scope of React Native? I know we can pretty easily do this:

<Text>{'something'.toUpperCase()}</Text>

but having universal apps in mind, basic support for upperCase and lowerCase would be nice.

<Text style={{textTransform: 'uppercase'}}>something</Text>

Depending on how Text is rendered, either basic NSString bindings below might be used or plain JS methods:

• capitalize - NSString -capitalizedString
• uppercase - NSString -uppercaseString
• lowercase - NSString -lowercaseString

If the answer to my question is Yes - I am happy to add in this in a PR.

[sahrens]

Not sure I understand the request - what do you want exactly that you can't do with plain JavaScript?

On Jul 22, 2015, at 11:22 AM, Mike Grabowski notifications@github.com wrote:

Hey,
Given recent updates to text-decoration implementation, I was wondering if this would've been in scope of React Native? I know we can pretty easily do this:

{'something'.toUpperCase()}
but having universal apps in mind, basic support for upperCase and lowerCase would be nice. If the answer to my question is Yes - I am happy to add in this in a PR.

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

[grabbou]

Well, just wondering what are the pros/cons of implementing textTransform so we don't have to use plain JS (it's mainly for the sake of CSS-like approach as I am happy with plain JS anyway). Not a real issue, feel free to close if no point in implementing.

[sahrens]

Our general philosophy on RN is not to provide APIs unless they both
provide clear value and can't be reasonably done otherwise. Since you can
easily use JS to do this, I don't think we'll provide specific support for
it.
On Wed, Jul 22, 2015 at 1:10 PM Mike Grabowski notifications@github.com
wrote:

Well, just wondering what are the pros/cons of implementing textTransform
so we don't have to use plain JS (it's mainly for the sake of CSS-like
approach as I am happy with plain JS anyway). Not a real issue, feel free
to close if no point in implementing.

—
Reply to this email directly or view it on GitHub
#2088 (comment)
.

[brentvatne]

Adding on to @sahrens' comment above, if anyone comes across some use cases where there is a significant benefit to doing this in a style rather than with JS, please post them here so we can consider!

[ide]

+1 strongly in favor of keeping code in user space.

[mxkxf]

Just stumbled upon this thread from Google; I'd say that adding textTransform support is necessary to separate your concerns. As others have pointed out, you can do this in JS, however what's the point in having a class full of styles and then having to use JS to force caps.

Say a couple of months down the line you don't wish to use caps any more then you've got to trawl through your app removing all the references to it. Having this as a style would alleviate that problem.

[jonlong]

@brentvatne Just dropping in to echo @mikefrancis's comments, which are right on the money in my experience.

Here's a quick example from a project I'm working on. This is the same screen with two different design options — labels rendered in title case, or labels rendered in small caps.

There's two things that make a textTransform property attractive to me in this case. The first is that I think there's a semantic difference between setting the actual content of <Text> to CITY rather than City. If preserving that semantic state is important, then I think this becomes a matter of style.

The second is to @mikefrancis's points around separation of concerns and maintainability. If it's a matter of style, then it makes sense to manage it with CSS.

Here's a sample of the JSX for both of those views:

Title Case:

<View { ...style('field') }>
  <TextInput
    { ...style('input') }
  />
  <Text { ...style('label') }>Address Line 1</Text>
</View>

<View { ...style('field') }>
  <TextInput
    { ...style('input') }
  />
  <Text { ...style('label') }>Address Line 2</Text>
</View>

<View { ...style('field') }>
  <TextInput
    { ...style('input') }
  />
  <Text { ...style('label') }>City</Text>
</View>

<View { ...style('field') }>
  <TextInput
    { ...style('input') }
  />
  <Text { ...style('label') }>State</Text>
</View>

<View { ...style('field') }>
  <TextInput
    { ...style('input') }
  />
  <Text { ...style('label') }>Zipcode</Text>
</View>

And the same code modified for small caps:

<View { ...style('field') }>
  <TextInput
    { ...style('input') }
  />
  <Text { ...style('label.upper') }>{'Address Line 1'.toUpperCase()}</Text>
</View>

<View { ...style('field') }>
  <TextInput
    { ...style('input') }
  />
  <Text { ...style('label.upper') }>{'Address Line 2'.toUpperCase()}</Text>
</View>

<View { ...style('field') }>
  <TextInput
    { ...style('input') }
  />
  <Text { ...style('label.upper') }>{'City'.toUpperCase()}</Text>
</View>

<View { ...style('field') }>
  <TextInput
    { ...style('input') }
  />
  <Text { ...style('label.upper') }>{'State'.toUpperCase()}</Text>
</View>

<View { ...style('field') }>
  <TextInput
    { ...style('input') }
  />
  <Text { ...style('label.upper') }>{'Zipcode'.toUpperCase()}</Text>
</View>

In the second version, a simple design change requires a lot of updates to the template content itself. Even going the "Find and Replace" route would be pretty tricky.

I also find that in many scenarios, small caps tend to look better with a little bit of letterSpacing applied. In that case, I'd also end up modifying my styles too.

IMO, it's a lot of overhead for a common use case, and something that could go from all this to a single line in a stylesheet with textTransform support.

[brentvatne]

Another option is to wrap the Text component with one that adds the capabilities that you want, so then if you have the uppercase prop set on it, it will toUpperCase() everything. Can you create an issue on ProductPains that includes the great description of the problem that you just stated @jonlong?

[jonlong]

@brentvatne sure thing — done: https://productpains.com/post/react-native/texttransform-should-be-available-in-stylesheet/

[afilp]

+1 I really need this on a specific app that uses it a lot. Thanks!

[dwilt]

I'm in a situation where I can't access the Text tags directly that I want to put uppercase because I'm dynamically generating them - thus, applying conditional JS is much harder than just passing in styles.

[vanpoos]

+1 for me as well. I am a designer which likes to develop UI's when I get the chance. Unfortunately, my Javascript skills are not great, yet. Having a more CSS centric approach to building UI's would really help me. Granted I should probably just learn Javascript and be done with it. However, I am sure there are others like me which like to code UI's but have not reached the level where they can use Javascript as an alternative. My 2 cents.

[ethanshar]

+1 it's clearly a style concern. it was a concern on the web and now on mobile.
I wouldn't want to worry about conditionally upper-casing text of a button component every time I use it but rather specify its style exactly like color or font-size, especially when I have to support two different style for the same component, each one with different text-transform style (Android vs iOs)

[leeight]

+1

[guiherzog]

+1

[neiker]

+1

[stephenmeszaros]

+1

[mjracca]

+1

[amazingandyyy]

the advantage of css "class" is to not duplicate codes.

I strongly think we need "whole supports" css system for RN.

[herlon214]

+1

[stphnsn]

+1

[hbierlee]

+1

[jonlong]

For all the folks posting "+1" feedback in this thread, consider that it triggers a notification (often an email) not just for the React Native team, but for anyone subscribed to the thread (which can easily be several hundred people at once).

On behalf of those who'd like to keep tabs on this thread's progress without receiving daily "+1" emails, please consider using GitHub's reaction feature — it's a nice new way of registering +1-style feedback without blanket notifications to an entire subscriber list:

[manfredxu99]

+1

[alexpriceco]

So is this happening, or is it just closed and left to die? 😕

[dotnetwise]

Why closing this? It seems so immature decision to not support obvious CSS properties and to duplicate the code for cross-universal apps!
This is a very easy to be implemented native but very hard to duplicate and take care of it in every single app.

[kennethpdev]

+2

[sahrens]

It seems like there is enough desire here that if someone wants to submit a PR for this, we'd probably take it.

[rikur]

+1 We're building components that work in both web and react-native and using JS to transform text in web feels so wrong.

[nmerchant]

I'm somewhat surprised that serious developers on a project as big as React Native have suggested using JS to modify text strings when text-transform is a pretty standard and commonly used CSS property. How is this still missing 3 years later?

[kennethpdev]

+3

[SofiaChuquin]

+1

[jayporta]

+1

[philtrep]

@nmerchant Especially since there's a PR for it by @TomSwift . Maybe @sahrens can reevaluate?

[TomSwift]

@nmerchant @philtrep I believe we're really close to having my PR merged. It's a slower process than I'd realized.

[nmerchant]

@TomSwift that's only half the solution though...still need Android support :( but nevertheless, bless you for taking this up.

[neiker]

[leozzitowned]

+1

[achubai]

+1

[jelenajjo]

+1

[xabree]

+1

[rikur]

+1

[melihcaliskan]

+1

[gustavopradoreis]

+1

[neyosoft]

+1

[exit99]

+1

[MrLoh]

I'm not sure this weird +1 posting will achieve anything, except alerting everyone who is still subscribed to this. There are emoji reactions on github now and since this has been closed it would probably make much more sense to open a new issue about android support for this. What's really needed is someone with the needed Android experience to create a pull request though.

[mrruby]

+1

[ghost]

+1

[MrLoh]

@mrruby @JuliaLuk if you want this to happen, help to bring forward a pull request, or sit in silence and subscribe to this issue. +1 spam is not helping this to come forward at all, it will only lead to people unsubscribing from this issue.

[kennethpdev]

+10

[guruganeshm-prft]

+1

[rikur]

Seems to be added in 0.56!

8621d4b