
Show HN: Myth – CSS the way it was imagined - ianstormtaylor
http://www.myth.io/
======
pvnick
Wow. I'm shocked at the disgusting responses I'm reading here. No wonder
people get terrible anxiety about releasing their hard work for feedback.
Hacker News seems to be a den of vipers, waiting to strike at the tiniest
opportunity to nitpick. And then folks have the gall to bicker and argue over
whether the project even has fundamental merit, on the very thread that the
author tries to show the "community" what he/she has made. I've been working
on a project myself, something I'm passionate about and looking forward to my
own "Show HN" thread, but this trend of negativity really makes me hesitate.

I think this is a really cool project, and I commend ianstormtaylor for
pushing the envelope and advancing the state of the web. Good job!

 _edit: I understand criticism has its place in Show HN. But for God 's sake,
I had to scroll _all the way to the bottom_ to find some kind words of
encouragement. You folks should really read some Dale Carnegie_

~~~
EasierLikeThis
I can't decide if people are overly competitive and frightened with the
increase in the developer population, or if we're just bitter and cynical
towards anything we can't put our name on.

~~~
__--__
You know those meetings where three or four guys go back and forth trying to
prove who's the smartest guy in the room? HN is that on a larger scale.

I can't help but think this tendency of ours can't be hacked into something
more productive, but I have no solution as of yet. :)

------
JimDabell
This only polyfills some of these features in the most superficial way. To
polyfill some of these features according to spec., you need to do it in the
browser.

For example:

    
    
        <!DOCTYPE html>
        <title>CSS Variable Test</title>
        <style>
    
            head {
                display: block;
                var-mycolor: blue;
            }
    
            :root {
                var-mycolor: red;
            }
    
            title {
                display: block;
                color: var(mycolor);
            }
    
        </style>
    
    

If I load that document in a browser that supports CSS variables, the title
will be blue. But if I run it through Myth, it drops the blue rule and makes
the title red. This is because CSS variables are inherited throughout the
document and can be overridden at any time. The calculated value of the CSS
property that uses the variable depends on the document structure.

Likewise with calc() - if you multiply values like in their example, it works,
but if you try to add two values of different units (e.g. 2em + 30%), it
silently falls back to requiring browser support for calc().

This might be useful in narrow circumstances, but it should have big warning
signs because it doesn't come close to being a proper polyfill.

~~~
dgreensp
Aha, yes. This is pretty damning.

------
crazygringo
> _Myth lets you write pure CSS while still giving you the benefits of tools
> like LESS and Sass._

Having a "polyfill" is certainly a valid justification. But this doesn't come
close to LESS/Sass -- I'd argue that the main feature of those is nested
rules, and then mixins.

Variables and calculations are great, but most LESS code I've encountered uses
nesting and mixins to a far greater extent. Advertising the project as "the
benefits of tools like LESS and Sass" seems misleading, and seems to set up
expectations that Myth doesn't fulfill.

~~~
ianstormtaylor
Yeah that's definitely true that it doesn't support all of the features of
Sass or LESS. But it does support some of the core features that people use
everyday, and could replace a lot of the need for preprocessing.

From everything I've seen nesting rules is an anti-pattern. It's useful for
writing code as fast as possible, but for any project of reasonable size
maintenance is a far bigger worry than LOC per second, and nesting makes for
some horrible to maintain CSS. Until we have native extending in CSS you're
much better off going the "one-class-per-element" route for maintenance.

As for mixins, I actually think they are an anti-pattern too. They're usually
used for two different things. The first is to simply make vendor-prefixing
easier, which this library already eliminates. For example the LESS homepage
shows mixins being used when really it's just a regular old `border-radius`
property. And the second is for extending classes with groups of properties,
but mixins are a bad practice there because they just duplicate the code
instead of doing any smart inheritance, so you end up with huge code bloat.

The real missing feature from preprocessors in my opinion is the idea of
"extending", but I wanted to wait for the CSS spec for extensions to be more
thought out before adding it, in case it varies a lot from how preprocessors
do it.

