3 ms·

I'm not a big proponent of all of these new HTML replacers. They don't really buy you anything--this one just gets rid of angle brackets as far as I can see, an

by apgwoz 17y ago

I'm not a big proponent of all of these new HTML replacers. They don't really buy you anything--this one just gets rid of angle brackets as far as I can see, and adds CSS style #id and .classname. Now, instead of angle brackets, we have to use tabs, or spaces, or some other delimiter (I saw | in there for continuing a line). The best way I've found of representing XML/XHTML or even HTML for that matter, is with X-Expressions--a subset of S-Expressions. But, they are most useful in a language that fully supports S-Expressions, like Lisp, since you can then use standard functions to generate your markup for you.

davidw 17y ago
Yes, I think that for HTML, "better tools" is the right answer. HTML is something that can be shared between people with various backgrounds, skills, and toolsets. I can write it in Emacs on Ubuntu, and send it to some guy who will work on it in Windows with Notepad, who can send it to someone else who will open it with Chrome on a Mac. These things might be ok for small, tight teams, but I don't see them as buying that much in the long term, as opposed to tools that let you be more productive with HTML.
- mtomczak 17y ago
  I believe that I see your point, and I would agree that the verbosity of HTML leads to sharability, and that is a strength. But the verbosity is also one of its weaknesses for large projects; it adds a great deal of overhead in terms of keeping track of the tags, especially if the HTML needs to be re-arranged. And with no language-supplied rules for how much whitespace to use or where (beyond "all adjacent whitespace is compressed"), there is too much flexibility for a large team to work smoothly. My usage case doesn't mesh with your example, because I'm working in an environment with version control and multiple developers. The guy using Notepad will be told to get a tab-aware text editor, because his changes will mangle the whitespace in the file and lead to unnecessary noise when he commits. When structure in your whitespace is already desired (to avoid making your version control noisy), you can leverage the fact that you are structuring the whitespace to make it a semantic element. This greatly decreases typing, makes the code easier to eye-scan, and allows details such as proper closing bracing to be left to the compilation tool and not to the developer. I agree with commenters who have noted that HAML has been proven useful for some developers. I would categorize both SHPAML and HAML as tools that let you be more productive with HTML.
  - davidw 17y ago
    It's not the verbosity or lack of it that makes it shareable, it's the fact that it's a standard. Some of these inventions are a bit nicer than the original thing, but not so much that I'd give up being able to share the code with pretty much anyone and everyone. I can do HTML pretty quickly with Emacs' psgml mode, and I'm sure there are other people who specialize in it who can do it even faster with other tools. I think that's the place to look for improvements, rather than generating it like machine code.
    - showell 17y ago
      When you run SHPAML through the preprocessor, it produces HTML that you can share with other people. So it's not that big an issue. Your greater point is well taken, though--using SHPAML is particularly suited to small teams.
      - silentbicycle 17y ago
        Things can get messy if people sending you patches for something generated, rather than patches for the original source, though. Most such transformations aren't trivially reversible.
        showell 17y ago
        I understand the use case, and if people are frequently sending you patches for your HTML, you probably want to make HTML the authoritative source. Do people frequently send you patches for HTML that you author? SHPAML does not allow you to trivially reverse HTML patches, but it does allow you to manually apply them without too much pain, as it lets most HTML pass through unmolested. I actually source control my HTML output to be able to see diffs on the HTML, for what it's worth.
showell 17y ago
SHPAML replaces angle brackets and close tags with space-based indentation and pipes. The CSS sugar for #id and .classname is completely optional, and obviously if you know CSS, then the syntax should be familiar. I agree that there are plenty of other useful ways to represent XML/HTML. SHPAML does require or even support tabs. The "|" is not for line continuation; it is to separate markup from content.

by apgwoz 17y ago

davidw 17y ago

Yes, I think that for HTML, "better tools" is the right answer. HTML is something that can be shared between people with various backgrounds, skills, and toolsets. I can write it in Emacs on Ubuntu, and send it to some guy who will work on it in Windows with Notepad, who can send it to someone else who will open it with Chrome on a Mac. These things might be ok for small, tight teams, but I don't see them as buying that much in the long term, as opposed to tools that let you be more productive with HTML.

mtomczak 17y ago
I believe that I see your point, and I would agree that the verbosity of HTML leads to sharability, and that is a strength. But the verbosity is also one of its weaknesses for large projects; it adds a great deal of overhead in terms of keeping track of the tags, especially if the HTML needs to be re-arranged. And with no language-supplied rules for how much whitespace to use or where (beyond "all adjacent whitespace is compressed"), there is too much flexibility for a large team to work smoothly. My usage case doesn't mesh with your example, because I'm working in an environment with version control and multiple developers. The guy using Notepad will be told to get a tab-aware text editor, because his changes will mangle the whitespace in the file and lead to unnecessary noise when he commits. When structure in your whitespace is already desired (to avoid making your version control noisy), you can leverage the fact that you are structuring the whitespace to make it a semantic element. This greatly decreases typing, makes the code easier to eye-scan, and allows details such as proper closing bracing to be left to the compilation tool and not to the developer. I agree with commenters who have noted that HAML has been proven useful for some developers. I would categorize both SHPAML and HAML as tools that let you be more productive with HTML.
- davidw 17y ago
  It's not the verbosity or lack of it that makes it shareable, it's the fact that it's a standard. Some of these inventions are a bit nicer than the original thing, but not so much that I'd give up being able to share the code with pretty much anyone and everyone. I can do HTML pretty quickly with Emacs' psgml mode, and I'm sure there are other people who specialize in it who can do it even faster with other tools. I think that's the place to look for improvements, rather than generating it like machine code.
  - showell 17y ago
    When you run SHPAML through the preprocessor, it produces HTML that you can share with other people. So it's not that big an issue. Your greater point is well taken, though--using SHPAML is particularly suited to small teams.
    - silentbicycle 17y ago
      Things can get messy if people sending you patches for something generated, rather than patches for the original source, though. Most such transformations aren't trivially reversible.
      - showell 17y ago
        I understand the use case, and if people are frequently sending you patches for your HTML, you probably want to make HTML the authoritative source. Do people frequently send you patches for HTML that you author? SHPAML does not allow you to trivially reverse HTML patches, but it does allow you to manually apply them without too much pain, as it lets most HTML pass through unmolested. I actually source control my HTML output to be able to see diffs on the HTML, for what it's worth.

showell 17y ago

SHPAML replaces angle brackets and close tags with space-based indentation and pipes. The CSS sugar for #id and .classname is completely optional, and obviously if you know CSS, then the syntax should be familiar. I agree that there are plenty of other useful ways to represent XML/HTML. SHPAML does require or even support tabs. The "|" is not for line continuation; it is to separate markup from content.