Slide 1

Slide 1 text

⚛ ! I'm literally giddy to be at this conference. I'm love the community around React and how aggressively it's pushing the web forward.

Slide 2

Slide 2 text

I'm excited to give out a bunch of hi-ﬁves.

Slide 3

Slide 3 text

I'm here to talk about inline styles—or styling React components with JavaScript. In November, Vjeux talked about the technical beneﬁts of CSS-in-JS and how it was improving their development story.

Slide 4

Slide 4 text

And the idea erupted.

Slide 5

Slide 5 text

That deck has over 400k views on SpeakerDeck. And it acts as the inspiration for a growing list of libraries. When I proposed this talk, it still felt like "one weird trick for styling your React components".

Slide 6

Slide 6 text

As with JSX, this idea was not well received.

Slide 7

Slide 7 text

“It's time to truly learn CSS.” This is a refrain I see a lot from those put oﬀ by the ideas of JavaScript styles.

Slide 8

Slide 8 text

This is bullshit It sells books. But it isn't true. There's never been a better time not to learn CSS. If you can style an app without learning CSS. Don't React, has empowered us with a performant option that is totally modular and not selector-based.

Slide 9

Slide 9 text

– J E R E M Y A S H K E N A S " R I S E O F T H E T R A N S P I L E R S " “Someone is going to unify these three different syntaxes and write a language that just addresses the web-platform directly and it's going to be insanely popular.” Jeremy Ashken gave a talk recently, at addressed this tangled relationship between HTML CSS and JS. [quote] https://www.youtube.com/watch?v=DspYurD75Ns&feature=youtu.be&t=2560 This is what I love about React. It Reduces the number of disparate technologies I need to know and align.

Slide 10

Slide 10 text

The distance between knowledge and capability is getting shrinking. We're not restricted by a speciﬁc set of tools to be productive on the web or native.

Slide 11

Slide 11 text

No content

Slide 12

Slide 12 text

No content

Slide 13

Slide 13 text

But the conversation still sucks. I'm a designer that's kinda found his way into programming UIs. The conversation requires that we think critically about separation of concerns. Today, we're talking about the Suitability and Capability of inline-styles.

Slide 14

Slide 14 text

I want you to think of this talk as a metro train. We're going all the way to crazy town, but I'm going to make some stops along the way. You may get out where it makes the most practical sense for your team. You may ﬁnd it's a little further than you might think :)

Slide 15

Slide 15 text

• Style is not "CSS" • State changes are UI changes* • Components should be reused, not repurposed Here are a few themes:

Slide 16

Slide 16 text

S T Y L E I S N O T " C S S " This is like the relationship between a square and a rectangle. We use "CSS" interchangeably with style. This makes conversation about where styles should live VERY HARD.

Slide 17

Slide 17 text

S TAT E C H A N G E S A R E U I C H A N G E S * This has an asterisk because it might not be universally true. But UIs are this loop between a computer and human. As our sites grow in interactivity. State changing typically results in a change to what the user sees. Hidden, shown, struck-through, connected — all things a user sees as feedback to an input.

Slide 18

Slide 18 text

C O M P O N E N T S S H O U L D B E R E U S E D , N O T R E P U R P O S E D Components are reusable in that they can be repeatedly used—not have multiple purposes. I would rather have 1000 components that do one thing than 100 components that do 2 things.

Slide 19

Slide 19 text

HISTORY Let's talk a little about how we got here.

Slide 20

Slide 20 text

I N T H E B E G I N N I N G . . . In the beginning, we didn't have CSS. Everything was styled inline.

Slide 21

Slide 21 text

HI!

And this is pretty clear!

Slide 22

Slide 22 text

HI!

But styles tend to grow...

Slide 23

Slide 23 text

HI!

And get duplicated... We needed a way to reduce duplication and reuse styles in a reliability way. So, we separated concerns of content and presentation.

Slide 24

Slide 24 text

HI!

CSS selectors solved this.

Slide 25

Slide 25 text

T H E S E M A N T I C W E B CSS was was very popular with those evangelizing the semantic web. This established web standards that ensured content would be presented clearly, even if presentation wasn't fully rendered or supported by a browser. This was hugely important to everything we do today.

Slide 26

Slide 26 text

h1 h2 h3 h4 h5 h6 p b i blockquote button table div span title ul li You had semantic elements and that was it.

