Hacker Newsnew | past | comments | ask | show | jobs | submit | mopires's commentslogin

About that... I think I got ahead of myself and forgot about this detail. I'm working on this. And will comment on this post when it's public.


Thank you for you appreciation! I'm very proud of this project. Thank you for the upvote.


Thank you sir. Closing tags are a very good feedback about the domains of a tag.


Also, if we remove closing markup, the only way to understand if a markup is closed woud be by checking if a new markup is open. That doesn`t seem efficient.


I guess pug's whitespace sensitivity permits a way to quickly tell if a tag is closed.

I'm a fan of higher expressiveness/minimalism, so perhaps I'm just biased in my preference, but I also appreciate how it removes the need to know/care about the inconsistent closing tag semantics of html.


Shorthand definitions would be a good feature to be added, but it needs refinement. We need to think carefully about how to implement in a way that would fit gracefully with the syntax and with the developer experience.


That`s correct. It`s not sensitive to anything. Just open and close tags. It is less noisy that way. Removing the bracktes, not replacing it by something else.


I have answered this in a previous comment. I'll past here for your convinience.

It's a snippet for the post I'll make about this very point.

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


It was flagged


It's not identation based. Removing the closing tags would just not close anything. Everything would be immediately nested hehe


Right... It's not identation based. Why remove the close tags?


That is a very interesting argument and very well presented. It gave me something to think about. Although, have in mind that this is a markup language. It's not a script language where you will make complex logic. It's intended to make visual elements. I do not intend to add logic implementation to it, like a template engine(ifs, loops,...). The incoming features are for visual elements implementations, like built in clip paths configuration.

I see now that the way I present it is vague. In future post I'll improve the presentation of it.

Thank you for you attetion to detail and for the argument. As humans we are prone to error. With that in mind I think this can be a valuable addition to the markups.

Thank you!


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: