```yaml
---
slug: stylizing-form-submits
published: 2006-10-28T00:00:00-08:00
description: Camino and Safari & styling type=submit
changelog:
  - on: 2020-02-23
    note: This was rescued from the archives of the old [felocity.org](https://web.archive.org/web/20050507121849/http://www.felocity.org/journal). As a result, many links in this piece were left pointing to archive.org destinations.
---
```

"The buttons aren't styling" I remarked as I stared at the page in Camino and Safari. Testing on the Mac platform has been the absolute bane of my existence as of late, mostly because for some reason, these browsers in particular are very protective of their form widgets. Coming back to [Cameron Adams' Entry on Styling Form Widgets](https://web.archive.org/web/20061218112920/http://themaninblue.com/writing/perspective/2004/04/28/), I found that none of the Macromedia examples were actually working for Camino/Safari, although they looked beautiful in Firefox. The submit button simply would not take the background settings. Interesting enough though, something of `input type="button"` styled perfectly.

However, the value attribute of the button wasn't getting passed in. For the legacy code around Gaia, we have forms with more than one possible "submit" for an action. The most common case of this is preview and submit buttons we traditionally use in the forums. This left us with two scenarios:

```html
<form id="myForm" action="some.php" method="POST">
  <input type="text" name="foo" value="" />
  <input id="submitBar" type="submit" name="action" value="bar" />
  <input id="submitBaz" type="submit" name="action" value="baz" />
</form>
```

or Button tags that wouldn't pass in their value to the PHP script (and shouldn't technically perform a submit either)

```html
<form id="myForm" action="some.php" method="POST">
  <input type="text" name="foo" value="" />
  <input id="submitBar" type="button" name="action" value="bar" />
  <input id="submitBaz" type="button" name="action" value="baz" />
</form>
```

The final solution ended up being something right down the middle and using JavaScript to make up for Safari / Camino's shortcomings. Starting with a default submit button, we can replace it with a input `type="button"` node, and add a bit of JavaScript to the `onClick` to make up for the stylized button's shortcomings. The first block of JavaScript goes into the head, and the second block can either go into an `onLoad` handler or at the end of the form tag, depending on how soon you need the replacement.

```js
////////
// SwapSubmit - A Tool for Stylizing Submit Buttons on All Browsers
// Licensed under CC-GPL-2.0
// http://creativecommons.org/licenses/GPL/2.0/
////////
var RJH_SwapSubmit = {
  replacedEles: new Object(),
  replace: function (formid, eleid) {
    if (typeof eleid == "string") var ele = document.getElementById(eleid);
    else var ele = eleid;

    if (typeof formid == "string") var f = document.getElementById(formid);
    else var f = formid;

    if (ele) {
      var o = this.build(formid, ele);
      var name = ele.getAttribute("name");
      var value = ele.getAttribute("value");

      var pn = ele.parentNode;
      pn.removeChild(ele);
      pn.appendChild(o);

      if (!document.getElementById(name))
        f.appendChild(this.buildInputField(formid, name));

      this.replacedEles[eleid] = new Object();
      this.replacedEles[eleid]["name"] = name;
      this.replacedEles[eleid]["value"] = value;
      this.replacedEles[eleid]["form"] = formid;
    }
  },
  build: function (formid, ele) {
    var o = document.createElement("button");
    var f = document.getElementById(formid);

    var oldOnclick = ele.onclick;
    o.id = ele.id;
    o.className = ele.className;
    o.onclick = function () {
      if (oldOnclick) {
        if (oldOnclick() == false) return false;
      }
      RJH_SwapSubmit.submitForm(this);
    };

    return o;
  },
  buildInputField: function (formid, name) {
    var o = document.createElement("input");

    o.setAttribute("type", "hidden");
    o.id = name;
    o.setAttribute("name", name);

    return o;
  },

  // ORIGIN: onClick of a button
  submitForm: function (ele) {
    var clickId = ele.id;
    var name = RJH_SwapSubmit.replacedEles[clickId]["name"];
    var value = RJH_SwapSubmit.replacedEles[clickId]["value"];
    var formid = RJH_SwapSubmit.replacedEles[clickId]["form"];
    document.getElementById(name).value = value;
    document.getElementById(formid).submit();
  },
};
```

```js
RJH_SwapSubmit.replace("FORMID", "SUBMITBBUTTONID");
```

Replace `FORMID` and `SUBMITBUTTONID` with the relevant values.

## Drawbacks
The largest drawback hands down is the addition of JavaScript. It's not something to depend on, and many steps were taken to ensure that the enhancement is progressive in nature.

Styled images will have to be styled to reflect the change from an input to a button node, and can be referenced via `button#idNameofElement` to apply all the necessary stylization.

