Possible Html Replacement

Discussing this topic over at PossibleXmlReplacement too, since HTML and XML are similar syntax.

Or maybe they aren't. One of the arguments of YAML is that data encoding (with metadata) and text markup are two entirely different things. They say "YamlAintMarkupLanguage," because YAML drops the "text markup" features, in order to simplify data markup.

See AlternativesToXml -- particularly the lists in the URLs referenced at the end, for alternatives to XML for text markup.

In particular, considering the http://www.pault.com/pault/pxml/xmlalternatives.html list, scroll down to "Grutatxt" or "txt2tags" -- both Wiki-like text markup languages. Or "AsciiDoc?" -- same, with nroff/troff "dot" line commands. And there are plenty of others on just that list.

Good Point. I'd still like to solve the problems with HTML, so there would be easy porting. (All our current HTML hanging around on servers, hard drives.) ..As the markup language it is, in it's current state, I need to convert html over to something easier to manage and read. I agree that there is a problem that XML is too markup-like for representing Data. However, when we are in need of reading and managing all the millions of already written HTML out there, one of the main problems is still purely the < and > symbols (and whitespace, tabs, indenting). Just different syntax (read: easy porting) might solve some of the main readability problems of html.

HTML Readability...

Possibility 1:

  [IMG
    SRC="http://c2.com"
    BORDER="0" WIDTH="1" HEIGHT="1" NOSAVE ]

  [A
    HREF="http://c2.com" 
    TARGET="_top"]
    [IMG 
      SRC="hxxp://c2.com/img.png" 
      BORDER="0" ALIGN="center" ALT="Go Wiki"]
    [BR]Link to Wiki Main
  [/A]

 [P]
  Some Text..
 [BR]
  More Content..

Possibility 2:

  [IMG
    SRC:=http://c2.com ;
    BORDER:=0; WIDTH:=1; HEIGHT:=1; NOSAVE; ]

  [A
    HREF:=http://c2.com ; 
    TARGET:=_top; ]
    [IMG 
      SRC:=hxxp://c2.com/img.png ; 
      BORDER:=0; ALIGN:=center; ALT:=Go Wiki;]
    [BR]Link to Wiki Main
  [/A]

 [P]
  Some Text..
 [BR]
  More Content..

Possibility 3:

  [A HREF=>http://c2.com TARGET=_top ] [IMG SRC=>hxxp://c2.com/img.png BORDER=0 ALIGN=center ALT=go wiki;]    
   [BR]link to wiki main
  [/A]

Possibility 4:

  [A HREF=http://c2.com TARGET=_top IMG=hxxp://c2.com/img.png BORDER=0 ALIGN=center ALT=go wiki]    
   Link to wiki main;
  [/A]

  [P]
   Some text... |
   Another Line is started |
   No need to verbosely type out BR |
   Just use the verticle line symbol to end a line |
   Another new line |
  [/P] 

 Or... 

  [P] 
   | A new line 
   | Another Line 
   | No need to verbosely type out BR 
   | Just use a verticle line (pipe character?)
   | Another new line
  [/P]

How about regular brackets... The reason, you might not want to consider brackets as a possible alternative...

 (P)
  Some Text..This is a page (a good page too) and you are the 14th visitor.
 (BR)
  More Content.. You like the page because we show articles (high quality ones).

...is because we do use brackets in conversation when typing on the internet. However, we rarely use square brackets as in Possibility 1. But... see below. Data types can solve that brack problem if we want to use brackets ().

How about regular brackets with data types...

  (a href: "http://c2.com" target: "_top"
    (img src: "hxxp://c2.com/img.png" border: "0" align: "center" alt: "Go Wiki")
    (br) "Link to Wiki Main")

 ("Some Text.."
  (br)
  "More Content..")

-- SmugLispWeenie

Yes, I need some Lisp people to chime in on the brackets, because my example above was rather incomplete. That's a clean solution you posted above, SmugLispWeenie. (I don't think you are smug or a weenie)

How does Possibility 1 differ from HTML, except that it uses square brackets instead of greater-than/less-than?

Exactly. But it is easier to read for me. That's part of the point of this wiki page. I'm not just discussing "some other technology". I am actually discussing issues with readability mainly, so far. --lo

The best ""replacement" for HTML would be for people to abandon this "semantic web" concept and accept that HTML is rich-text markup. If you want semantic markup, then use semantic markup - XML works fine. But don't use that as your output format, use it as a storage/interchange format and use a transform to create rich text (HTML) for display. It's essentially impossible to create non-trivial websites and layouts (and most certainly not the sort of rich, interactive sites that are popular) while still maintaining anything resembling "semantic" markup. If we get HTML back to it's roots as rich-text, we can actually have a standard on display formats, meaning that there will be less cross-browser hackery.

People can improve things. This isn't a negative page. If things weren't improved, people might still be using Linux at the command line without any window managers, or MS-DOS without windows. This page more discusses possibilities and improvements, and readbility issues.

An even better "replacement" for HTML is admit that markup -- whether semantic or presentational -- is different from content. Therefore, make the markup a companion structure, tightly bound to the content, so that the markup changes when the content changes. This allows, for example, multiple markups on the same document. It also greatly simplifies the incorporation of non-textual content into a hypermedium.

There is no problem with rich text, you are right. I am mainly discussing readability issues here. I do find the greater than and less than symbol hard on the eyes. I am not discussing whether we should use some completely different method of designing rich text document, but rather rather discussing variations of HTML or variations of text markup languages. It's similar to discussing Python to PHP to PascalScript? to Ruby to JSP really. They are languages, but they may end up doing similar things in the end. For example, even if we took all the < and > out of html and just used [ and ] instead, it would do basically the same thing. This < and > are not the only reasons though, there are other issues such as <BR> and <P> getting in the way of your thoughts, instead of using something like the pipe character. In other words, I or we may even end up creating a language out of this for readability reasons only - not to modify the intent of HTML or rich text.
P.S. One thing I do see as something non-readability related, which may modfy the intent of HTML, is a language with more speed. Html is slow. But with a language that had less markup.. (again, that's not what this page is getting at so far) --lo
Another thing I do see as something non-readability related, which may modify the intent of HTML, is that it doesn't have to be downloaded by browsers as a script. It could be compressed or in more binary format. Although we do have Gzip, so this helps a bit. --lo
And I agree with you that HTML is mainly for rich text (e-brochures). This page discussses rich text markup languages for the web, and possible alternatives or replacements. When I want to discuss issues regarding people abusing HTML I'd usually talk about it in BrowserAbuseSyndrome, HtmlSucks.