Show HN: Myth – CSS the way it was imagined

http://www.myth.io/

by ianstormtaylor • 13 years ago

357 152 13 years ago

myth.io

chc• 13 years ago

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

publicfig• 13 years ago

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

kcorbitt• 13 years ago

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.

_j5l32• 13 years ago

I think the idea is that, instead of writing x other style language (SASS, LESS, etc.) that is turned into css, you write css that turns into different css. This means you can use other SASS/LESS/etc... and myth together.

ollysb• 13 years ago

Preprocessor: non css => css (e.g. less, sass)

Postprocessor: css => better css (e.g. myth, ?)

XaspR8d• 13 years ago

The reading I think they are going for is that preprocessors generate CSS from something else, while this uses (the platonic ideal of "true") CSS and generates the shambled code that the browser needs. But I could be way off.

metaphorm• 13 years ago

had the same thought.

when I saw "post-processor" I was expecting this to be some kind of browser extension or plugin that post-processes (on the client side) CSS received over the network.

it seems that they have basically just done a pre-processor that accepts css as input and returns css as output. its exactly like every other css pre-processor except that its DSL for pre-processing is a subset of CSS rather than a superset.

uses• 13 years ago

From that perspective, less.js is kind of a post processor.

prezjordan• 13 years ago

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

codegeek• 13 years ago

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

pistle• 13 years ago

"Who dragged a pencil eraser down my screen???!!! Oh... WTF?"

RALaBarge• 13 years ago

I came here to report the same thing. http://i.imgur.com/Htq6JIK.png

martin-adams• 13 years ago

Yup Chrome not so good, Firefox seems fine.

BadassFractal• 13 years ago

Is that the infamous issue that requires you to reorder font type imports in your CSS? I've seen this many times on Win7 in Chrome.

edwardy20• 13 years ago

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

dangrossman5• 13 years ago

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

franksmule• 13 years ago

Me too Chrome Version 32.0.1700.41 m Aura Win8 - Hard to read fonts

Kronopath• 13 years ago

Same here on Windows 7:

http://i.imgur.com/i5GwqIN.png?1

"Variablcs"?

jahewson• 13 years ago

The solution to this problem is to serve your web fonts as SVG to Chrome on Windows, or hint your web font with ttfautohint.

Raphmedia• 13 years ago

Pretty bad for a product aimed at front-end guys.

uno7• 13 years ago

Looks great in FF windows 7

Ygg2• 13 years ago

Looks the same in FF as in Chrome (missing parts).

lstamour2• 13 years ago

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

xauronx3• 13 years ago

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.

stormcrowsx2• 13 years ago

You've been missing out avoiding CSS preprocessors, they're fun.

dabernathy89• 13 years ago

I avoided preprocessors for a while too, but I can't imagine not using SASS now. Even if all it had to offer was nesting it would be worth it, but with variables and mixins it really shines.

marknutter• 13 years ago

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

xauronx3• 13 years ago

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.

dreamfactory• 13 years ago

It's replacing a declarative syntax with a procedural one as far as I understand which is a huge (and unwelcome) shift.

zem• 13 years ago

there's nothing about "true css" that makes it intrinsically superior to the "pseudo-languages" that have to be preprocessed to generate css. the spec merely determines the features browsers have to support, not the manner in which people have to use them.

marquis• 13 years ago

This very good intro to SASS makes it really obvious.

https://www.youtube.com/watch?v=fPAf8dN4G4w

valtron• 13 years ago

You can also write colors with the more intuitive hsl() and it'll convert them to hex notation.

(Only relevant if you need to support IE < 9, but still cool.)

iLoch3• 13 years ago

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• 13 years ago

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• 13 years ago

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.

teddyknox• 13 years ago

I kind of like it. It looks nice, and the the low info density makes reading (relatively) dense subject matter easier. With this design trend you'll probably start assuming that there is room to scroll when there's only a title on the screen.

dnm• 13 years ago

I had no idea that was even an option until I read your comment. Chrome on OS X shows the v-scroll bar for less than a second, and I missed it. After that, the only way they come back is to scroll. There was no visual indication that it was anything more than a title page with no links (aside from the github link).

crazygringo5• 13 years ago

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.

_j5l32• 13 years ago

It's not supposed to replace LESS/SASS, it's a supplement. That's why it's a postprocessor, not a preprocessor.