This was rescued from the archives of the old [felocity.org](https://web.archive.org/web/20050507121849/http://www.felocity.org/journal). As a result, many links in this piece were left pointing to archive.org destinations.

Document

Link

code

Fence

////////
// SwapSubmit - A Tool for Stylizing Submit Buttons on All Browsers
// Licensed under CC-GPL-2.0
// http://creativecommons.org/licenses/GPL/2.0/
////////
var RJH_SwapSubmit = {
  replacedEles: new Object(),
  replace: function (formid, eleid) {
    if (typeof eleid == "string") var ele = document.getElementById(eleid);
    else var ele = eleid;

    if (typeof formid == "string") var f = document.getElementById(formid);
    else var f = formid;

    if (ele) {
      var o = this.build(formid, ele);
      var name = ele.getAttribute("name");
      var value = ele.getAttribute("value");

      var pn = ele.parentNode;
      pn.removeChild(ele);
      pn.appendChild(o);

      if (!document.getElementById(name))
        f.appendChild(this.buildInputField(formid, name));

      this.replacedEles[eleid] = new Object();
      this.replacedEles[eleid]["name"] = name;
      this.replacedEles[eleid]["value"] = value;
      this.replacedEles[eleid]["form"] = formid;
    }
  },
  build: function (formid, ele) {
    var o = document.createElement("button");
    var f = document.getElementById(formid);

    var oldOnclick = ele.onclick;
    o.id = ele.id;
    o.className = ele.className;
    o.onclick = function () {
      if (oldOnclick) {
        if (oldOnclick() == false) return false;
      }
      RJH_SwapSubmit.submitForm(this);
    };

    return o;
  },
  buildInputField: function (formid, name) {
    var o = document.createElement("input");

    o.setAttribute("type", "hidden");
    o.id = name;
    o.setAttribute("name", name);

    return o;
  },

  // ORIGIN: onClick of a button
  submitForm: function (ele) {
    var clickId = ele.id;
    var name = RJH_SwapSubmit.replacedEles[clickId]["name"];
    var value = RJH_SwapSubmit.replacedEles[clickId]["value"];
    var formid = RJH_SwapSubmit.replacedEles[clickId]["form"];
    document.getElementById(name).value = value;
    document.getElementById(formid).submit();
  },
};


RJH_SwapSubmit.replace("FORMID", "SUBMITBBUTTONID");


Stylizing Form Submits

```yaml
---
slug: sifr-and-floats
published: 2005-04-14T00:00:00-08:00
description: A flash of inline content in your (flash) replacement
changelog:
  - on: 2020-02-23
    note: This was rescued from the archives of the old [felocity.org](https://web.archive.org/web/20050507121849/http://www.felocity.org/journal) site. Writing on the internet was pretty different back then.
  - on: 2020-02-23
    note: Flash isn't a technology we should use anymore. Modern web fonts have made this article completely obsolete. It's a good thing.
  - on: 2021-02-20
    note: Flash is officially dead
---
```

I ran into a snag while preparing for the May 1 reboot, involving [sIFR](https://web.archive.org/web/20050507121849/http://www.mikeindustries.com/blog/archive/2005/02/sifr-2.0-release-candidate-4). I was attempting to replace a H2 element in the following two columns. They were designed to display side by side using opposing floats. However, someone pointed out that in Firefox for Windows only (now there's a new browser oddity for you) the flash text would cling to the top of the container element, in this case, content. Here was the initial CSS being used:

```css
#content #recentEntries {
  float: left;
  display: block;
  width: 200px;
}

#content #latestProject {
  float: right;
  display: block;
  width: 200px;
}
```

The problem was solved by making use of absolute positioning within a relative container. This solved the weird flash "flicker" that was occurring using the sIFR technique. The final CSS looked like:

```css
#content #recentEntries {
  position: absolute;
  left: 0;
  display: inline;
  width: 200px;
}

#content #latestProject {
  position: absolute;
  left: 256px;
  display: inline;
  width: 200px;
}
```

I don't think I will be the only person who ever goes the route of floats and runs into this peculiar snag. Once I complete the Felocity design, I will also put up the alternate stylesheet that fully demonstrates the flicker effect. In the meantime though, it's back to packing boxes. I've been preparing for a move to the San Jose area in the interest of not driving an hour every time I need to go to San Jose—which translates to 3-5 days a week. There's a good number of boxes lying around and in my room. My original plan of a "few short trips and one big trip" is quickly becoming anything but a few. It seems like you always have more stuff when it's in boxes.

This was rescued from the archives of the old [felocity.org](https://web.archive.org/web/20050507121849/http://www.felocity.org/journal) site. Writing on the internet was pretty different back then.

Flash isn't a technology we should use anymore. Modern web fonts have made this article completely obsolete. It's a good thing.

A flash of inline content in your (flash) replacement

#content #recentEntries {
  float: left;
  display: block;
  width: 200px;
}

#content #latestProject {
  float: right;
  display: block;
  width: 200px;
}


#content #recentEntries {
  position: absolute;
  left: 0;
  display: inline;
  width: 200px;
}

#content #latestProject {
  position: absolute;
  left: 256px;
  display: inline;
  width: 200px;
}


sIFR & Floats

