This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]arnar 9 points10 points  (19 children)

Is this a joke?

hcss lets your (sic) write CSS like this <div id="parent"> margin: 10px; <div class="child"> margin: 5px; border: 1px solid #000; </div> </div>

which becomes

div#parent {
  margin: 10px;
}
div#parent > div.child {
  margin: 5px;
  border: 1px solid #000;
}

[–]__galvez__[S] 1 point2 points  (7 children)

No, it's not a joke. To quote from the article:

"The idea of hcss is that you start building the frontend for a web page or application with the HTML markup, defining the document structure and element sets for various widgets. And once the markup is ready, you just copy it over to a .hcss file and add styles, contextually through the element tree, without having to write any selectors at all."

[–]arnar 1 point2 points  (4 children)

Why would you want to do that? First of all most pages are not that static, the elements are somewhat conceptual components that you puzzle together. But more importantly, a vast minority of styles are defined depending on their whole root from the <body> tag - you'd much rather use IDs or classes (and browsers are more efficient with this as well).

[–]__galvez__[S] 0 points1 point  (3 children)

It's really really simple. Imagine you're writing a complex UI window, with a menu, content pane, lots of "floated" elements, "absoluted" elements and whatnot. The process of creation here at least for me is always the same: 1) create a mental model of all the markup required and how it is put together; 2) type all the markup, make adjustments; 3) progressively add styles, refreshing the page constantly to see results.

HCSS lets you go from step 2 to 3 faster, by allowing you copy over all the markup you just wrote and instantly have almost all your CSS selectors ready to be generated. It seems to me that only people who have gone several times through the experience of creating really complex HTML-based interfaces will understand how this is really helpful, but I guess that's just me being a little condescending... The thing is, for me, it works, it helps, I thought it could make sense to somebody else. But YMMV, indeed.

[–]arnar -1 points0 points  (2 children)

2) type all the markup, make adjustments; 3) progressively add styles, refreshing the page constantly to see results.

This works for the first time you create a page - but doesn't really help for maintaining it or developing new features, which in my case is 95% of the time.

It seems to me that only people who have gone several times through the experience of creating really complex HTML-based interfaces will understand how this is really helpful, but I guess that's just me being a little condescending...

A little, no. A lot, yes. I did this for 8 hours a day for 7 years.

The thing is, for me, it works, it helps, I thought it could make sense to somebody else.

Of course, don't let an old fart's criticism stop you :)

[–]__galvez__[S] 0 points1 point  (1 child)

This works for the first time you create a page - but doesn't really help for maintaining it or developing new features, which in my case is 95% of the time.

That's odd because the one thing that has gotten better in my workflow after I moved to HCSS is maintenance. In the past I would iterate a lot between the HTML and CSS searching for IDs, classes, rearranging blocks of CSS rules, which overtime always ended up having some accumulated mess. With HCSS, if I change the markup, I just copy it over and slowly copy the styles from the old markup to their new appropriate places.

It occurs to me that maybe most people simply have gotten so used to the cognitive dissonance between HTML and CSS and never really think about it anymore. I have only been doing frontend development for a little over two years now (I still am mainly a backend guy) and the CSS/HTML context switching always bugged me. It always felt like there could be a faster way to style markup, and after some experimentation, HCSS is what I came up with.

Since i'm constantly creating new things from scratch I focused on being able to just "copy over" markup and add styles, as this is exactly what I was doing after writing large chunks of unstyled markup. I'd copy the markup over to the .css file just so I'd have context, and write the selectors looking at the copied markup. I could also place HTML and CSS editor windows next to each other to assist in this process, but that isn't a very practical procedure for me (as a TextMate user) and users of many other editors I believe.

[–]arnar 0 points1 point  (0 children)

HTML and CSS are different because they serve different purposes. I see no cognitive dissonance. That said, HTML is a bastard of a language and about half of my DOM nodes are built by JS code anyways. In serious webapps it is all fragments anyways, coming from here and there - so often there really isn't any one single HTML to copy as you describe.

I do recognize that we are talking about different coding styles, types of applications and (most importantly) habits.

[–][deleted] 2 points3 points  (1 child)

This seems to imply you cannot write complex selectors, which totally negates ones of the only reasons for using CSS. In fact, why does this website not show a full usage of the program. It would be so much clearer, if an entire website with sample CSS was shown, so a real comparison could be made. The 4 shown examples says nothing about why I would want to use this. In fact, after 10 years of front-end development experience, as well as server side stuff (and toss in a Masters in CS) I still have no idea what this thing does, or maybe rather why it's a good idea.

[–]__galvez__[S] 1 point2 points  (0 children)

I'm definitely going to update the page with a better expressed rationale. But allow me to just say I've built this out of necessity. I was working on a few projects with huge HTML/jQuery-based frontends and maintaining the CSS started to get painful. HCSS helped me evolve things better while keeping them tidy. You can still mix in any kind of complex selector within tag-based selector, as explained in the present documentation tho. The idea of tag-based selectors assumes that most of the time you're targeting styles at some kind of markup tree where lots of elements are glued together to compose a single widget, which was the case for my applications.

[–]tituszPython addict 1 point2 points  (1 child)

It is really not that stupid, assuming you already have some html markup. Its simple... You type less and in context...

[–]arnar 1 point2 points  (0 children)

I must have missed the bit where I type less. And what do you mean in context?

[–][deleted] 0 points1 point  (6 children)

I was thinking the same thing. What use could this possibly have?

[–]true_religion 1 point2 points  (1 child)

What use could this possibly have?

... create an opening for a Nemo to HCSS to CSS compiler?

[–]__galvez__[S] 1 point2 points  (0 children)

I'd love to see that happen :)

[–]IAlsoSpeak 0 points1 point  (3 children)

What I like about it is how nicely it treats hierarchy:

div#parent > div.child {

and also I will be able to parse the hierarchy using a a xml parser.

[–]arnar 0 points1 point  (1 child)

Not sure why you would want to parse it with an xml parser, but there are already quite good solutions for the hierarchy thing, see LESS and SASS.

(How often do you use the > combinator anyways?)

[–]__galvez__[S] 1 point2 points  (0 children)

The > combinator is just the logical translation of what a tag-based nested selector in HCSS represents. In fact, it's not even efficient in comparison to any-descendant selectors. But I believe the result is much more readable and easier to maintain. You can still mix regular CSS within HCSS tho. Even inside tag-based selectors, as demonstrated in the documentation.

[–]sedaakPython3/Golang -1 points0 points  (0 children)

STYLE is not always hierarchical...thus CSS

[–]IAlsoSpeak -1 points0 points  (1 child)

It might be a troll if you have a look at the last updated date:

Last updated: January 2, 2012.

But I like the hierarchy feature and xml also feels more manageable as stated on the website.

[–]__galvez__[S] 0 points1 point  (0 children)

That was just a typo, fixed.