9 ms·

The fatal flaw of HTML (and XML for that matter) is that the tags have the same visual weight as the text they're delimiting, which makes for a sense of clutter

The fatal flaw of HTML (and XML for that matter) is that the tags have the same visual weight as the text they're delimiting, which makes for a sense of clutter even in your minimal example. Markdown really scores here, by having a pleasing plain text representation as a goal from the outset, and I've love to see it used more widely for web pages. I'd also love to see it more widely used for offline reading, too - the help files in an application really shouldn't need to invoke a web browser to view them when a lightweight markdown viewer would do the job. Not that there is a lightweight markdown viewer, mind you!

5560675260 4y ago
> tags have the same visual weight as the text they're delimiting IMO this issue should and can be easily solved by editor/viewer by rendering tags with lower contrast.
- robinsonb5 4y ago
  Yes, that's a perfectly viable workaround, but it's still a band-aid that requires expending resources that wouldn't need to be spent if the markup method had been better chosen for readability. (To be specific, I believe the angle-brackets are the main culprit.)
ElemenoPicuares 4y ago
Markdown is undoubtedly more readable, but HTML can be more readable than most people make it. And considering that the ultimate goal is to wind up with a layed-out, styled document, its capabilities in that regard are just plain-old more important, especially since markdown isn't going to replace WYSIWYG editors any time soon, and almost everybody who needs to know HTML can learn it relatively easily. Browsers collapse white space by default, so you've got a lot of flexibility with its formatting: <!doctype html> <title> Page Title </title> <h1> Page Title </h1> <p> Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut ac lorem ut massa euismod vestibulum. <p> Nullam rutrum blandit eleifend. Aenean a varius diam. Morbi sodales velit nunc, vel vestibulum lorem tempus sodales. --or-- <!doctype html> <title> Page Title </title> <h1> Page Title </h1> <p> Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut ac lorem ut massa euismod vestibulum. <p> Nullam rutrum blandit eleifend. Aenean a varius diam. Morbi sodales velit nunc, vel vestibulum lorem tempus sodales. I get why many developers like this idea... Web developers are responsible for implementing the complex user-facing parts, and their primary weapon is text: doing extra work sucks, and when you're a hammer, everything looks like a nail. But developers are not designers, and design not being left to developers in mature organizations is no accident. Absolute, deliberate, limiting simplicity is always an attractive argument if you dismiss the value of, or maybe don't even understand the reason for the complexity. I won't deny the advantages of reader-view-level simplicity in web design: it's easier to visually parse, more performant, and easier to navigate compared to most web pages, similar to how books compare to magazines-- but about 225 million people per year in the US read magazines and I assure you most of them would not choose to have textural printouts in lieu of their current form. While people like having the option of a uniform, grey, easily visually parseable mode to view webpages, that's probably not what they want even most of the time, let alone as a deliberate limitation.
- robinsonb5 4y ago
  I may be that rare exception - a hobbyist developer who does design work as part of $dayjob.
  - ElemenoPicuares 4y ago
    I don't think that's as rare as people say, especially in smaller organizations. Having an art school design education and a bit over a decade in (mostly back-end) web development, I've had plenty of deseloper type roles. If they fall under a design or marketing department, they'll spend 80% of the time doing design work and try to throw it together on some shitty wysiwyg monstrosity, ignoring performance, stability, maintainability, etc. If they fall under technical departments, design, ahem, decoration and polish is something to be applied at the end, if there's time, after the real work is done. Either way, having the same group of people responsible for two halves of that coin rarely yields a good balance, and they almost never pay any real attention to usability ... at least not for use cases that don't exactly mirror their own. Seems to me that replacing the flexibility of current markup and styling tools with simple markdown and reader-type layouts is just trying to apply the tech-focused solution to the entire problem the way Flash tried to do the opposite.
- nerdponx 4y ago
  The problem is that this only really works well for "documents". Most webpages are anything but "documents", even those that do mostly focus on text. Of course, HTML templating can help a lot with that: adding footers and sidebars and so on. But it's still no good for "web apps".
  - ElemenoPicuares 4y ago
    Compared to markdown I think HTML works a lot better as a general purpose format.
- account42 4y ago
  One problem with this style is that if you copy any text from this website you will have trailing spaces after each paragraph. To avoid that you have to close the tags (or open the next one) directly after the text.
kridsdale2 4y ago
IMO the main issue with writing HTML is it takes a two-armed key-chord to do a < or > char.
- iso1631 4y ago
  Not entirely sure what you mean by "two-armed key-chord". It's shift-, or shift-. -- my keyboard's bottom line goes <shift>\ZXCVBNM,./<shift>. < is right-index and right-pinky, and > is right-index and right-pinky (as shift is so much wider) Now sure, some are home row afficiandos, and having # on the home row is certainly beneficial to those as your right-index can stay on J as god intended Or do you have a different keyboard layout to me. Keyboard layouts - especially the location of things like ,./<>?@;'#:@~[]{} vary a lot depending on the country you are in.
tannhaeuser 4y ago
HTML is based on SGML, and SGML has short references to handle lightweight custom syntaxes. For example, you can define that an asterisk appearing in your content within a <p> element is replaced by <em>, and moreover define that an asterisk appearing within <em> content is replaced by </em>, toggling emphasized text tags. So SGML very much acknowledges the need for lightweight markup, but the SHORTREF feature, like everything else requiring markup declarations, didn't make it into the XML subset of SGML. HTML itself doesn't have these and other features (such as basic text macros) because SGML was understood to be available at least at authoring time.
- nerdponx 4y ago
  Why didn't we end up with SGML -> XML "compilers"? As I understand it, XML is intended to be equivalent to SGML, with less syntactic flexibility to make it easier to parse. So once you've done the hard work of parsing SGML, it seems like it should be straightforward to emit the same data as XML for further machine processing. Or are there some SGML features that cannot be represented with an equivalent in XML?
  - tannhaeuser 4y ago
    > Why didn't we end up with SGML -> XML "compilers"? We did; both the osx command-line tool of the venerable SP/OpenSP package, as well as sgmlproc (sgmljs) with output_format=xml does exactly that: output canonical XML markup with shortrefs resolved, omitted tags inferred, attribute values put in quotes and attribute names preprended where not already present, conditional marked sections included or omitted depending on parameter entities, and also entity references expanded, etc. But SGML can also output HTML proper, unlike XML. SGML mostly has additional authoring features over XML indeed, but a number of additional concepts as well: much more powerful notations (used as general extension mechanism such as for math or parametric macro expansion) and stylesheets ie. link process declarations with state-dependent assignment of attributes and pipelining to yield markup projections, transforms, and views.
    - nerdponx 4y ago
snthpy 4y ago
This is a great point.
deleted 4y ago
[deleted]
Mikhail_Edoshin 4y ago
Technically XML has some machinery to support more lightweight notations. It won't parse these notations, of course, but the information is accessible to the users of XML reader. The mechanism should work like that: <?xml version="1.0"?> <!DOCTYPE myDoc [ <!NOTATION markdown PUBLIC "https://authority.org/markdown/v1.23"> <!NOTATION rest PUBLIC "urn:restructured-text/v4.56"> <!ELEMENT myDoc (note+)> <!ELEMENT note CDATA> <!ATTLIST note notation NOTATION (markdown|rest) #REQUIRED> ]> <myDoc> <note notation="rest"> restructured text goes here </note> <note notation="markdown"> markdown goes here </note> </myDoc>

5560675260 4y ago

> tags have the same visual weight as the text they're delimiting IMO this issue should and can be easily solved by editor/viewer by rendering tags with lower contrast.

robinsonb5 4y ago
Yes, that's a perfectly viable workaround, but it's still a band-aid that requires expending resources that wouldn't need to be spent if the markup method had been better chosen for readability. (To be specific, I believe the angle-brackets are the main culprit.)

ElemenoPicuares 4y ago

Markdown is undoubtedly more readable, but HTML can be more readable than most people make it. And considering that the ultimate goal is to wind up with a layed-out, styled document, its capabilities in that regard are just plain-old more important, especially since markdown isn't going to replace WYSIWYG editors any time soon, and almost everybody who needs to know HTML can learn it relatively easily. Browsers collapse white space by default, so you've got a lot of flexibility with its formatting: <!doctype html> <title> Page Title </title> <h1> Page Title </h1> <p> Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut ac lorem ut massa euismod vestibulum. <p> Nullam rutrum blandit eleifend. Aenean a varius diam. Morbi sodales velit nunc, vel vestibulum lorem tempus sodales. --or-- <!doctype html> <title> Page Title </title> <h1> Page Title </h1> <p> Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut ac lorem ut massa euismod vestibulum. <p> Nullam rutrum blandit eleifend. Aenean a varius diam. Morbi sodales velit nunc, vel vestibulum lorem tempus sodales. I get why many developers like this idea... Web developers are responsible for implementing the complex user-facing parts, and their primary weapon is text: doing extra work sucks, and when you're a hammer, everything looks like a nail. But developers are not designers, and design not being left to developers in mature organizations is no accident. Absolute, deliberate, limiting simplicity is always an attractive argument if you dismiss the value of, or maybe don't even understand the reason for the complexity. I won't deny the advantages of reader-view-level simplicity in web design: it's easier to visually parse, more performant, and easier to navigate compared to most web pages, similar to how books compare to magazines-- but about 225 million people per year in the US read magazines and I assure you most of them would not choose to have textural printouts in lieu of their current form. While people like having the option of a uniform, grey, easily visually parseable mode to view webpages, that's probably not what they want even most of the time, let alone as a deliberate limitation.

robinsonb5 4y ago
I may be that rare exception - a hobbyist developer who does design work as part of $dayjob.
- ElemenoPicuares 4y ago
  I don't think that's as rare as people say, especially in smaller organizations. Having an art school design education and a bit over a decade in (mostly back-end) web development, I've had plenty of deseloper type roles. If they fall under a design or marketing department, they'll spend 80% of the time doing design work and try to throw it together on some shitty wysiwyg monstrosity, ignoring performance, stability, maintainability, etc. If they fall under technical departments, design, ahem, decoration and polish is something to be applied at the end, if there's time, after the real work is done. Either way, having the same group of people responsible for two halves of that coin rarely yields a good balance, and they almost never pay any real attention to usability ... at least not for use cases that don't exactly mirror their own. Seems to me that replacing the flexibility of current markup and styling tools with simple markdown and reader-type layouts is just trying to apply the tech-focused solution to the entire problem the way Flash tried to do the opposite.
nerdponx 4y ago
The problem is that this only really works well for "documents". Most webpages are anything but "documents", even those that do mostly focus on text. Of course, HTML templating can help a lot with that: adding footers and sidebars and so on. But it's still no good for "web apps".
- ElemenoPicuares 4y ago
  Compared to markdown I think HTML works a lot better as a general purpose format.
account42 4y ago
One problem with this style is that if you copy any text from this website you will have trailing spaces after each paragraph. To avoid that you have to close the tags (or open the next one) directly after the text.

kridsdale2 4y ago

IMO the main issue with writing HTML is it takes a two-armed key-chord to do a < or > char.

iso1631 4y ago
Not entirely sure what you mean by "two-armed key-chord". It's shift-, or shift-. -- my keyboard's bottom line goes <shift>\ZXCVBNM,./<shift>. < is right-index and right-pinky, and > is right-index and right-pinky (as shift is so much wider) Now sure, some are home row afficiandos, and having # on the home row is certainly beneficial to those as your right-index can stay on J as god intended Or do you have a different keyboard layout to me. Keyboard layouts - especially the location of things like ,./<>?@;'#:@~[]{} vary a lot depending on the country you are in.

tannhaeuser 4y ago

HTML is based on SGML, and SGML has short references to handle lightweight custom syntaxes. For example, you can define that an asterisk appearing in your content within a <p> element is replaced by <em>, and moreover define that an asterisk appearing within <em> content is replaced by </em>, toggling emphasized text tags. So SGML very much acknowledges the need for lightweight markup, but the SHORTREF feature, like everything else requiring markup declarations, didn't make it into the XML subset of SGML. HTML itself doesn't have these and other features (such as basic text macros) because SGML was understood to be available at least at authoring time.

nerdponx 4y ago
Why didn't we end up with SGML -> XML "compilers"? As I understand it, XML is intended to be equivalent to SGML, with less syntactic flexibility to make it easier to parse. So once you've done the hard work of parsing SGML, it seems like it should be straightforward to emit the same data as XML for further machine processing. Or are there some SGML features that cannot be represented with an equivalent in XML?
- tannhaeuser 4y ago
  > Why didn't we end up with SGML -> XML "compilers"? We did; both the osx command-line tool of the venerable SP/OpenSP package, as well as sgmlproc (sgmljs) with output_format=xml does exactly that: output canonical XML markup with shortrefs resolved, omitted tags inferred, attribute values put in quotes and attribute names preprended where not already present, conditional marked sections included or omitted depending on parameter entities, and also entity references expanded, etc. But SGML can also output HTML proper, unlike XML. SGML mostly has additional authoring features over XML indeed, but a number of additional concepts as well: much more powerful notations (used as general extension mechanism such as for math or parametric macro expansion) and stylesheets ie. link process declarations with state-dependent assignment of attributes and pipelining to yield markup projections, transforms, and views.
  - nerdponx 4y ago

snthpy 4y ago

This is a great point.

deleted 4y ago

[deleted]

Mikhail_Edoshin 4y ago

Technically XML has some machinery to support more lightweight notations. It won't parse these notations, of course, but the information is accessible to the users of XML reader. The mechanism should work like that: <?xml version="1.0"?> <!DOCTYPE myDoc [ <!NOTATION markdown PUBLIC "https://authority.org/markdown/v1.23"> <!NOTATION rest PUBLIC "urn:restructured-text/v4.56"> <!ELEMENT myDoc (note+)> <!ELEMENT note CDATA> <!ATTLIST note notation NOTATION (markdown|rest) #REQUIRED> ]> <myDoc> <note notation="rest"> restructured text goes here </note> <note notation="markdown"> markdown goes here </note> </myDoc>