```yaml
---
slug: tailwind-css-in-react-native
published: 2021-05-03T00:00:00.000Z
description: Tailwind's CSS classes in your React Native projects
changelog:
  - on: 2021-12-20
    note: I'm currently using [twrnc](https://www.npmjs.com/package/twrnc) which is an evolution of the tailwind-rn library. A pattern like `gust` is great for custom components, but right now, the React Native ecosystem almost always needs to pass style objects around.
---
```

React Native is very behind the web when it comes to UI libraries. There’s two likely reasons for this: CSS on the web is easy and the object known as `StyleSheet` in React Native is not.

At a fundamental level, the syntax of `StyleSheet` causes a lot of problems. It looks like CSS (the kind you’d use in React’s `style` prop), it acts like CSS (most of the time) just like you’d expect in a browser, but then you encounter one of dozens of scenarios where React Native takes the CSS specification and yeets it out the nearest window.

- Shadows are a custom object syntax instead of a conversion of `box-shadow`
- Random elements such as `ScrollView` introduce custom non-standard props such as `elevation`, but also only for specific platforms
- You get flexbox. Only flexbox. Everything flexes. Everything is boxes. Except for the `flex` property which has decided it is not actually `flex` as you’d expect but just a number that translates to a percentage. But not a useful number-to-percentage like `55` meaning `55%`. Instead, you get an alternate universe number that is expressed as a ratio based on the sum of all flex properties on sibling nodes. It’s a universe where `flex:1` means both `100%` and `50%` based on elements outside of its rendering tree. /rant

Yes, a lot of this will be fixed over time as React Native continues to improve on its style interpreter, but we are still converting from CSS to platform-specific layout calls. I don’t think we’ll ever reach parity, but I’d also like to avoid the programming equivalent of “hammering my thumb” every time I lay things out in a mobile app.

The truth is, what I want is something as easy as [Tailwind CSS](https://tailwindcss.com/) in React Native. If you haven’t tried Tailwind yet, you should. It’s trivial to make something look good, and it’s adaptable enough withstand design changes. In React Native, there's a few really solid options:

* **tailwind-rn**([github](https://github.com/vadimdemedes/tailwind-rn), [npm](https://www.npmjs.com/package/tailwind-rn)) is the OG of Tailwind in your React Native projects. It works by converting the Tailwind styles into JSON, which is memoized in your app on access. Because it tries to be only a translation layer between systems, complex behaviors such as breakpoints and React Native's Appearance are not supported out of the box.
* **tailwind-rn-gust** (_archived_ [github](https://github.com/jakobo/tailwind-rn-gust), [npm](https://www.npmjs.com/package/tailwind-rn-gust)) extends the `tailwind-rn` library by adding utilities for custom component creation. By introducing a React Component generator, it's possible to add additional props to turn "on" flags inside of a call to `tailwind-rn`'s style generator. _However, I wouldn't recommend this, as the components add an additional layer of complexity once you want to use `Animated.View` or other 3rd party components that want to leverage the `style` prop for stylistic behavior.
* **twrnc** ([github](https://github.com/jaredh159/tailwind-react-native-classnames), [npm](https://www.npmjs.com/package/twrnc)) Is what I'm currently using and it leverages [Tailwind's JIT Compiler](https://v2.tailwindcss.com/docs/just-in-time-mode) to remove the built steps inherent in other Tailwind-bridging systems. Out of the box, it uses React Native's hooks for figuring out screen sizes and appearance, making it easier to use normal Tailwind prefixes such as `lg:text-xl`.

Originally, this post focused on `tailwind-rn-gust`, but I think it's becoming more clear that until there's an official Tailwind for React Native, `twrnc` is going to be the truest-to-Tailwind experience you'll find on the platform.

Instead, here's how you'd accomplish something like a rich "press" interaction using `twrnc`. (You can also put both styles into a single `tw.style` call, but I find it easier to read leveraging the array syntax supported for multiple style objects.)

```jsx
<MyComponent style={({pressed}) => [
  tw`bg-red-500`,
  tw.style({
    "bg-blue-500": pressed
  })
]} />
```

The best thing about the `tw` helper is that it's built for generating `style` objects, meaning it'll work with Moti, Reanimated 2, and many other component libraries that focus on the `style` prop.

## Gust Archived
And so, with great alternatives out there, `gust` is archived. The [entire library](https://github.com/Jakobo/tailwind-rn-gust) is only 159 lines and is easy to port into your own existing React Native project if you need the features. However, until we see something like a native `className` in React Native, the `style` tag is going to be the default operating mode for rich styles, animation, and state based effects.


I'm currently using [twrnc](https://www.npmjs.com/package/twrnc) which is an evolution of the tailwind-rn library. A pattern like `gust` is great for custom components, but right now, the React Native ecosystem almost always needs to pass style objects around.

Tailwind's CSS classes in your React Native projects

<MyComponent style={({pressed}) => [
  tw`bg-red-500`,
  tw.style({
    "bg-blue-500": pressed
  })
]} />


CSS

2021

A Guide to Tailwind CSS in React Native

2006

Stylizing Form Submits

2005

sIFR & Floats