masklinn• 13 years ago

Considering what it does duplicates a small part of what less and sass do, why would you use it?

jrochkind12• 13 years ago

I don't get it. If you are using less or sass anyway.... why would you use myth as a post-processor, since myth doesn't do anything you couldn't do already in sass or less?

L8D• 13 years ago

When it says "giving you the benefits of tools like LESS and Sass" I think they are referring to how you can postprocess the CSS generate by LESS and Sass

crazygringo5• 13 years ago

Hmm... I can't quite see how the sentence could be parsed that way.

But even if that is the case, it doesn't make any sense to me, and I can't begin to understand how they could be compatible with each other. How are you going to write "var(...)" or "color(...)" declarations within LESS, that LESS will ignore, just to "pass through" to Myth? And why would you? As far as I can tell, Myth doesn't do anything that LESS doesn't already do, so I don't see why anyone would add Myth on top of LESS.

ianstormtaylor11• 13 years ago

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.

loupeabody• 13 years ago

Is there a grunt module for Myth? Thanks very much for this, I'm looking forward to using it.

crazygringo5• 13 years ago

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.

philipwalton• 13 years ago

I agree 100% with Ian. I came here to say the exact thing, but he beat me to it.

robertnealan• 13 years ago

When nesting is used incorrectly it's absolutely an anti-pattern (my first LESS project regrettably mimicked the HTML structure with nesting), but when everything is kept as semantic/modular as possible and nesting is avoided except where obvious (a UL class that styles the children LI/A tags, etc) it can be a great help in keeping your CSS simple and understandable.

While it's more difficult to replicate the same issues in native CSS due to the friction involved of copying/pasting the same elements/classes over and over, I don't think that should be a reason to entirely avoid a tool that can be a great benefit in the long run.

On the other hand, per our email I have to say I'm more and more skeptical of the benefit and long-term maintainability of SCSS @extends and @mixin except in special circumstances.

stormbrew• 13 years ago

I feel like a lot of the fear of nesting came about in the era when you couldn't do direct-child selection reliably. I'm pretty sure this is something that was overcome a long time ago now, though. It's a lot easier to limit and control the application possibilities with:

    .blah > .blorp

than it is with

    .blah .blorp

without resorting to .blah-blorp prefixing.

alanh3• 13 years ago

just because we don't want the extra weight of a new syntax

Sass defaults to .scss syntax, which is exactly CSS syntax. Okay, exactly a superset. Since it merely adds $variables and other features, you are free to ignore them and just write “pure CSS” but with variables.

What am I missing?

Flenser• 13 years ago

If/when you do add extensions will it be easy to add sourcemap support as well?

andreypopp2• 13 years ago

You can have mixins with rework-macro[1] so it would be very easy to integrate it with myth if needed (myth is based on rework).

[1] https://github.com/andreypopp/rework-macro

worldsayshi• 13 years ago

I first read it as - allowing you to use tools such as less/sass in 'conjunction'. I see now that was not really stated like that. But that seems the case anyway. It's compatible with a pipeline using both legacy css and less/sass.

simonrobb• 13 years ago

I like the idea of retaining preprocessors for nesting and mixins to write good CSS quickly, but also having the postprocessor at the other end to add polyfills where necessary.

This way, I can write SASS to target modern browsers and not worry about backward compatibility so much, because I know the postprocessor is there to catch the older browsers. e.g.: I don't want to worry about specifying a solid block colour for CSS gradients, I just want to specify a gradient.

But yes, I agree the implication that this could replace preprocessors is unrealistic.

oe• 13 years ago

The most important feature of Sass is saving your fingers by not having to write those curly braces and semicolons. Everything else is a nice bonus.

eknkc• 13 years ago

It's basically a 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.

ozh• 13 years ago

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

kumarski• 13 years ago

A little tough to read the text.looks cool.

Kiro• 13 years ago

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

mscottmcbee• 13 years ago

It looks like a disaster on FF as well. I don't understand why designers have been on a binge of typefaces that look like unreadable garbage.

dangrossman5• 13 years ago

They're running Macs or Linux and never see the garbage when they're designing their sites. The poor rendering only occurs when you use GDI to render the text which is only used by Chrome on Windows (and Firefox in Windows XP, but not Vista/7/8).

dangrossman5• 13 years ago

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.

sergiotapia2• 13 years ago

Link to the bug?

