CSS Algorithms Lara Schenck
KATIE: Hello. Hi. Oh, all right. How is everybody doing? Yeah? Whoo! I know we’re all hungry.
But this is our last talk before lunch. And I think it’s gonna be an amazing one. We have
Lara Schenck here to talk to us about CSS algorithms. And so, Lara’s fun fact that she
gave me is that she grew up on a llama farm in rural Pennsylvania, very small town. And
I asked her, well, can you tell me some cool things about llamas that people wouldn’t necessarily
know about in their everyday life that’s llama free. At 4H competitions, there’s a bunch
of llama categories that you can enter. So, llamas can do agility runs. Kind of like,
you know, you’ve seen the dogs that jump over hurdles and they go in between poles. That
was not her specialty, though. Her specialty was the llama costume category. Where you
dress up yourself and you dress up your llama. And she won a blue ribbon for her rendition
of she was the tinman and the llama was the cowardly lion. And she said there’s probably
a picture of this somewhere so I’m going to really encourage her to have her parents take
a picture and send it to us so we can go and find it later and see a picture of her prize
winning llama costume. All right. So, let’s give it up for Lara Schenck. Take care.
[ Applause ] LARA: Hey, everybody. Wouldn’t it be great
if I want in a tinman costume? Yeah, I don’t know how I’m gonna follow that story with
my talk. I wasn’t really prepared. Yeah. Welcome to my talk. CSS algorithms. I’m really excited
is I have met so many great people that, oh, I’m giving a talk to my new friends. Isn’t
that nice? Nasty, friends, before we get started talking about CSS algorithms, we have to answer
a very important question. Is CSS a programming language? Fire emoji.
[ Laughter ] How many of you have seen this question where
there’s related drama about this topic on Twitter over the last year or so? Yeah? Okay.
Depends how many people use Twitter, I guess. I do have a question. Like, does this drama
come up in real life also, or is it mostly contained to Twitter? Anyways, we have to
answer this question before we talk about algorithms. So, I asked this question on Twitter.
First in March of 2018 before I gave version 1 of this talk. This is on 3.5.1 now I believe.
Is CSS a programming language? What did Twitter think in 2018? Any guesses? No. So but it’s
pretty split. 42% yes, 50% no, 8% I’m not sure. Not a huge dataset, 129 votes. But the
answers to kind of the responses in the comments are very varied. So, it was either like, yes,
absolutely. Or, of course it’s a programming language. Or, I don’t really consider CSS
programming. Or you can’t call styling a web page programming. It’s not really a programming
language. And things like that. So, after I gave this talk a little bit, before I started
giving it again this year, May of 2019 I asked this question again. And I was like, nobody
is going to answer. Okay, Lara, we see what you’re doing. We saw your talk. Okay. No.
This time [ Laughter ]
This time the poll had 5324 votes, which is definitely the most activity I’ve had on a
Tweet before. And the noes increased. I was like, what’s happening? What’s going on? And
not only were the same kind of varied responses in the comments, but there were also people
that kind of specialize in HTML and CSS that were saying that I never call myself a programmer.
And things like, why are we concerned about what CSS is? We should be concerned about
what it’s doing, et cetera. And things like stop asking this question. Don’t wake the
beast. So, stop. Like, everybody, stop. We have to answer a different question before
we talk about is CSS a programming language. What is a programming language? Before we
decide whether or not CSS is one of these things so, not surprisingly, there are many
fields of research and people have dedicated their entire careers to answering this question.
And we can’t be really specific about what a programming language is because there are
so many types of programming languages. So, the definition kind of boils down to there
are lots of different ones. But could boil down to a formal language for instructing
computer to perform tasks. This is Wikipedia and several others. Some good articles out
there. The important part here is language. It’s a language. And there are different types
of programming languages. And these kind of fall under the categories of programming paradigms.
And we use programming paradigms to both describe languages themselves as well as the style
of code that we write. So, the two main paradigms are imperative which is code that describes
code that tells a computer how to accomplish a task. And declarative. Where you tell a
computer what to do. So, the language the expressions in the language are saying what,
not how. And the main difference is the presence and absence of control flow. And so, control
flow is the ability to manipulate the order of executions of statements in a program.
So, control structures like if statements, for loops, imperative languages have these,
declarative do not. Any logic is baked into the statement itself. What are some examples
+ +, Python. These are what we usually think of when we think of programming languages.
Often times general purpose languages. Declarative languages are often, not always, domain specific.
They are built to function within a certain context. What are some domain specific declarative
programming languages? SQL. It is a declarative for data bastes. HTML, adding meaning around
content on a web page, CSS for styling the content on that web page. Loud and clear.
CSS is a domain specific declarative programming language. 100%. CSS developers program the
layout of web pages. boxes. Let’s be honest. Everything is a box. CSS programmers are box
programmers. Also 100%. Okay. So, cool. Like, great. Like, maybe I can win a Twitter argument
at some point. Good job. Why do we care about this? Why do we care if CSS is a programming
language or not? So, I want to talk about something called Turd driven development.
Of course this is a rift on test driven development, one simple in both is all code is crap the
first time you write if. It is not possible for a human being to write perfect code the
first time you write it. So, in test driven development, you kind of counter this by starting,
instead of writing in production code, write a failing test first. In CSS, we don’t really
have this kind of testing. You can kind of say the test is the design. It’s like, okay.
This is why am I failing tests? Yes, I see it. It doesn’t exist yet. So, yes, the test
is failing. Run the test with our eyes. What do we do? We write code to make the test pass.
So, all code is crap at first. We write some crap CSS. And then what happens? We stop.
Okay? The CSS, it’s done. I don’t have to write anymore. Oh, wait, the test is failing.
There was a change to the UI. Some new feature. The test is failing now. What do we do? We
write more CSS. The test is passing. Oh, wait, maybe there was a regression. So, now our
test is failing again. So, we write more CSS. Okay, whew, don’t touch it, erg is working.
And then we wait. And, oh, wait, new feature. More CSS. Test is passing, oh, no, another
regression. More CSS. And so on. Wait here we go. Oh, wow, what’s happening. Our tests
no longer completely passes. And this is what happens. But the problem is this is the web.
This is the frontend of our web applications. This is what People use. And this doesn’t
culture of how we program. So, what do we do? Ah! Oooo! This is so bad! It’s so bad!
All this crap everywhere. What do we do? Stop writing CSS. Start programming. Okay. So,
the thing is, programming does not equal logic, math, science, engineering. These things can
be part of programming. But programming in its essence as an art, as a craft, is writing
instructions for computers that other developers are able to read and maintain. And I think
if anything shows that CSS is a programming language, it’s that naming is really hard
and extremely important. Naming is one of the hardest problems in computer science CSS
got if. We’ve covered a lot of ground so far. Now let’s talk about algorithms. Now that
CSS is a programming language, how do we write algorithms in this programming language? Hm.
Algorithms 1013 let’s have another definition. An algorithm, a well
Defined computational procedure that takes input and produces output. This is from Thomas
Cormen who wrote the book, the introduction to algorithms that is assigned in many the
computer science course. I read the introduction. [ Laughter ]
Might revisit. Okay. So, a well defined computational procedure. Input and output. Let’s use this
little board to help us visualize. Common use for an algorithm, sorting. We have a list
of unsorted numbers. Our algorithm, the output, our algorithm should transform that input
into sorted output. Hm. What are some sorting algorithms? I know this crowd probably knows
some sorting algorithms. Bubble sort. Selection sort. MergeSort, quickSort. And could go on,
but we’ll keep it at that. Okay. What does an implementation of a sorting algorithm look
fine. If this was declarative code, it would be secured behind the source. We’re telling
not, not telling the computer how to do it. What about another kind of algorithm? So,
how could this possibly apply to boxes? Okay. So, our input is a stack of unsorted, unstyled
boxes. And our output, we want this to be a row of boxes. What kind of algorithm happens
in between? Well, display: Flex, absolutely. float: Left. Gasp!
[ Laughter ] How dare we? Yes. Floats still have their
place in this day and age. Okay. What is an implementation of these algorithms look like?
Well, this is what we see. This is declarative CSS. There’s a big huge algorithm under the
surface, but display: Flex is all we have to write. If we expand on this, this is what
declarative logic looks like, what, not how. And under the surface, this is what’s happening.
This is a little snippet of Rust code from the experimental rendering engine called servo
being pulled into gecko in Firefox. And this is where the wrap is happening. There’s an
imperative backbone to any code in CSS. Let’s have a iceberg metaphor. Love a good iceberg
metaphor. We have CSS on the top and imperative code on the bottom. Oh, my god, so many browsers
in here. They are complicated. can we call the CSS algorithms? Hm? Algorithm?
Why not? So, let’s go on the premise of all the work I have been doing. What happens when
we call that an algorithm? How far can we take this? Let’s update algorithms 101 to
CSS algorithms 101. Domain specific, declarative. These are magic words for CSS. And in term
little of a word like algorithm or any kind of analogy to general programming, it’s by
definition going to be different in CSS, domain specific, declarative, you have to understand
the domain to use these. A definition, a CSS algorithm is a well defined declaration or
set of declarations that produces a specific styling output. Me. So, key points here. Well
defined and specific. An algorithm is not a block of however long a set of declarations
can get. But you’re solving a specific problem. And I also think an algorithm is when CSS
goes from being this mundane styling language like font size, color, whatever, to something
where you’re like, whoa! CSS! Like, what’s happening? This is so cool. And you kind of
appreciate the fact that you don’t need to write so much code because the language is
doing it. We can understand the language and understand how to communicate with the browser.
So, you know what this notion is. This well defined set of declarations. So, as I was
thinking, I was like, okay. I’m going to pick out some common algorithms that people would
recognize. And the first one I thought of was this. Clearfix. So, oh, god, sad face.
Like, that’s a hack. Clearfix is not a fun algorithm. Could be an algorithm. Okay. What
about this? [ Laughter ]
So, this is a very long class name and not actually the name of the class. But you get
the idea. And this is very amazing and elegant that you can do this. Let’s say you have an
element way out here. Positioned relatively. You can no matter how far it’s nested in
nested into that, that child you can kind of pop out of that whole DOM structure and
stick it to the top right, bottom right, whatever. That’s cool. Positioning. It’s cool. Spaced
content. Has anybody used this before? It’s kind of a selector pattern. Lobotomized owl.
Someone named Heydon Pickering came up with this. This is a way of spacing content with
another content without adding to the top and bottom. This one I like. It’s kind of
a fluid typography. So, we use a viewport unit to make the size of the text element
more fluid. And this is a linear interpolation. Math. Cool. So, yes, that’s grid. Oh, my god.
These two lines of code, we can make so many grids. Add a couple of spans in there and
this is the most robust grid framework you’ll ever need. It’s not a framework. It’s just
code. Oh, my god, so great. So, CSS algorithm, a well defined declaration or set of declarations.
Specific styling pattern. I haven’t updated it. A CSS algorithm is a utility pattern that
lets the browser algorithms do the work. And I think a CSS algorithm also follows some
programming best practices. So, a single responsibility principle. Let’s say we have a set of kitchen
tools. So, the wooden spoon is so good at being a spoon. The whisk is great at being
a whisk. Spatula is great at being a spatula, knife, knife, et cetera. What happens when
a tool tries to do too much? [ Laughter ]
Sad. This is a spork. A spork. I’m sorry, spork, but you’re just trying to do too much.
It’s not that useful. People aren’t that excited about sporks. Although there is a restaurant
in Pittsburgh named Spork. Why did you do that? Anyways. Small, well named functions.
This was a good programming practice. How small should your function be? Small. And
then smaller than that. So, these are the words of Robert C. Martin in a book called
Clean Code. He’s kind of one of the inventors of a lot of agile software development practices.
Okay. This is all well and good. What about in the real world? You’re probably not writing
the next Clearfix. So, I work as a design engineer at a company called Penske Media
Corporation, PMC. We’re a big publisher with 24, I think, different very large brands all
on WordPress sites which is exciting. This enterprise WordPress environment. Sometimes
I call myself a design Ops engineer. I love my job. So, give it some hearts. These words
also equate to UI engineer. Also, the design systems at PMC. Also, the first and only frontend
developer in team of many backend developers. However, not anymore. We hired another frontend
developer recently and I see that as a major sign of success. Yes, a company that went
so long without frontend developers now has two. This is cool. This is like, yes. PMC
cares about frontend. So, my work has revolved around the development of a design system
called Larva. Yes, it is called our design system is called Larva. And it is an embryonic
design system. It’s a good name for it. It’s a little baby. It’s not this beautiful UI
library of components. But it’s tools and best practices to build modules and comments.
Embryonic. This is a laboratory to try out all these ideas, what is an algorithm? How
does this work? So, Larva was built inside of a project from a site called deadline.
And this is a WordPress theme. Kind of the base file structure here. And then drilling
into a source directory. This is an IT CSS architecture. Triangle CSS. I added at the
beginning of the project a directory for algorithms. I was like, will this be useful? Would this
will we actually add anything to this? And yes, there were like 20 something algorithms
in here afterwards. So, kind of proved to be this useful naming convention and useful
way to think about styles. And since this project completed, the process has been like
moving all of this code into a shared repo. So, project structure that might be familiar
to some is the monorepo structures. This is like Laravel 1.0 and these are npm packages.
We have kind of the CSS npm package. Inside one of these algorithms, a glue, which is
a pretty weird name for a style. There’s a SaaS file, or a CSS file. And an HTML file
to give an example of what the markup is. And a glue is this algorithm. But we’ve kind
of turned it like design systemed it to be more reusable and a little more robust. So,
it has different namespacing and we use the term glue because it’s a nice mental model
for what it does. Glue a UI element within another UI element. And this was used like
15 times in the deadline project. Not only by me. Mostly not by me, in fact. So, there
was another contractor who was like a little more junior and they understand what this
did. Whoa, this is a cool way to communicate the CSS concepts that might be a little hard
to understand at first. Another algorithm, space children. Whoo space children. So,
this is the lobotomized owl. And design systemed, this looks like this. So, I could have some
progressive enhancement inside this algorithm. It’s kind of pulling this functionality into
its own little node. Into its own little section. We can do really interesting things. So, column
gap is a new property in some browsers and we can add this feature query inside the algorithm.
In markup, this is what it look like. So, pretty heavy use of utility classes. And the
algorithms are kind of layered in among the other class names. Like an onion. But algorithms
can also be useful for stuff like this. So, if you’ve ever got an design and you’re like,
god damn it. This is a really pretty border. But this is a very annoying thing. Why do
I have to develop this? So, you can be like, I’m gonna pull this out and I’m just gonna
write this border. This border code. And if it shows up in one design, it’s probably going
to show up in another one. So, an algorithm can be a nice way of handling that. Okay.
How to write a CSS algorithm or realize you don’t need to. How to write algorithms? How
you write an algorithm in an algorithm interview? Has anybody done a whiteboarding interview
or an algorithms interview? A few? Yeah. No more comments.
[ Laughter ] Okay. So, the steps. These are kind of taken
straight out of cracking the coding interview. Plan your algorithm. Then you run a brute
force solution. A not optimized version that steps through piece by piece. Slow, but maybe
it works. And then you do a walkthrough in the interview to make sure the algorithm is
functioning and then optimize it. Layer different optimization techniques. What about writing
CSS algorithms? Well, you start by planning. Planning out the algorithm. Then you write
brute force solution that’s not quite optimized and walkthrough. Same thing. Except there’s
some pre work when you’re writing a CSS algorithm which is doing a turd check. So, you’d stop
before you write any CSS and say to yourself, should I actually be writing new CSS? Like,
what is going on? Have I solved this problem before somewhere in this codebase and why
can I not use that again? So, just a quick moment to be like, wait, is this really the
problem I should be solve something and then you plan. Pseudo code and boxes. Pseudo coding
CSS and defining your problem. What is this thing you’re having a hard time with that
you need to solve? On paper, I love drawing boxes on paper. I love to do other things
too. But sometimes this is really fun. Also because writing things on paper and like whiteboarding,
there’s research that shows we have better human beings have better retention when you’re
doing things in physical space like that versus drawing boxes in Illustrator, et cetera. Also,
printing out the design and marking it up in that way could be really useful. Figure
out what if you’re working with an existing system, what patterns are already provided.
What do you need to write new? And a brute force solution. Spaghetti, write gross code,
that’s fine. And remember the assumption, all code is crap at first. Don’t write it
in the actual stylesheet. Write it somewhere else. Instead of inside the main application,
you could have a separate file. This recent project I was having a file called scratch
pat.scss that was added to a test environment, not to an actual application. It was a safe
space to try out the CSS. This is what it ends up looking like. Working with boxes.
CodePen is like a product for this specific use case. For writing frontend code outside
of a regular environment. And this is a the little border arc. Our story border arc
from before. So, do a walkthrough. We love resizing our browsers. Web developers are
like, yes. Not going to test it in a different browser, but I’m gonna resize it a lot in
this one. So, that’s a walkthrough. But test it in other browsers. And it’s a lot easier
to do that when it’s a small piece. So, it’s easier to do it now. Ask yourself, is every
declaration essential? Are there any dependencies? Does this algorithm need to be applied with
another class and why? And this you can have a Robert C. Martin in the back of your head
that’s like smaller, smaller codes. And then you can optimize and refactor and document.
This is when the magic happens. When our poopy code becomes a flower. Of course. This is
how programming works, right? And this is when you’re moving that crap code, the fact
that you need to move it into the actual codebase, that refactoring will happen naturally. So,
moving from this set of boxes to an actual layout will improve your code. Document. So,
inside our deadline program library we had documents, a paragraph about what it’s doing,
how to use it. And then boxes. Show what it’s doing. So, I feel like this with this process
turd driven development can kind of become more like test driven development. With CSS?
What? So, what if we had thought about it like, oh, our test, instead of being the entire
design, is a smaller piece of the design or a specific piece. We run the test with our
eyes still and write our crap code. But the refactoring, putting it in the code, can give
us that additional step of refactoring. Again, a beautiful flower. Refactor the missing piece.
Let’s be real. But less looking poop is greater than regular poop. But what if, so, this is
a little experiment that’s coming up here. What if so, test driven development. I have
I love writing tests. There’s some magic, like straight up magic when you write good
tests. And I want to do this with CSS. How can we write unit tests for CSS? Domain specific
declarative tests? I had an idea and wrote enthusiastic blog posts about it. Testing
algorithms. So, warning, this is a big code slide and kind of a prototype of something
what it could look like. So, this is essentially a couple of test methods that log to the console.
And the crux is you’re testing boxes against boxes. So, you’re figure out relative values
of certain positions and boxes and comparing them. And what this looks like in practice.
The unit test might be with the minimum amount of HTML. And we’re logging into the console.
But this could also be an integration test on an actual application. I ordered this to
the deadline staging environment and actually found a problem with this. So, this showed
me that there should not be space below the last item. But there was a different set of
styles that was adding that space, which is incorrect. That will cause problems later
because if someone adds another widget to the side bar, it’s gonna be too spaced out.
And that’s what cause this is like turd driven development. Especially with CSS, oh, you
override it instead of going back to change the actual issue. Ah! This could be cool.
So, my inner critic is like, overengineering much, Lara? Like, why are you it’s just
CSS, jeez. My god. But then I’m like, no. That’s the kind of thinking that causes turd
driven development. Say no to that. It’s okay to think about CSS like this. And in fact
like the rest of software has come up with many an antidote to turds. So, general software
on this end is kind of like, whoa, look at all these things we do to control our code.
To create better environments and develop better programming practices. And then on
the other side we have frontend and UI that has a lot of these things as well. So, design
systems, atomic design, progressive enhancement. Many a CSS architecture and naming convention.
And maybe these things are not that different. So, there’s a lot of the same concepts that
bridge these these two kind of areas that could seem separate. But testing. I think
we could do more of this. Okay. Conclusion. I’ll tell a small story time. Okay. How the
math hater became a programmer. This is me. 14 year old Lara in 2003. I hate math. Okay?
I was a staunch math hater throughout my childhood. I loved art class and horses and llamas. But
at the age of 14 I was starting to become a little bit anti llama and just kind of embarrassed
about that. But I loved art class and horses and Green Day. Which I didn’t put up there.
2009. A little bit larger Lara. I had some blond in my hair and glasses. I was in college.
20 years old? Art school and I had a weird idea for a video game and learned how to code.
I had a lot of freedom in school and very supportive parents. And then fast forward
to 2015. I had been working as a freelance developer for a while and I wrote this article
for CSS Tricks. Tales of a non unicorn: A story about the trouble with job titles and
descriptions. This was about a role, the UI engineer/interaction designer. And I was like,
And in the interview they asked me FizzBuzz. And FizzBuzz, for anybody unfamiliar, is sort
of this beginner’s algorithms question. And in the interview I was like, what? Why would
anybody do this? I had been so far removed from what this algorithm in computer as someone
self taught from an art background. And after I wrote this article, which became a little
bit viral, there was a post on Reddit. Designer applies for JS job, fails at FizzBuzz, then
proceeds to write 5 page rant about job descriptions. I was like, whoa. This was on the front page.
There were all these horrible comments coming into the article. Like, awful stuff. And sob,
after this experience from like 2015 to 2017, I was like, oh, hell no. Like, I am not a
programmer. Computer science is not what I do. I do HTML and CSS. Computer science, not
for me. Programming, not what I do. Who are these people? No thanks. I had like these
two years of rebellion against that kind of identity. And late 2017 I ended up getting
an interview for a job I was super excited about that was going to be an algorithms interview.
No question about it. Okay. I have to learn this. Swallow my pride, FizzBuzz, let’s do
it. I wrote all these blog posts and put myself through computer science boot camp. And I
was like, wait a second, this is for me. This is cool. I love this stuff. And it’s not so
different than the concepts in HTML and CSS. And in 2018 I proposed this original talk
of algorithms of CSS for CSS ConfEU to bridge the gap between CSS and computer science.
And throughout that talk, CSS something I knew well before kind of went from like
CSS to like, wow. I understand what CSS is doing. Like, this is freaking amazing. I love
CSS. And I realized that this is kind of the wrong metaphor. It’s not like this. It’s like
this. So, computer science is like the big like, you know, mom giving everyone a hug.
All these nice things in here. So, CSS, they’re all together. So, to put a button on this.
Here is FizzBuzz in CSS. [ Applause ]
Okay. Okay. 2019. Is blank a blank? Is CSS a programming language? This is like a fucked
up question structure. Because you can sub out the terms and have like is depression
a treatable illness? Is non binary a gender? When you ask a question like this, it’s opening
up the option for people to say no, when as soon as you start excluding something from
something else, that’s a sign of much darker stuff. So, this is a smelly question. This
is a culture smell. The answer is, of course. So, I’m like, what is going on? Why is this
happen something why are there designers designing systems at companies, but they can’t have
anybody from the engineering team implement them because HTML and CSS are not considered
part of engineering? Or why are there developers coming from full stack bootcamps or presenting
themselves as full stack developers who don’t understand fundamental characteristics of
CSS? Is CSS not part of the stack anymore? What’s going on? I was describing this to
someone at my coworking space, kind of an old school computer science guide. His name
is Dick. And why are there so many people that don’t think CSS is a programming language?
What’s going on? He said, well, Lara, when it comes to computer science, and in computer
science, there’s an 800 pound gorilla in the room and it’s called a testosterone. And I
was like, okay. Wow. Okay. So, maybe this is the truth. Is this what like, okay. But
I don’t think the answer is to not talk about it. So, when I see responses to this question,
it’s like, stop asking this question. Don’t talk about it. Questions like that can be
good because it brings out what we need to address. So, what if instead of, you know,
people who know other types of programming not learning HTML and CSS because they’re
not programming. I know programming. I don’t want to learn that, it’s not my thing. And
web applications suffering because of that. That’s on one side. And we have people like
me and I’m sure some people in this room who were focused in HTML and CSS and told you’re
not a real programmer. And therefore you develop this kind of oppositional identity, I’m not
learning that. That was me. What if we do this, CSS and HTML are this little golden
springboard. You have little people like me, little baby Lara, or people with non traditional
backgrounds who don’t necessarily have the ability to go into computer science programs,
et cetera. HTML and CSS can be this kind of springboard into technology. And not just
people that look like me. Of course, like anybody can do this. And it’s also kind of
a metaphor for creativity. Because I’m not that good at drawing people. I put a monster
in it. It has to represent something. Creativity. Let’s have more creativity and honor technology
teams. HTML and CSS, this golden springboard. My question is, why aren’t we valuing these
skills more and embracing this technology? Instead of this is not for you, saying, yes,
you are a programmer. Come, learn more. Thank you.
[ Applause ] KATIE: Wow. Okay. Yes, yes. Yes, yes. Yes.
You’re awesome. Yes. I am so excited that we are going to lunch right now because I
would feel really bad for anyone who had to follow that up. Thank you, Lara. That was
amazing. Yeah. Thank you. [ Applause ]
All right. So, it is lunchtime. Before you go, I have two things that I need to do. The
first thing is that I need to tell you back in this room at 12:30 because folks have been
so interested in learning more about how the closed captioning works, that Mux has sponsored
a special presentation where the folks from White Coat are going to show us how their
closed captioning works and how they transcribe things so quickly. And the second thing that
I need to do, because my 8 year old daughter and my 6 year old son are in the back of the
room is I need to tell you all a joke that my daughter told me.
All right. So, why is a seagull called a seagull? Cause if it flew over a bay, it would be called
a beagle. [ Applause ]
All right. So, everyone go and enjoy your lunch and we’ll see you back here or in the
scythe HPE room when lunch is done. test this is test.