News for hackers. Stuff that matters.
Re:The thing I hate about HTML (2010) by ericfontaine on Tuesday March 10, 2015 @10:40PM (#9182224)
how about just use whitespace, like python:

  div class="red"
    p
      Hello, World!
(of course I know would not look nice if had to place <b>tags</b> inside of single line of text, and might get a little too indenty)
Re:The thing I hate about HTML (2010) by TheAceOfHearts on Tuesday March 10, 2015 @10:48PM (#9182259)
This is basically jade[0]. Although jade isn't quite as smart, so the expression you wrote would be considered invalid.

[0] jade-lang.com

Re:The thing I hate about HTML (2010) by ericfontaine on Tuesday March 10, 2015 @11:30PM (#9182426)
interesting. Very clean looking.
Re:The thing I hate about HTML (2010) by jaredmcateer on Friday March 13, 2015 @08:50PM (#9201072)
You absolutely have to split jade documents and use includes/blocks though, any decent sized page, even if it's static becomes unmanageable very quickly.
Re:The thing I hate about HTML (2010) by icantthinkofone on Tuesday March 10, 2015 @10:42PM (#9182235)
Because whitespace matters in HTML.
Re:The thing I hate about HTML (2010) by ericfontaine on Tuesday March 10, 2015 @11:28PM (#9182417)
good point, but could you elaborate?
Re:The thing I hate about HTML (2010) by icantthinkofone on Wednesday March 11, 2015 @09:54AM (#9184054)
One quick example.

Certain elements are, or can be made to be, "inline" which gets them treated the same as characters on a line. Thus those elements, such as an image, will have white space between them as a word does in a paragraph. If you butt those element's tags right next to each other, with no white space between them, then there will be no white space on the displayed page.

Re:The thing I hate about HTML (2010) by ufo on Tuesday March 10, 2015 @11:01PM (#9182309)
This is good for hand-written html but annoying for machine-written html.
Re:The thing I hate about HTML (2010) by ericfontaine on Tuesday March 10, 2015 @11:34PM (#9182440)
machine would just have to count '/t' tabs at beginning of each line to parse. Is that any slower than scanning every character for '<'?