meritt• 13 years ago

Is there a workaround I (the user) can employ to make Windows+Chrome work right? I've long since given up on sites to figure out a workaround but would really love to have readable sites.

ultimatedelman• 13 years ago

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

pc86• 13 years ago

Tiny text is unreadable on Windows Chrome.

oneeyedpigeon2• 13 years ago

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

ianstormtaylor11• 13 years ago

Why yes, yes it should :) fixing now.

nawitus2• 13 years ago

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).

andreypopp2• 13 years ago

Myth uses autoprefixer[1] so you can use it directly if you don't need other features. It "just works".

[1] https://github.com/ai/autoprefixer

peferron• 13 years ago

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

nawitus2• 13 years ago

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.

coderzach• 13 years ago

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.

Pxtl• 13 years ago

"Myth - CSS the way it was imagined "

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

badman_ting• 13 years ago

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.

jackmoore• 13 years ago

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.

alanh3• 13 years ago

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

abvdasker• 13 years ago

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.

transfire• 13 years ago

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!

jsmeaton2• 13 years ago

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

jrochkind12• 13 years ago

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.

ianstormtaylor11• 13 years ago

That's a case of assuming the worst without knowing the decisions that went into the spec. The idea of using a simple `$` syntax for variables came up and was discussed but was eventually rejected. If I recall right it was rejected because they thought they might want to use it for a separate feature in the future. And they thought the function syntax better fit in with the rest of CSS (which uses functions a lot) anyways.

I know I used to think the var syntax was incredibly ugly, but I have to say after using it for a while now, you actually get used to it.

But read through the CSSWG mailing lists and you'll gain a lot more respect back for the decisions they make.

bct• 13 years ago

Just adopt the best of those

You say that like everyone agrees on what "the best" is.

fiatjaf• 13 years ago

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

JimDabell• 13 years ago

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• 13 years ago

Aha, yes. This is pretty damning.

habosa2• 13 years ago

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

jongleberry• 13 years ago

this module doesn't need help. if you want to help, you should contribute to the plugins that it depends on: https://github.com/visionmedia/rework/wiki/Plugins-and-Utili...

ianstormtaylor11• 13 years ago

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 :)

habosa2• 13 years ago

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.

philliphaydon• 13 years ago

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• 13 years ago

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

djokkataja• 13 years ago

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.

pvnick• 13 years ago

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

EasierLikeThis2• 13 years ago

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.

__--__• 13 years ago

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. :)

dinkumthinkum2• 13 years ago

I don't think it's that really. It is hipster to snark and dislike things and hipster is in apparently. That being said, some things should be disliked, this not being one of them.

_pmf_• 13 years ago

Hacker News seems to be a den of vipers, waiting to strike at the tiniest opportunity to nitpick.

When presented with a sensible, practical and actually innovative idea, I've found the responses to be fairly favorable. With small things that have been done over and over again (worse or better), I think you can expect some comparisons and questions.

heretoo• 13 years ago

https://news.ycombinator.com/item?id=6926247

For people who didn't grow up [with it].

dinkumthinkum2• 13 years ago

I know it's really not good. I actually find this project interesting. I think the fundamental idea has a lot of merit, the individual details can be worked on.

davedx• 13 years ago

Yeah, I find it very disappointing, and it's not just on Show HN threads either. The community here is still pretty intelligent, but I feel like it's become almost unbearably negative in the past year or so. I know people always say things like that about communities, but I really feel it on HN. Not so on Reddit, where people can still be positive and happy (small and large subreddits).

There is a place for criticism, even non-constructive. But HN sometimes is an echo chamber of only criticism and negativity.

hderms• 13 years ago

Why do programmers, in particular, seem to lose respect for others so quickly? Is it that ours is such a technical field that people often value 'straight-talking' at the expense of politeness (see: Linus)? Is it that software is so difficult to do properly that almost everyone becomes embittered on some level? It's such a weird phenomena when you have things like open source which are fundamentally positive, cooperative forces in spirit. The same class of people who want to give their work away for free are the same people who bitterly attack others for doing that very thing.

EasierLikeThis2• 13 years ago

We're only hurting ourselves and our community. I'm really disappointed that this is the case.

Maybe it's time for a sociological analysis of our tech population.

crystaln• 13 years ago

"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.

Show HN: Myth – CSS the way it was imagined

Related Stories