\---

The reason this came about is because we went back to writing pure CSS at
Segment.io (after having used LESS, Stylus and Sass at different points) and
realized that we shouldn't need to give up things like variables just because
we don't want the extra weight of a new syntax.

~~~
crazygringo
If you think nesting rules is an anti-pattern, I feel like you've never worked
on a large-scale web project. When you need to ensure that sections of pages
are self-contained, and components likewise, you _need_ to start every rule
with ".titlebar" or ".large-button", etc. Nesting just makes your CSS much
cleaner, by writing ".titlebar" once instead of 30 times (for each of the 30
rules that apply to things inside the title bar), and making your stylesheet
more organized and easier to browse. It doesn't mean you need to nest every
single element, but it's a _fantastic_ tool for organization, particularly
when multiple people are working on a project.

Likewise, I feel like you're missing one of the main points of mixins -- that
they allow you to repeat commonly used calculations that may involve multiple
properties in complex ways. For example, a mixin I often use lets me create a
vertical gradient by specifying a base color and a brightess spread amount,
instead of start/end colors. It's incredibly valuable, and it also allows me
to automatically support IE and specify a fallback base color. Mixins are
hugely valuable for creating classes based on sprite positioning too. Going
back to pure CSS without mixins would be a huge step backwards in
maintainability for any project of decent size which I've worked on.

Obviously, both nesting and mixins can be abused or used inappropriately, but
I'd never call them anti-patterns -- to the contrary, they're essential for
front-end development on sites that reach a certain level of complexity, for
cleanly factored code.

~~~
ianstormtaylor
I could be wrong, and they both _can_ work if extreme caution is applied. My
general take is that they make it way too easy to do the wrong thing though,
at very little gain (assuming other parts of your system are setup properly).

\---

For nesting, the problem with nesting is that is messed with specificity way
too much. Since adding an extra class inside a nested block is trivial, people
start adding more and more. But even just 2 classes is already too much in my
opinion. Ideally each component would have classes on each of its inner
elements, so that the component-level styles always have a specificity of
0010:

    
    
      <div class="textfield">
        <label class="textfield-label"></label>
        <input class="textfield-input">
      </div>
    

If you have a setup like that, you never need to nest because your CSS ends up
looking like this:

    
    
      .textfield {}
      .textfield-label {}
      .textfield-input {}
    

And that way all of your selectors are minimally invasive in terms of
specificity. The problem with nesting is that you end up with selectors that
have a specificity of 0020, which means anyone implements those components
needs to be sure to achieve that level of specificity or greater to override
them.

But honestly, when working with small components there just isn't that much
typing to justify the possible downsides. Sure I have to type out the extra
selectors in the beginning a few more times, but its worth it to do without
the unintended consequences of the magic.

The one case where nesting really does come in handy is for page-specific or
app-specific stylesheet files. Places where you are adding the "glue" CSS that
should always be namespaced to avoid collisions.

\---

For mixins, I feel like they only seem useful if the components you're using
are broken into small enough pieces to begin with. For example, if you want a
complex gradient system on your buttons, put that inside your button styles
and then don't touch it from anywhere else. If you're constantly needing to
use a mixin to re-define those styles, something else is wrong. Because
realistically how many different color variations of those buttons do you need
to make? It should be somewhat limited, and they should be able to exist in a
single file without issue.

Where things really get screwed is if you aren't versioning your mixins (which
most people aren't doing). At that point, you're just tightly coupling changes
to that mixins across your entire codebase. If you want to change the way the
buttons implement the gradient, with the mixin system you go change the mixin,
but now you need to visit every other component that uses that mixin and
double-check that you didn't break anything.

Instead, if you didn't use a mixin and the component just contained its
gradient logic (slightly more verbose maybe, but way more maintainable) then
you don't have that problem.

The other solution is to strictly version your mixins using something like
Component and maintain your mixins in a separate repository on GitHub that
gets versioned, then that also works because each other component can peg the
version of the mixin it is using.

\---