Slide 27

Slide 27 text

Slide 28

Slide 28 text

#header h1 #header h2 #header h3 #header h4 #header h5 #header h6 #header p #header b #header i #header blockquote #header button #header table #header div #header span #header title #header ul #header li h1 h2 h3 h4 h5 h6 p b i blockquote button table div span title ul li #main h1 #main h2 #main h3 #main h4 #main h5 #main h6 #main p #main b #main i #main blockquote #main button #main table #main div #main span #main title #main ul #main li This was early approach to "Modularity". And it scaled indeﬁnitely.... provided you don't need anymore semantic.

Slide 29

Slide 29 text

C S S H T M L Our separation of concerns grew.

Slide 30

Slide 30 text

C S S H T M L

Slide 31

Slide 31 text

C S S H T M L presentation We call this coupling presentation.

Slide 32

Slide 32 text

T H E " W E B 2 . 0 " W E B With the discovery of AJAX, we started to transition from content driven sites to data driven applications. CSS was reborn through more classically-rooted ideas.

Slide 33

Slide 33 text

$("#todo-list ul li span") As we added interactivity, our selectors became coupled to markup. This isn't good.

Slide 34

Slide 34 text

$(".todo-list .item") We needed something that better expressed intent. So, we started to deﬁne our own semantics.

Slide 35

Slide 35 text

first
second

Now the markup can change without aﬀecting behavior.

Slide 36

Slide 36 text

first

second

Slide 37

Slide 37 text

first

second

But this is a problem. Anyone can change '.item' and we're hosed.

Slide 38

Slide 38 text

first

second

So, we namespace it. This works works extremely well.

Slide 39

Slide 39 text

J S H T M L C S S Our "separation of concerns" deﬁnition split again.

Slide 40

Slide 40 text

J S H T M L C S S

Slide 41

Slide 41 text

J S H T M L C S S presentation We still have a presentation coupling.

Slide 42

Slide 42 text

J S H T M L C S S behavior And we've added a new coupling that we call behavior.

Slide 43

Slide 43 text

I N T E R A C T I V E W E B With the interactive web, we got state.

Slide 44

Slide 44 text

J S H T M L C S S The problem is that we still regard "the separation of concerns" on the web as content/behavior/presentation. But with each new capability, these relationships grow and got more complex. Where is state in this Separation of concerns?

Slide 45

Slide 45 text

J S H T M L C S S state EVERYWHERE. The old wisdom is that these "just have to work in perfect synchrony"—each part depending equally an the other. This seems naive. Fortunately, React helped tame this a bit.

Slide 46

Slide 46 text

J S H T M L C S S

Slide 47

Slide 47 text

H T M L J S C S S state React made state a ﬁrst-class concern.

Slide 48

Slide 48 text

H T M L J S C S S interface presentation And looped markup into this tidy concept of an interface

Slide 49

Slide 49 text

H T M L J S C S S interface presentation behavior style But the "best practice" is still coupling state to style through CSS classes.

Slide 50

Slide 50 text

H T M L J S C S S interface presentation behavior style

Slide 51

Slide 51 text

.is-complete {...} .is-connected {...} .is-expanded {...} .is-collapsed {...} .is-open {...} .is-closed {...} These are some example classes of state-classes.

Slide 52

Slide 52 text

Without the .is-complete class deﬁned, which of these items is complete? It's impossible to tell. An oversight in our presentation concern is breaking our behavior.

Slide 53

Slide 53 text

H T M L J S C S S interface presentation behavior style The ﬁrst stop I want you to take is putting styles of state into React components.

Slide 54

Slide 54 text

H T M L J S C S S interface presentation behavior style

Slide 55

Slide 55 text

☑ WORLDS DUMMEST TODO-LIST This all seems a little nuanced. Let's walk through an example.

Slide 56

Slide 56 text

We're going to build the dumbest component I can think of: A List of todos. When click, a todo gets crossed out.

Slide 57

Slide 57 text

.todo-list { ... } .todo-list__item { ... } We'll start with our CSS classes The styles themselves are of no consequence.

Slide 58

Slide 58 text

{item.name}

Here's the render function of our component.

Slide 59

Slide 59 text

{item.name}

We want to conditionally add the .is-complete class based on state.

Slide 60

Slide 60 text

{item.name}

