Jeff Conniff and Tilo Mitra: The Future of YUI CSS

Uploaded by yuilibrary on 26.11.2012

Jenny Han Donnelly: And we're back. Next up we have Jeff Conniff, who is our resident
visual design and interaction design guru come engineer, walking us through some of
the CSS related changes that we have in store, followed by Tilo Mitra, one of our newest
team members who is a former intern as Dav mentioned, talking about some of the exciting,
again, CSS related projects that he is working on.
Jeff Conniff: Thank you Jenny.
Thank you. I'm glad to be here today and get an opportunity to talk about skinning.
I've been asked to give a brief bio just at the beginning. I would like to mention
that my lifelong quest for all things visual and beautiful started very early in my life.
My mother was an artist, and she prompted me. Got my very first opportunity to exhibit
a huge full-scale full-color mural. It was beautiful. Unfortunately it was on the wall
of my hallway to my parents' room. It was called Exploration in Crayola on Latex Enamel.
I learned one thing very early on, that there are critics everywhere.
It was demanded that I scrub off every one of those brilliant strokes.
Even though I was probably damaged psychologically, I still went on to get a degree in graphic
design and have spent 15+ years ñ I think that's the right euphemism, 15+ years ñ
doing visual design, interaction design, and prototyping, and found myself on the YUI team.
I'm the author of the dial widget and the night skin and lots of fun library examples
that you may have seen.
I'm right now currently working on skinning with some really brilliant and fun people
to work with. I'd like to mention Matt Sweeney ñ you want to wave your hand back there,
Matt? The great Matt Sweeney.
And Anthony Pipkin, is he here? Yep, there's Anthony over there. Great guys.
Having a lot of fun.
In the animal kingdom, it's a very critical skill to be able to blend in to one's background.
So that's critical for two reasons: these critters need to be able to blend in and hunt
well so that they can eat. That's critical. They also need to, for the second reason,
they need to be able to hide well so that they're not eaten. Those two things. It's
similar in UI skinning, but it's also a little bit different. It's not so much an eat or
be eaten proposal, but you really need to blend in and look like you belong so that
you don't have the sore thumb effect happening when you're putting a widget into a UI.
Fortunately in YUI we've got this great system for skinning the appearance of things, pages
and our widgets. It goes something like this. It's very easy. Just in the body tag or anywhere
else, other DOM element, you can put in a skin with theÖ I'm sorry, a class name with
the skin there. And then in this case you don't need it because sam skin is the default,
but in other cases you could put in a filter that has that same matching name. And that's
all it takes to get the skins and interchange them.
So we have two skins today. One is called the sam skin, which works great for light
backgrounds, and the other one named, for obvious reasons, the night skin. So we have
those two skins today. The only problem with that is that if you're working in some sort
of application or web page that looks like this and you want to put, say, a tabview control
in that open spot to the left of the cinnamon roll, so you drop that in, the colors don't
quite cut it. They're not just right. So what are you going to do? Well, you'll have
to do some tweaking on that. It becomes really apparent to us that we need a lot more skins.
What are we going to do to get a lot more skins? Well, the process unfortunately is
a little bit tedious. You have to understand a lot about each of the widgets, or at least
the widget that you're going to put in your app. You need to look at the CSS and understand
where the classes go and where they fall on the different DOM objects. You need to connect
all the dots and put the right values in the right place to make them look correct for
what you're doing.
Now that's great for one widget, but if you're trying to do a skin for the entire library
of all of our widgets, that's a bigger job. You're really doing similar work times n
widgets. It also helps to have some experience with visual things and color, and to have
spent some time doing some of that is a helpful thing. Even with that and the patience required
to do that, it's still a little bit like the process of manually creating the inner
works of a wrist watch one at a time. It's a lot of work.
We tried to figure out what we were going to do about that, and we looked around at
some other people who were trying to solve the same problem and saw a couple of solutions
out there. One of which is a solution where you look at every individual possible style-able
element in your user interface and you give it a very explicit variable name, and then
you provide an input field for whoever's going to do this skin for them to enter in
their own hex value or their font or their size of padding or whatever it is. So you've
got a lot of input fields and a lot of variables. You can imagine that each time you add something
to that space it just gets longer and longer, so it becomes kind of unwieldy as you can
see. That may share the work of producing skins, but it doesn't necessarily make it
a lot easier.
Now, an obvious answer to that would be to group the variables together and have multiple
things point to the same variable so you don't have quite so many buckets to deal with, quite
so many inputs to fill in the values for. We saw some of those and you can imagine that
you might come up with some names for UI groups of things that could be commonly shared, like
title, or header, and you could color them this way. But you might find that there are
some things that might be a little surprising. It might be somewhat expected that you'd
see that color for title and header behind a tabview, but on the other hand you might
be surprised when you find out that that same color is also being shared by the range between
thumbs in a slider, or maybe even more surprised to find out that that same color is being
used by a progress bar while you're waiting for something to load. So you're having some
problems with unexpected consequences from combining those things together.
Another example: you might think a good generic value to set variable would be for something
called clickable. We use a general name, so you'd say great, I'll color my buttons dominant
because they need to be seen a lot, so I'll give them this color. I might not realize
that spin controls will also have that dominant color on those buttons, and I might not realize
that the thumbs on sliders are going to have that same dominant color. You might have expected
that, but you might not. What you might really not expect is that every day in a calendar
since it's clickable, guess what? Gets the same dominant color. Really an unexpected
In some of these systems you can select and change every single little piece and it's
just a lot of work. That doesn't assure that you get what you want. That reminds me of
a story about work. There once was a neighbor down the street. His name was Bob. Bob lived
in a nice home with his wife Sally. Sally was always after Bob, saying Bob, I think
it's time that you painted the house, Bob, when are we going to paint the house, Bob
we haven't painted the house in 12 years. So Bob finally decided that while Sally was
going back east to visit family for a couple of weeks, he'd surprise her and he'd paint
the house.
So while she was gone, that's what he did. He got all the chips. Fortunately Bob doesn't
live in an area where there's a home owners association, so he really had total freedom
to do whatever he wanted. He could pick any color, which was great news for Bob because
he really loves color. So he has a house that has a lot of individual pieces that he's
got to decide exactly the relationships and these colors. He got to work and planned it
all out, and he did paint the house while Sally was gone. On her return, Sally was indeed
surprised to see that Bob had painted the house. Just the fact that Bob had the ability
to paint every single piece any way he wanted to didn't mean that he was going to get the
good relationships and get a good paint job, and Sally would agree with that too.
That brings me to another issue, just like in UI this is a problem. There's another
principle that I've called the whac-a-mole principle. You all know the game, the mole
pops up and your hammer him down, and as soon as you hammer him down he pops up somewhere
else and you hammer him down and it goes over and over and seems endless that you're trying
to get this thing to stay down. Well, the same can be true when you're picking colors
and setting things together.
Let me show you that. To demonstrate that pain point I'd like to use my acupuncture
diagram. This is a simple example of a widget, just a menu. It's sitting on a white background.
Say you were going to change this because you realized that you needed something that
was going to be on a green background and it just didn't look quite right. You'd think,
well, I'd just make it green, no big deal. Maybe you've thought this. But once you got
into it you thought well, I've got to change this body of the bottom part to something
green, and if I do that then this highlighted section doesn't look good so I need to change
that. By the way, this blue text on the green background doesn't look very good, so I'll
need to change that. And by the way, the border doesn't look very good, so I'll need to
change that to green, maybe a little darker. And this top tab really needs some work too,
it can't stay blue. Then its text of course can't be blue, it needs to be green. And
the border also has to be green. We haven't even gotten into the hover problems ñ you
know, if there's hover and a lot of other colors have to be selected.
Then you step back and you look at it, and this is the whac-a-mole part, and you say
that's good except I think the body needs to be a little darker in that menu. So as
soon as you change the body color to be something a little darker, then the text is not readable,
so then you have to go back and do the text. I think this conference only goes for a couple
of daysÖ
Öso I probably can't really show the full effect of whac-a-mole. But that gives you
an idea.
This is what we did, or actually to be more accurate, what we're doing. We started with
two skins like I mentioned, and we did a little research and we decided that we would probably
need a number of skins that would be pretty close to the number of unique visual color
schemes and designs of apps and webpages on the internet. So we did some calculations
and did some research and found that we'd need about 29 million.
Audience member: How did you get this number?
Jeff: The question is how did I get that number. Well, we actually employed some of the same
research methods that politicians use frequently.
I got that off my RSA token. But you can use any random number generally.
And it seemed plausible so I put it in.
Thought you'd be fooled by it, but I guess not. At any rate, we need a lot. Unfortunately
people who have the time and the patience and some of the skills to put these together
is a relatively small number, so it's going to take a long time to get to 29 million skins.
What we had to do was figure out a way to eliminate a lot of those special skills and
a lot of the tedium, and that's exactly what we've done and are doing. We needed to make
this easy. How easy do we need to make it? Well we need to make it easy enough so that
just about anyone can create a skin or their own skin whenever they need to in a short
amount of time.
So how to do that? Well we looked around and the other solutions that we were seeing didn't
seem to be the way we wanted to go, and we had a different idea so we're proceeding
with that in a different direction. From our experience in working with color and design
we've learned that colors are a lot like people. You could really group all people
in the world into three categories. Everyone knew that, right?
Three main categories. There are the ones that seem to always need attention. They always
have to be in the limelight, they always have to be out there and people have to be looking
at them. And then there's the other group that's not quite so in your face. You know,
they're important and they have a purpose but they're not always out there shouting.
And then there's a third category that seemed to fade into the background and you don't
really even know they're there, but they're still necessary.
The same is true of colors and UI elements. To give an example of that I've put together
a test, and don't worry, this is not graded but we'll all be taking this test together.
You don't have to hand in your papers or put your names on them. In fact this test
is made ridiculously easy just to make a point. I'm going to show you five blocks of color
ranging in emphasis from most emphasized to least emphasized and see if you can pick out
which one is which. Grade them from really dominant to really recessive.
Do you need more time?
Did I make this too easy by stacking them from brightest to darkest? Maybe I did, okay.
All right, so that's throwing it off. I'll mix them up a little bit. What do you think?
Need more time?
Maybe I made it too easy because they're all blues. Maybe if I mixed in some other
hues in there it would be more difficult, so we'll see. What do you think? Pretty tough?
No. Got it. Pretty easy to do.
Well, it's really relationships of colors and which ones are emphasized and which ones
are not. You can take this kind of process and apply it to text elements as well, or
objects on a widget, or on a UI. That's what we've done, is to create instead of buckets
of UI named things to attach skins to, we've created a hierarchy of emphasized color values
and then we point the widgets at those generic values.
Let me demonstrate that. You'll see something that looks kind of similar to what we saw
in the test. We've got some boxes there, they're labeled, but they're going from
most emphasized item to least. Don't be fooled by the fact that the least emphasized one
is a wrapper for the others. So what can you do with this? You can select the key color
ñ in other words you don't have to change all the color blocks, just pick a key color,
let's say green, and you automatically get colors of green that are in different emphasis.
Really all you're doing is picking one color. Want red? Got the same thing. Want a dull
red, a dull dark red? So it's as easy as using a color picker. You're establishing
this relationship of colors and color buckets.
Now there are not just four colors to choose from, but we've really got a whole fully
fleshed out set of text of different weights and gradients and rules and borders in the
system. Selecting anything in there changes everything just at a single click.
The second thing that you can do to change this scheme of emphasis is pick a color scheme.
A color scheme is really nothing more than how those main blocks of color bucket relate
to one another. Right now we're looking at monochrome, but if you really wanted just
a single color as your highest emphasized color and the rest gray, you could pick the
color plus gray color scheme. Then the same thing happens wherever you go.
If you wanted a complementary color scheme you can do that too. You pick green and you
get the complementary color of that. If you want a dark background. And the last choice
down there and more means there can be infinite number of color schemes. We're obviously
going to start with more than just the four or five, but you can see very quickly that
if you have say 16 million colors in that color picker and you throw half of them away
and you multiply that by even 4, you're at 29 million possibilities right there.
Let's go back. Whenever you're trying to take something visual and aesthetic and you're
trying to create it by math, you run into some thorny problems because one and two don't
always equal three when you're dealing with things like color. There are some problems
that we run into. Fortunately Tony Pipkin ñ if you can stand up again Tony, or wave
or something ñ he's my super hero. I had cobbled together some code that was sort of
doing this, but Tony came in and rewrote some great methods that are now part of the library.
They're Y.Color, and he's got some great things in there that take care of these thorny
problems. I'll let you applaud after you've seen some of those.
Let me show you some of those. First is readability. You can imagine any time you're changing
background colors you're going to quickly have problems with readability of text sitting
on top of it. For example, this slider changes only the background color, and you can see
if you start doing that you're going to get into some things that are pretty hard to read
real fast. But fortunately thanks to Tony and Y.Color, we've got getOffset, which really
just takes a background color which is the background hex color there, and offset lightness
value, it could also be offset saturation or hue, and in this case it's 20 per cent
lighter, and now anywhere I move the slider you can see the text is readable. Which is
pretty nice, except when you start getting toward the top, right? For that situation
we've got just another minor piece of code that flips the sign of 20 so that it stays
readable no matter where you move. So that's getOffset in Y.Color, which was really nice
for me to use in this.
The next thorny problem is introduced by this humble gray rectangle who has no color at
all. He has no hue. I'm sorry, he does have hue, but you won't know it because it has
saturation of zero, so he's plain. He's only 50 per cent brightness ñ I mean if he
were 100 he'd be white, if he was zero he'd be black. He's pretty boring. But a much
more festive rectangle is this one. It has all of the hues from left to right. They're
all 100 per cent saturated, and make special note that they all have the exact same lightness
value of 50 per cent.
Now if you squint your eyes and look at that bottom thing you might see that some of them
seem to not be 50 per cent, some of them seem to be a little darker. In fact if you take
that color band and you turn it into a grayscale image in Photoshop you get something like
this, which makes it really obvious that some of those colors are not appearing to the eyeball
to be the same brightness.
Why does that matter? Why am I talking about this? Well if you took two colors out of the
color spectrum and say you wanted to use those two colors in a widget somehow and you had
two objects that you wanted to have sitting next to each other and you wanted to have
this system that can change hues to anything the user wants but you want those two elements
to keep the same relative dominance, when you ran into a combination like yellow and
blue one is going to scream and the other's going to be quiet. So that's a problem of
Fortunately we have another thing from Y.Color which is called getBrightness. This is no
getBrightness method happening now, but you can see as I choose different colors that
the comparative lightness between the purple on the left and say the blue on the right
is very different. But in Y.Color now there's getSimilarBrightness. Now when I pick a green,
and you can see that it gets input on the first argument, and I tell it to match the
lightness of the color on the left, that I get a different value for green that's equal
in brightness. You can kind of see how this works out. As we pick different colors around
here for the most part, monitorsÖ You can see we're maintaining the brightness.
Also in Y.Color is a harmony utility, which in this case gives us getComplementary color.
Now when I select say green for instance, it's the color on the right, it's going
to give me the complement of green which is red. Then we use getSimilarBrightness to take
that red color and say give us a red that's the same lightness as green, and we get this
result here. If I pick red then it takes red and gives me green, and then tones down the
green so that it matches the brightness of the red. These are really nice utilities and
I really appreciate Tony's work on that. Let's give him a round of applause.
Those thorny issues are no longer thorny. If you'd like to look at Y.Color that's
a link to it if you get this presentation.
Now that I have the ability to work in that color space and have confidence that I'm
going to get these benefits from Y.Color, I can get widgets that are hooked up to that
color space in intelligent ways so every element in the widget can then point to its right
level of emphasis. Then no matter where I drive the colors, that emphasis is kept. Let
me demonstrate that.
If we look for a green, one click and we've got a green monochrome scheme. Pick a different
color scheme, maybe complementary, and we have a green and red color scheme. Pick something
over here. Saturated, low saturated, anywhere you go. You can see that these widgets are
all behaving the way you'd expect color-wise.
These are real widgets, by the way, this is not smoke and mirrors. This is the real stuff.
We've got hover colors also taken care of. I didn't have to set any of those at all.
All the widgets are now hooked up to this extended color space that looks like that,
and it all behaves well. We're also doing a little experimenting with border radius,
if you watch the radius on the buttons. And also padding. These things are very easy to
manipulate without having to dig in and set individual variables everywhere.
So that's how we're doing that. Since you're here, you fit the demographic of people who
the first thing you do when you get a new pen isÖ what? Take it apart, right? So let
me show you a little bit about how the color space is connected up to the widgets. I should
remember to mention that you only have to do this once, and we'll be doing this before
it's even out there. This, that I'm about to show you, is not something that has to
be done every time you do a skin, it really is just as easy as picking a color scheme
and a color. This is under the hood.
Let's start with a single individual element. Let's take the text on a highlighted tab
of a tabview widget. Where does that come from? That comes, of course, from the CSS,
but how did that hex value get there? Well that came because there was a variable that
was replaced in a template, and that variable came from a mapping file where that variable's
mapped to the correctly emphasized place in that color space that we looked at. That space.block.highest.text.normal
is a location in a JSON object, an element in a JSON object that represents the entire
color space. You have space.block.highest.text.normal, and that's where the hex value is.
Now how did that hex value get there? Well this whole color space JSON object is represented
in the UI that we've been looking at. It's just the visualization of the color space.
That element for that particular string of text came when we clicked on the bucket for
the highest key color and we chose a color from the color picker. Then smart calculations
happen and we got all the color space filled out with all of its values. So that's how
it's put together.
In summary, we should avoid the hard work. We should avoid defining everything and the
whac-a-mole pain. We've taken a different approach - this is relative levels of emphasis.
CSS variables to point to this color space, and again, this is one time work that we're
taking care of. Under the hood it's Y.Color. And really all you'll have to do is pick
a key color and a color scheme and you'll have millions of possible skins.
Thank you.
I think we have a microphone coming for you.
Audience member: Hi. So how is the impact of this dynamic mechanism effect on the performance?
Jeff: Actually all of what you've seen will be put in place just to generate a skin, and
then that skin will be used the same way skins are today. You'll just reference that and
it will automatically load the CSS file for those. Really, performance is none.
Audience member: Okay, second question. Does this use any less?
Jeff: Actually it can use anything to substitute the value in that mapping file. We're going
to be publishing this and getting feedback to find out exactly what the right system
is for that.
Audience member: Thank you.
Audience member: Hello. Oh, sorry. Do you feel like the automation of this constricts
your ability to maybe fine tune some of the details on something, and what are the drawbacks
to that?
Jeff: No actually, because you can pick any color to start with as a key color, and you
can easilyÖ We'll be making it so that you can create your own color scheme, which is
the relationship of those four blocks. You have a lot of flexibility. And then at the
end of the day this is just generating a CSS file that today you would have to go in and
edit anyway. We're not restricting that point. Then later on we can probably add the ability
to tweak individual things.
Matt, speak up if you want to add anything to what I'm saying. Okay.
Audience member: Just curious what sort of timeline you're looking at for when this
will be included in the public release and all that?
Jeff: Actually what you saw today was working code. We're going to polish that up just
a little bit and make the tool that I have there that I showed available so that you
can create skins sometime in the near future. Then we're going to properly format the code
and put it actually as part of the library. Did you want to add anything on
that Matt?
Matt Sweeney: Yeah, the longer term strategy is to incorporate it into the build process
and stuff, the shorter term is get the skin generator out there so people can create style
sheets and contribute those.
Jeff: Yeah, so we can get feedback on that as well.
Audience member: So just to be clear that if you're writing a gallery module, say,
then before too long you'll write a CSS template that will refer to that color space rather
than CSS?
Jeff: Right, right, once.
Audience member: Thank you from the bottom of my heart.
Jeff: You're welcome. And that'll be once, you'll only have to do that one time.
Audience member: Hi. Do you have any concept of a lightness or darkness threshold to where
certain elements gain or lose styling? For example a drop shadow may look good in a medium
brightness skin but maybe on a light skin it might not look quite so right. Do you have
anything like that in your skin builder?
Jeff: A lot of theÖ Are you asking specifically about drop shadows, or any color element?
Audience member: It would be any color element, or you know, thickness of borders or things
like that.
Jeff: We're looking at thickness of border too, so we'll be anxious to hear community
feedback on thickness of border. There is a lot of code in there that handles the relationships
between all of those colors and makes sure that they don't fall off the radar and you
can't see this part. So yes, we're handling that. There's a lot of really good stuff
in Y.Color that's helping us write smart code for that.
Audience member: Hi. I'm wondering how you handle spacing between buttonsÖ Over here.
If you thought about automatically calculating the proper spacing between buttons? I find
that we have several modals in our application or other elements on the page, because we
don't have a consistent way of easily padding between different objects. Are you guys thinking
of that too?
Jeff: That's good input, and I'll make sure that we think about that, get that in there.
We have been working on padding within widgets, within objects, and that's good input. We'll
take that as padding between objects. Good. I mean margins between objects.
Audience member: Over here. Will it be possible to generate your own color combinations? Like
say when it generates CSS you canÖ Like you have the opposite colors and stuff like that.
So you generate your own kind of library that will generate CSS for you?
Jeff: I'm not sure I understand. Did you mean a different color scheme?
Audience member: Yeah, you know like you have the complementary colors, maybe you create
your own that will generate CSS for you. Like you modify the existing library.
Jeff: Right. The whole color scheme picker that I had, the radio buttons on the top left
were choices between how the individual major blocks of color relate to each other. You
saw complementary in there, and monochrome, and color plus gray. It's wide open, and
we're using all of the Y.Color utilities for that so you could have triads, you could
have split chromatic things. So anything is open to that. The Y.Color has a whole full
library of ways that you can get different color schemes that can be part of that. Thanks,
good question.
Audience member: Hi. I'm using slider as an example for my question. Slider today has
several skins which work really, really well, but it's awkward to have one theme and select
a couple of slider styles for that. So any thoughtsÖ On some widgets you just have one
theme and that's it, but some widgets like slider and buttons are candidates for having
within one theme different styles per se, so any thoughts on making that easy so you
choose the skin and the different styles of what component are part of it rather than
choosing like a style per component or skin per component?
Jeff: Yeah, the sliders are a little tougher nut to crack because right now they're image
based. We're thinking on that one but I don't have a good answer for you today.
Audience member: Thank you.
Audience member: Over here.
Audience member: What about accessibility sort of colors? Will that also be taken care
in the options?
Jeff: Can you say that again?
Audience member: Accessibility colors, like for color blind and stuff like that for people.
Jeff: Accessibility color blindness issues, yeah. That will be the responsibility of the
person who is picking the key color and picking the color scheme or building your own color
scheme, which again, is about this many lines to say how those blocks relate to each other.
Then you can totally control which colors appear, which hues appear in the color scheme.
Audience member: Okay.
Jeff: So that's a good point ñ maybe we should offer a couple of color schemes specifically
designed at visual accessibility. Great, thank you.
Audience member: I have another question.
Jeff: Yeah.
Audience member: What about if there is a situation where I want the colors to dynamically
change on the user's choice? I want to give an application that the user can change the
color scheme dynamically, something sort of design UI based, something like that, which
is not CSS file based something, but it's all in memory sort of. Will this help in that
situation also?
Jeff: Dynamically changing color schemes is probably going to go over my head.
Matt: He wants you to show him the tool.
Jeff: What's that?
Matt: We're demonstrating the toolÖ
Jenny: Can we get a mic on him please?
Jeff: Yeah, can Matt have a mic?
Matt: It sounded like you were asking for something like the tool that Jeff demonstrated.
Jeff: I think he means in real time if an end user wants to do something with an application
that will change the color scheme in real time.
Matt: Unless I'm missing it I guess I would imagine you would build something almost exactly
like what you demonstrated there, which was skinning the widgets on the fly.
Jeff: Yeah. Okay.
Audience member: I have one question over here.
Audience member: I had the exact same question. The application that we work on has the capability
of user choosing themes, which are nothing but style sheets. I would probably think that
it'll be useful for us to have like a generator where I can pick and it can build the style
sheets for me using Y.Color. The last question is related probably.
Jeff: That's exactly what you saw today. It's going to be a tool and you'll be able
to do that, press a button, and get a style sheet. Also you can keep pressing a button
and keep making style sheets and then you'll have them.
Audience member: Okay, thanks.
Jeff: I think we should cut off the Q&A now and give some time to Tilo for his presentation.
Thank you very much, those were good questions.
Tilo Mitra: Hey everyone. I want to thank Jeff, that was a really nice presentation.
I just want to take a little bit of time to give you a really quick look at something
that I've been working on for a few weeks after I joined YUI, which is responsive grids.
How many people here have used YUI grids at some point? Okay. How many of you guys are
actually using it now in like a project or something? Okay, that's pretty good.
Yeah, I've used YUI grids before obviously, and I really liked it, but I felt it was always
missing responsiveness. Just out of curiosity, how many of you guys who are using YUI grids
have some responsive behavior built into that grid? Okay, a lot less hands.
I wanted to just show you something that I was working on to solve this problem. I've
made a version of YUI grids, and this an exampleÖ Well, let me first talk about the issue here.
There are a lot of responsive grids out there ñ Bootstraps, Zurb, and there are a whole
bunch more ñ and I took a step back and thought about the issue. Matt actually helped me a
lot with this. I feel that for a lot of responsive grids out there, they kind of force a lot
of things down your throat.
Let's take Bootstrap as an example. The Bootstrap grid is a 12 column grid layout, and if you
want it to be responsive it has certain media queries that it feels are right, so usually
it's 480 pixels and below for phones. It has a tablet media query level, usually 768
pixels to 1024 for the iPad. Then it has a large desktop media query. Well now you have
the Nexus 7 out, we have iPad minis out, and some of those lines are getting more and more
blurry. That's one issue. The other issue is this 12 column layout that a lot of grids
kind of force down your throat.
I wanted to show you something that we've been working on here at YUI, which is this
grid builder. We think that a grid should work to help you build the application that
you want, and you shouldn't be trying to conform your application into a specific grid.
What we have here is a grid builder and you can choose a bunch of properties here and
it automatically generates the CSS for you. For example, I can take anywhere from a 12
column to a 24 column through a 36 column, whatever I want. You can choose a specific
width, or you can have a fluid or fixed grid. Let's see if I canÖ You can choose whether
you want to make it responsive or not, and the CSS here is actually going to be generated
on the fly. I have let's say a 6 column grid, you'll see a lot less CSS.
The other thing that we were working on is media query support. Instead of forcing specific
media queries down your throat, right now there are these 4, but the goal is to add
more media queries and you can add or remove the ones that you're interested in. Let's
just keep them in here for now. I have to fix that little bug there.
The other thing we were working on is responsiveness. Do you want your grid to be responsive or
not responsive? Responsiveness, for certain behaviors, the grid goes down to 100 per cent
collapsible columns under specific screen width.
If we take this now, take the CSS that's generated from this, and put it into an example.
Here's a simple page with the grid overlaid on top of it so you can see what's going
on. It behaves just like a responsive site would, so you have images there, you have
columns that go down 100 per cent width, but you can also keep grids on mobile devices.
So if you have an iPhone and you want something to be a grid on a smaller screen size, you
can do that. We've also baked in some support that was lacking in original YUI CSS which
is stuff like margin support, offsets, gutters, etcetera.
I just want to explain how this works. The whole concept behind this is one class name
that we've added to the existing YUI grids, which is yui-g responsive. If you add a yui-g
responsive instead of a yui-g, everything inside that automatically becomes responsive.
You can mix and match responsive behavior with unresponsive behavior, just like we have
on this site. Here we have a yui-g responsive with a yui3-u-1-3, and that gives you responsiveÖ
Sorry. Here we have a yui-g responsive with yui-1-4, and that gives you the responsive
behavior of an element that's one fourth at higher screen resolutions but at lower
screen widths it comes down to 100 per cent. Whereas in this case, we have a simple yui-g,
no responsive behavior, and that maintains sort of a grid even on smaller screen sizes.
This is something that I'm still kind of working on. One of the issues that I'd like
some feedback on, actually, is what happens to grids between the phone resolution and
the desktop resolution. In that tablet space where I think there's an opportunity there
to have grids that can offer some unique benefitsÖ For example, let's take a look at this one
fourth column again. If you have thoughts about this, please come and talk to me because
this is still something that we're working on. On a tablet you could imagine this becoming
two columns and two columns almost like a little grid, and then on a phone becoming
one single column again. That's something that we're working on, seeing how grids can
behave on a tablet versus on a phone versus on a desktop. But the whole idea behind how
we're approaching this is that instead of giving you one CSS file and saying this is
your responsive grid as a lot of other people do, we're letting you generate differentÖ
letting you essentially customize your grid to how you see fit and then based on that
we might take specific variations and put them on the CDN as standard CSS files, which
we feel are the most common ones that people would need.
This tool is actually out already. As you can see, you can view it on, it's on Heroku
right now, and we might pull it in to YUI Library when it's a bit more fully baked.
But I just wanted to give you guys a sneak peak at it. It's all written in JavaScript
and Node and it's actually using YUI grids to generate YUI grids.
So yeah, that's all I had to show you today.
Jenny: You first, over here.
Audience member: Hello.
Tilo: Oh, sorry.
Audience member: So I saw you generating a CSS we typically use to generate a mark up,
and CSS typically is tied with the YUI. So I couldn't understand. Could you just go
through the CSS which is getting generated?
Tilo: Right, so the CSS that's getting generated actually is generated through Handlebars.
The grid allows you to customize not only, as you saw, widths and columns, but also the
prefix of the CSS itself. Instead of using yui3-g, if you could use yui3-row, and instead
of using yui3-colunm you could use y-column. Everything is generated using Handlebars,
so that's how it's working under the hood. The variables are getting fed into a Handlebars
template that generates the CSS for you.
That also actually reminds me ñ the grid is actually, in terms of file size, is actually
pretty small because what we say is if you have responsive behavior then you have media
query support, and if you have media query support then you probably have CSS 3 support
in the browser. For everything inside the media query we use CSS 3 attribute selectors,
which lets us essentially group a lot of CSS styles into a single rule. The CSS that's
generated is actually pretty small. I think for a 12 column grid it's about maybe I think
it was 9 kb of CSS. I have to double check, but it was actually smaller than the Bootstrap
grid CSS from what I remember.
Audience member: If you can use the grid builder on the Heroku app, couldn't you just generate
CSS inside of the app that you're actively creating downloads and things like that?
Tilo: Totally, and in the grid builder app you saw the yellow columns, and that's actually
the CSS getting fed into that yellow column, that yellow sort of bar. That's essentially
what's happening in that.
Audience member: So how's the performance on that like if you're doing it inside of
a whole bunch of views and things like that?
Tilo: I haven't tested performance on that specifically because I think that grids are
something thatÖ It's probably something that most people will pull down from CDN,
so I don't have specific performance metrics on that to show you today.
Cool. Okay, cool, thanks.