My big takeaway from CSS though is that none of the solutions for it are nice
right now. And most of these problems should disappear (I think) with proper
native extension.

~~~
wallunit
You can use LESS's nested syntax in order to generate prefixed CSS classes
instead of nested CSS selectors, if you prefer them. That gives you the
advantage of prefixed CSS classes, but you don't have to repeat the prefix and
you have all classes with the same prefix grouped together, which IMHO makes
large projects easier to maintain.

    
    
      .textfield {
        &-label {
          ...
        }
        &-input {
          ...
        }
      }

~~~
ianstormtaylor
That is pretty cool. I think generally that the components themselves should
be more limited in functionality to the point where it's just not that big of
a deal to write out `textfield` two more times. As in, I think it's optimizing
for a case that isn't that important. If you write a component, the number of
times you're going to change the root class name of the component is very
small, so it doesn't need quick rename-ability. And then the number of nested
elements inside of it should also be small, so you don't have that many gains
there either.

------
xauronx
I've avoided the CSS preprocessors for some reason, something about learning a
CSS pseudo-language just didn't feel right. The idea behind this however is
awesome. You're writing simple, true CSS and it does the annoying work of
making it crappy CSS that browsers want. I might actually be able to get
behind this.

~~~
marknutter
There's nothing to learn. Even if you use nothing more than nesting it's a
huge boon to productivity and readability.

~~~
xauronx
Well, I don't know how to do nesting right now so there WOULD be something to
learn :D

Maybe it was that a clear winner never arose between LESS and SASS or maybe
that I always let things play out a bit before jumping onto a trendy
technology. I guess I'll have to just get with it since it's not really going
away.

~~~
sergiotapia
It's literally:

    
    
        .header {
            background-color: orange;
        
            p {
                font-size: 16px;
            }
        }
    

You nest the selectors and it spits out .header{} and .header p {}. Much
cleaner to write and maintain.

~~~
xauronx
Well, now I learned something. Also, that's pretty awesome. I could definitely
use that.

------
jackmoore
You all should be aware that it is impossible for CSS
preprocessors/postprocessor to fully replicate calc() and var(). For example,
you won't be able to do something like calc(100% - 200px) or have scoped
variables.

~~~
alanh
Yes. This should be the top-voted comment, IMHO. Myth is fairly misleading!

------
codegeek
Oops. Landing page font is almost unreadable in Chrome Version 30.0.1599.101
(Windows XP)

~~~
edwardy20
Chrome works for me. (Version 31.0.1650.63 on Ubuntu 13.10)

~~~
dangrossman
It's only an issue on Windows because Chrome uses GDI to render text there,
instead of DirectWrite like Firefox/IE use.

~~~
maxerickson
A lot of the text looks bad in Firefox on XP.

~~~
dangrossman
Because Firefox also used GDI on XP. It doesn't on newer versions of Windows.

~~~
SiVal
What's the workaround for this problem? This is the first I've heard of it,
and it looks pretty bad.

~~~
buugs
Test on windows?

A lot of thin fonts look bad in Windows especially chrome. So you could
probably make a safe bet that if a font is thin on OSX then it will be much
thinner (sometimes unreadable) on Windows.

If you want to use thin fonts only use them for the titles (but even here it
looks like that causes problems).