We'll used Jed Watson's classnames library here. When an item is complete, we add the is-complete class.

Slide 61

Slide 61 text

.todo-list { ... } .todo-list__item { ... } ... back to our SCSS ﬁle ...

Slide 62

Slide 62 text

.todo-list { ... } .todo-list__item { ... &.is-complete { textDecoration: "line-through" } } We'll add this state class to our SCSS ﬁle. "does just hearing 'state-class' bother anyone else?" Anyway, moving on...

Slide 63

Slide 63 text

describe("when item is is complete", () => { it("it has state-class is-complete", () => { // ... } } Let's look at what a test might look like for this. Without the style our behavior breaks SILENTLY. Let's take a look at what this looks like if we just put state styles inline.

Slide 64

Slide 64 text

{item.name}

Back at our component...

Slide 65

Slide 65 text

let completedItemStyles = { textDecoration: 'line-through' }; return (

{item.name}

); Put our state-styles in a JS object

Slide 66

Slide 66 text

let completedItemStyles = { textDecoration: 'line-through' }; return (

{item.name}

); And add a condition that loads those based on state.

Slide 67

Slide 67 text

let completedItemStyles = { textDecoration: 'line-through' }; return (

{item.name}

); We can now remove the classnames dependency, and our '.is-complet' classname from the component.

Slide 68

Slide 68 text

.todo-list { ... } .todo-list__item { ... &.is-complete { textDecoration: "line-through" } } Finally, we can remove this state-class that has always felt a little strange.

Slide 69

Slide 69 text

.todo-list { ... } .todo-list__item { ... } Now this ﬁle is stateless again, only concerned with "appearance" not appearance and "behavioral"

Slide 70

Slide 70 text

describe("when item is is complete", () => { it("it has state-class is-complete", () => { // ... } } I have a real problem with this. Without the style our behavior breaks.

Slide 71

Slide 71 text

describe("when item is is complete", () => { it("it appears crossed out", () => { // ... } } Don't let styles break your behavior silently.

Slide 72

Slide 72 text

H T M L J S C S S interface presentation behavior style ALL we've done is brought state fully into our React component.

Slide 73

Slide 73 text

interface J S C S S appearance And we've freed CSS to ONLY care about appearance.

Slide 74

Slide 74 text

“What if I don't want the default style?”

Slide 75

Slide 75 text

let completedItemStyles = { textDecoration: 'line-through' }; return (

{item.name}

); Back at our component...

Slide 76

Slide 76 text

let completedItemStyles = { textDecoration: 'line-through' }; return (

{item.name}

); Let's bulk up our style equation to handle multiple conditions, using Object.assign.

Slide 77

Slide 77 text

let completedItemStyles = { textDecoration: 'line-through' }; return (

{item.name}

); Now, we can take a prop, call it completeItemStyle, and merge it in atop our base styles.

Slide 78

Slide 78 text

Slide 79

Slide 79 text

Now we can override these base styles at the call site.

Slide 80

Slide 80 text

goes from our default...

Slide 81

Slide 81 text

to have our new styles

Slide 82

Slide 82 text

W H AT W E D I D ? • State is fully owned by our component • Stateful classes removed from DOM and CSS • CSS reduced to "appearance"-only • Styles can be overridden at the call site • Better specs

Slide 83

Slide 83 text

W H AT I T C O S T • State-styles written in JS objects I think that simple shift is a big win for established teams with an existing CSS codebase.

Slide 84

Slide 84 text

CAPABILITY So, we've talked about suitability. I'd like to talk a little about capability. CAN we do the same things in JS that we can in CSS? This won't be an exhaustive list but I'll try to get through the most common questions.

Slide 85

Slide 85 text

VA R I A B L E S One of the things people often ask is if they can use variables to theme components. Yes and they're just JS.

Slide 86

Slide 86 text

$red: #ff4136; $orange: #ff851b; $yellow: #ffdc00; $green: #2ecc40; $blue: #0074d9; $indigo: #39cccc; $violet: #b10dc9; colors from mrmrs/colors variables.scss This is what variables look like in SCSS

Slide 87

Slide 87 text

export default { red: "#ff4136", orange: "#ff851b", yellow: "#ffdc00", green: "#2ecc40", blue: "#0074d9", indigo: "#39cccc", violet: "#b10dc9" }; colors from mrmrs/colors variables.js And here's what the look like as a JS module.

Slide 88

Slide 88 text

import appColors from './colors'; I can import these into my component wholesale.

Slide 89

Slide 89 text

import { orange, indigo } from './colors'; Or just grab only the variables I want.

Slide 90

Slide 90 text

import dark from './themes/dark'; import light from './themes/light'; I can create diﬀerent themes.

Slide 91

Slide 91 text

import darkColors from './themes/dark'; import lightColors from './themes/light'; ... let colors = (this.props.theme === 'dark') ? dark : light; ... And switch based on a prop.

Slide 92

Slide 92 text

P S E U D O - C L A S S E S These are fake classes that allow you to make selections based on an elements relationship to other elements.

Slide 93

Slide 93 text

let completedItemStyles = { textDecoration: 'line-through' }; return (

{item.name}

); This is where we left our TodoList component.

Slide 94

Slide 94 text

let completedItemStyles = { textDecoration: 'line-through' }; return (

{item.name}

); Say we want change the background of every even element. We just add a condition.

Slide 95

Slide 95 text

let completedItemStyles = { textDecoration: 'line-through' }; return (

{item.name}

); If that condition requires the length of the items. We get get that through map

Slide 96

Slide 96 text

let completedItemStyles = { textDecoration: 'line-through' }; return (

{item.name}

); and write our condition based on it.

Slide 97

Slide 97 text

textDecoration: 'line-through' }; let tigerStripeStyle = { backgroundColor: "#f2f2f2" }; return (

{item.name}

And again, we can move this object as it continues to grow.

Slide 98

Slide 98 text

:first-child :last-child :only-child :nth-child(even) :nth-child(odd) :nth-child(n) :nth-last-child(n) :nth-child(-n+3) i === 0 i === arr.length - 1 1 === arr.length i % 2 !(i % 2) i === n - 1 i === arr.length - n i < 3 common pseudo-class cheatsheet If your interested, here's a little cheatsheet.

Slide 99

Slide 99 text

P S E U D O - E L E M E N T S Fake elements to keep semantics.

Slide 100

Slide 100 text

.my-class::before { } .my-class::after { } In CSS, these are a godsend. They make things like: * clearﬁxes * iconfonts * some grids possible. They're completely useless in React because you're deﬁning your own semantics.

Slide 101

Slide 101 text

Hover here If you have markup like this...

Slide 102

Slide 102 text

::before Hover here ::after pseudo-elements get inserted like this in the DOM.

Slide 103

Slide 103 text

Hover here

This is how you would do this in React and inline-styles.

Slide 104

Slide 104 text

HARD PARTS Hard Parts When I proposed this talk. These details were going to be the core of my talk. In the past 5 month. Libraries have made it possible to to not have to solve this on your own.

Slide 105

Slide 105 text

.list-item:hover { background-color: rgba(0,0,0,0.1); } adding :hover styles in CSS is delightfully simple.

Slide 106

Slide 106 text

class ListItem extends React.Component { constructor(props) { super(props); this.state = { hovered: false }; this.handleMouseEnter = () => { this.setState({ hovered: true }); } this.handleMouseLeave = () => { this.setState({ hovered: false }); } } render() { return (

); } } In React, it is not.

Slide 107

Slide 107 text

.list-item:hover { background-color: rgba(0,0,0,0.1); } In CSS, adding breakpoints is incredibly simple...

Slide 108

Slide 108 text

.list-item:hover { background-color: rgba(0,0,0,0.1); } @media (max-width: 480px) { .list-item { width: 100%; } }

Slide 109

Slide 109 text

class ListItem extends React.Component { constructor(props) { super(props); this.state = { hovered: false, smallScreen: false }; this.handleMouseEnter = () => { this.setState({ hovered: true }); } this.handleMouseLeave = () => { this.setState({ hovered: false }); } this.handleMatchMediaChange = (e) => { return this.setState({tabletContext: e.matches}); } } componentWillMount() { this.handleMatchMediaChange(window.matchMedia("(max-width: 480px)")); window.matchMedia( "(max-width: 480px)") .addListener(this.handleMatchMediaChange); } componentWillUnmount() { window.matchMedia("(max-width: 480px)") .removeListener(this.handleMatchMediaChange); } render() { return (

); } } In React, it is not.

Slide 110

Slide 110 text

T H I S I S N ' T B E T T E R This isn't easier. But it does give you some much needed control over events. The way that mobile browsers handle events like :hover for touch only gets harder and harder to reason about. But sometimes you just want sensible defaults.

Slide 111

Slide 111 text

R A D I U M This is where libraries like Radium come in. There are 15-20 libraries now that take a similar but varied approach to adding nice conveniences to inline styles. I feature Radium because I think it's the most extremely "inline-styles" only. And because of that, it doesn't required a build-step; making it a great ﬁt for any system, including integrated systems like .NET and Rails. By design, Radium allows you to style application components in a way that's very remeiscient of SASS or Less

Slide 112

Slide 112 text

.list-item:hover { background-color: rgba(0,0,0,0.1); } adding :hover styles in CSS is delightfully simple.

Slide 113

Slide 113 text

var styles = { ':hover': { backgroundColor: 'rgba(0,0,0,0.1)' } } In React, this is what's required to emulate the hover pseudo-class

Slide 114

Slide 114 text

.list-item:hover { background-color: rgba(0,0,0,0.1); } adding :hover styles in CSS is delightfully simple.

Slide 115

Slide 115 text

.list-item:hover { background-color: rgba(0,0,0,0.1); } @media (max-width: 480px) { .list-item { width: 100%; } } adding :hover styles in CSS is delightfully simple.

Slide 116

Slide 116 text

var styles = { ':hover': { backgroundColor: 'rgba(0,0,0,0.1)' }, '@media (max-width: 480px)' { width: 100%; } }

Slide 117

Slide 117 text

H O W I T W O R K S How does it work?

Slide 118

Slide 118 text

class MyComponent extends React.Component { render() { return

} } export MyComponent; It uses an ES7 decorator to enhance your component.

Slide 119

Slide 119 text

@Radium class MyComponent extends React.Component { render() { return

} } export MyComponent; ES7 It uses an ES7 decorator to enhance your component.

Slide 120

Slide 120 text

class MyComponent extends React.Component { render() { return

} } module.exports Radium(MyComponent); CommonJS w/enhancer But it supports CommonJS

Slide 121

Slide 121 text

(() => { var MyComponent = React.createClass({ render() { return

} }); this.MyComponent = Radium(MyComponent); })(); ES5 / globals And with som old tricks, globals

Slide 122

Slide 122 text

var styles = { color: '#0074d9', ':hover': { color: '#0088FF' }, '@media (max-width: 480px)': { width: '100%' } } .my-class { color: #0074d9; &:hover { color: #0088FF; } @media (max-width: 480px) { width: 100% } } JS + Radium SCSS Reads like SCSS, with nested syntax.

Slide 123

Slide 123 text

T H E O T H E R S Radium has a very elaborate chart about alternative libraries, comparing: * syntax * override mechanism * ES-version * and isomorphic support. But Radium is hard to beat. It's passionately maintained, with excellent docs, and has no build-time phase, making it a great ﬁt for integrated systems like Rails and .NET.

Slide 124

Slide 124 text

GRAB BAG Grab bag. These are the things that didn't ﬁt into the theme that I wanted to make slides for. Incase they were where your head was at.

Slide 125

Slide 125 text

C O L O R S SCSS has some cool ways to manipulate colors.

Slide 126

Slide 126 text

import Color from 'color'; harthur/color The great thing is that these are honest to goodness variables. Sass compiles these values to regular CSS. Whereas they can be edited on the ﬂy in JS

Slide 127

Slide 127 text

import { orange, indigo } from './colors'; import Color from 'color'; harthur/color The great thing is that these are honest to goodness variables. Sass compiles these values to regular CSS. Whereas they can be edited on the ﬂy in JS

Slide 128

Slide 128 text

import { orange, indigo } from './colors'; import Color from 'color'; let hoverStyles = { backgroundColor: Color(indigo).lighten(0.2); }; harthur/color The great thing is that these are honest to goodness variables. Sass compiles these values to regular CSS. Whereas they can be edited on the ﬂy in JS

Slide 129

Slide 129 text

L AY O U T If you're comfortable with an existing grid system. If you have one for your app --- There are a lot of mature layout systems out there. For our team, we don't use a react-speciﬁc layout system. For what we do, there's not really a need. Where reasonable, we make our components the full width and height of a container. So, we ALWAYS wrap a component in layout, instead of applying layout to the component directly.

Slide 130

Slide 130 text

U S E A N Y L AY O U T L I B Y O U L I K E

Slide 131

Slide 131 text

When applying layout to a component...

Slide 132

Slide 132 text

This is bad

Slide 133

Slide 133 text

This is better.

Slide 134

Slide 134 text

const styles = { width: "100%", height: "100%" }; We try to make things work at 100%. And contain them with a layout or component.

Slide 135

Slide 135 text

D I S T R I B U T E D C O M P O N E N T S

Slide 136

Slide 136 text

import media-object from 'react-media-object'; If you ﬁnd yourself sending a lot of style props down. Export more components

Slide 137

Slide 137 text

import { Media, MediaImg, MediaImgExt, MediaBd } 'react-media-object';

Slide 138

Slide 138 text

import { Media, MediaImg, MediaImgExt, MediaBd } 'react-media-object';

Slide 139

Slide 139 text

import { Media, MediaImg, MediaImgExt, MediaBd } 'react-media-object';

Slide 140

Slide 140 text

soundcloud react-soundplayer http://labs.voronianski.com/react-soundplayer/

Slide 141

Slide 141 text

INLINE-STYLES I said we were going to take this all the way to crazy. Here's our last stop. I think that components are the cornerstone of interactive experience on the web and mobile. We should build that as singular blocks of code.

Slide 142

Slide 142 text

{message.time}

{message.author}

{message.message}

My moment came when I was scaﬀolding out my 50th component. I wrote this render function...

Slide 143

Slide 143 text

{message.time}

{message.author}

{message.message}

I add my classes...

Slide 144

Slide 144 text

.ChatMessageList {...} .ChatMessage {...} .ChatMessage-time {...} .LiveChatMessage-author {...} .LiveChatMessage-body {...} And built up stylesheet.

Slide 145

Slide 145 text

• The component filename • The component class definition • The 5 uses of className • The stylesheet filename • The 5 class definition in the stylesheet There is so much naming duplication here. This is so much ceremony. I hated this invisible line that lived between these two totally desperate technologies. Literally held together by a strings.

Slide 146

Slide 146 text

– S A N D I M E T Z , P R A C T I C A L O B J E C T- O R I E N T E D D E S I G N I N R U B Y “The purpose of design is to allow you to do design later, and it's primary goal is to reduce the cost of change.” With classes we're sacriﬁcing "changeability" for the chance that we might be able to repurpose our styles by cascading styles alone. This is a pipedream.

Slide 147

Slide 147 text

interface appearance So, we took the last part piece of our component and moved it inline.

Slide 148

Slide 148 text

interface The best practices in modern CSS continue to move toward modularity. So why not just used modules.

Slide 149

Slide 149 text

data EmailClient data ChatMessages data Document data Songs interface If we do this, we can fully live in the promise of React. With our separation of concerns at the boundaries of our components.

Slide 150

Slide 150 text

This year I turned 32. I learned that, in your 30s, you can't love eating everything and doing nothing at the same time. So I started riding a bike.

Slide 151

Slide 151 text

A bike is made of components, designed speciﬁcally for a bike. I don't expect to repurpose my bike components: If my car gets a ﬂat, I don't expect that the tires of my bike could act as a spare. However, I can switch components with another bike.

Slide 152

Slide 152 text

My bikes behavior isn't deﬁned by it's appearance. A bike is useless without a frame or handlebars or tires. but it works ﬁne without paint or handlebar tape.

Slide 153

Slide 153 text

A bike is components are designed components that are complete on their own and act in service to the whole. Inline-styles get us closer to directly addressing the web and iOS by separating concerns not at technologies but components.

Slide 154

Slide 154 text

• Style is not "CSS" • State changes are UI changes* • Components should be reused, not repurposed Let the boundaries of your concerns be components.

Slide 155

Slide 155 text

• Style is not "CSS" • State changes are UI changes* • Components should be reused, not repurposed • It's a great time to get involved Please start using these ideas in your apps. With inline-styles there are still a lot of big questions to solve. We can only tackle those if people are using this in a meaningful way.

Slide 156

Slide 156 text

@chantastic I want to meet you. So, I have stickers. Come up. Say "hi". Tell me why you think I'm wrong about all this :)