------
eknkc
It's basically a rework
([https://github.com/visionmedia/rework](https://github.com/visionmedia/rework))
distribution with a couple of plugins bult in.

I you need finer grained control, take a look at rework itself. We have been
using it for a while and it's just great.

------
chc
Despite its assertion to the contrary, that looks like a preprocessor to me.

~~~
publicfig
I agree, I'm not sure what postprocessor would even mean in this context.

~~~
kcorbitt
I think they chose "post-process" based on the following feature:

    
    
      Taking plain CSS as an input also means you can use Myth to post-process anyone else's CSS, adding the browser support you need, without having to re-write their code in a completely different syntax.
    

What distinguishes it from LESS or SASS or whatever is that the input has to
be valid CSS, as well as the output. Their claim is that it makes your CSS act
now like it will in the future once the version of the spec they're targeting
has been fully adopted.

~~~
ricardobeat
LESS, SASS and rework/stylus are all supersets of CSS, so they can too "post-
process" anyone else's CSS.

~~~
amitu
That would be a noop with LESS/SASS unless the input CSS was not a "valid"
CSS.

This project will "enhance" "normal" CSS to take care of polyfill, which alone
is a win. Take _any_ CSS file you got, and it suddenly has all browser
prefixes thanks to this tool. This is something LESS/SASS _can not_ do.

~~~
ricardobeat
Styl(us) can. My point is that calling it a 'post-processor' is a misnomer.

------
badman_ting
Very cool, but once you start working in something like LESS or Sass, it
totally changes how you write styling and becomes something more than "CSS
with variables". The possibilities they offer are more than features, it
changes your entire workflow. Personally, I won't go back.

But besides all that, it's pretty sweet to have something more like "CSS with
variables". That can come in super-handy sometimes.

------
djokkataja
The site looks gorgeous and is perfectly readable in Firefox 25 on Ubuntu.

Also this looks pretty neat; I wasn't super interested in learning to use
Sass/LESS or working it into my development cycle, but this looks like a good
step towards not having to make much of a change while still reaping some nice
benefits.

------
coderzach
This looks pretty cool. It should probably explain that it's a static subset
of the spec, and not actually a polyfill for the spec itself. Since the spec
allows for dynamic, cascading variables, as well as dynamic calculations.

------
Kiro
What's up with the font? It looks like a disaster on Chrome @ Windows.

~~~
dangrossman
All custom fonts look like a disaster on Chrome in Windows. It's the only
browser that uses GDI to render text in Windows where Firefox/IE use
DirectDraw. All fonts end up being rendered very thin, and if they're thin to
start with, that causes discontinuities in the glyphs. It also affects the
color; the rendered color may be significantly different than the text color
specified in CSS.

It's been an open bug on Chromium/Chrome for several years.

~~~
sergiotapia
Link to the bug?

~~~
theandrewbailey
[http://code.google.com/p/chromium/issues/detail?id=137692](http://code.google.com/p/chromium/issues/detail?id=137692)

~~~
omegote
This is depressing. They closed the comments so they don't have to hear
anything from their userbase. If this kind of problems happened in Mac, the
bug would have been resolved for years.

------
prezjordan
Wow what a great idea. Nicely executed, love the demo page.

------
Pxtl
"Myth - CSS the way it was imagined "

I totally read that completely differently. Complete document/style separation
_is_ a myth.

------
ozh
lots of readability issues on this page. Purple tiny text on black background
!= easy to read.

------
abvdasker
Definitely going to give this a try. I really appreciate the apparent
simplicity and creativity of this tool. It avoids the need to learn the odd
syntax of LESS/Sass for those of us who need reliable cross-browser support
while providing many (though not all) of the benefits of precompilers.

Seriously great work.

------
lstamour
Long-term I'm not sure how well this will work.

After all, SCSS was based on "CSS3" so we wouldn't have to rewrite our CSS.
It's still around ... so we don't have to rewrite our SCSS.

I'm happy to see innovation here, but I also wish IE would just auto-update
already. :D

------
iLoch
Man I really hate when the creator of the site expects me to scroll down. I
have a 1080p monitor, if I can't see any content at that height I have to
assume there isn't any.

~~~
ldh
Agreed. It seems to be a design trend that's on the upswing lately, and it's
frustrating. I encountered a mobile site yesterday that did that... to me it's
the equivalent of the "click to enter" home page of bygone days. Uh, no
thanks.

~~~
jonesetc
I honestly can't tell if your guys are being serious. Click to enter was
absurd because they were page loads just for the sake of page loads. Scrolling
down is just spacing out your content to get a visual feel. This one in
particular is giving a short explanation to let you decide if you want to
scroll down first. There's no cost here, just the courtesy of not overwhelming
anyone who isn't actually interested in the details.

~~~
iLoch
I don't have a problem with the concept if the fact that I have to scroll is
obvious. I opened that page, read the title and "What am I doing here again?"
I'm on a Mac so there's no scrollbars. Do you just want me to guess that
there's something down there? The least you can do is hint at the content
below.

~~~
userbinator
> I'm on a Mac so there's no scrollbars. There's your problem.

~~~
iLoch
Congratulations on being an ignorant elitist. I have both Mac and PC and have
been using both for a very long time. The point of my statement is that
whether or not I can see my scrollbar, I shouldn't have to look at the size of
the bar to determine the functionality of the site.

------
transfire
I wish there were a revolt against W3C. They have consistently made a mess of
everything they touch (and take forever to do it). Why reinvent the wheel yet
again with another fuglier syntax? We already have Sass and LESS which are
widely used and quite beloved. Just adopt the best of those and save us from
yet another "XSL-FO". Please! For God's sake, man!

~~~
jsmeaton
So, in your world, we'd all have to compile our stylesheets? I don't like that
idea at all.

~~~
jrochkind1
No. The reason sass or less require compiling is to support features that
aren't actually a part of the CSS standard, so they need to be compiled down
to things that are a part of the css standard.

In his world, the best of those features would be part of the CSS standard and
supported by browsers, so you could just give them right to browsers without
compiling anything.

~~~
jsmeaton
Well I'm glad I phrased it as a question then :)

------
crystaln
"post-processor"? What does that mean?

Looks a lot like a pre-processor to me, except that its functionality is
limited to what can be defined by pure CSS. I'm not sure why you would choose
this preprocessor over one with more functionality.

Somebody must have thought it was a good idea to have gone through so much
effort, so perhaps I'm missing something.

------
ultimatedelman
this is cool, but the problem i have with the variables is that it's based on
a suggestion of a spec that mozilla hasn't even finalized... if it changes in
the future, this could break

------
nawitus
Can Myth postprocess LESS output and guarantee that it'll "just work"? I like
the vendor prefix feature (although there's a 'LESS Prefixer' project too).

~~~
peferron
Is there anything wrong with LESS + Autoprefixer? I'm using Sass +
Autoprefixer on a project currently and it works just fine.

~~~
nawitus
Yes, I didn't know about it :). I'll probably go with autoprefixer, but with
Myth I could also use some of the other features and perhaps aim for a slow
transition from LESS to CSS over the coming years.

~~~
ianstormtaylor
Totally, that's the idea :) — and yeah you should absolutely be able to post-
process LESS output and have everything work fine.

------
philliphaydon
Why do front-end developers not test their website cross-browser and platform?

The font chosen doesn't render properly on Windows with Opera or Chrome.

~~~
winterswift
Can confirm, the text renders miserably on Chrome in Windows 8. Somewhat
ironic considering the product being advertised.

For anyone wondering, here's what it looks like:
[http://imgur.com/XbZJpC6.png](http://imgur.com/XbZJpC6.png)

------
oneeyedpigeon
Interesting. Shouldn't the 2nd "a" in the right column under "Color
Manipulation" be an "a:hover"?

~~~
ianstormtaylor
Why yes, yes it should :) fixing now.

------
habosa
SIde note but I have never seen "Star on GitHub" before ... does that mean
contributions are not welcome?

~~~
ianstormtaylor
Nah, I just personally think the "Fork on GitHub" line is wrong because I'm
very rarely trying to go from a tool's site directly to the "fork" action.
Instead I think something like "Source on GitHub" or "View on GitHub" is more
appropriate. And since I just launched it, in this case I thought "Star on
GitHub" could work. I don't mind too much really, just anything but forking :)

~~~
habosa
Ah ok, that makes sense. I think "View the code on Github" is the best way to
say it. Star on Github reminded me of those people who bug you for reviews on
the app store, which only helps you and not them. View the code is a two-way
trade.

------
pc86
Tiny text is unreadable on Windows Chrome.

------
fiatjaf
I imagine a CSS where the outer divs submit to the inners (but only when I
want to).

------
kumarski
A little tough to read the text.looks cool.

