4 ms·

> Good information design, clear visual hierarchy, accessibility, etc. all help with communication Isn't that what HTML gives us?

by ghusto 4y ago

martin_a 4y ago
Somewhat subtle, but: Yes and No. I'd say HTML for itself just gives us a way to give meaning or imply how something should be styled "headline of first order". In the end it's a markup language, not some magic styling tool. How it is actually styled (in absence of CSS) is in the hands of the default rendering of your browser. That might very well be a very bad rendering, due to lack of knowledge/time/engagement of the people building/maintaining that renderer. Also those renderes might come from a time and system where technical limitations where different, markup was different, lots of things were very different. So I don't think we should expect HTML alone to "look nice" or work well in regards of readability.
- berkes 4y ago
  > I'm quite certain that a large part of the web would need no CSS or just a few lines of it, if the basic (browser applied styles) were good. As in: designed I think we would win a lot if browsers default styles were beautiful (as in: really good, not merely fancy) designed. Many websites then would need just a few lines to set some colors, style that weird-custom thing they do or make it feel just a bit more personal.
  - kerkeslager 4y ago
    I think the bigger thing would be to have more semantic HTML. <dropdown>, <tab-area><tab>Content</tab></tab-area>, <carousel><slide>Content</slide></carousel>, <rich-text-editor>, etc. Instead we've got a million immature implementations of these that are slower because they are written in JS instead of native code, slowly break over time as they aren't maintained, and typically have terrible accessibility.
kerkeslager 4y ago
Well, that was what HTML was on track to give us. But once JS and CSS were introduced, semantic HTML that was actually semantic stopped developing, under the assumption that if someone needed, for example, a tab area or slide show, they could develop those themselves with CSS/JS. What we've gotten instead is extremely vague elements like "section" that don't communicate what the elements are. If HTML were truly semantic, browsers could implement accessibility features around it, but because they're so vague, there's no real way for browsers to do that, which offloads the responsibility onto web developers, who in most cases aren't granted budget to do it. There are a handful of features such as alt properties, but these are pretty limited. So yeah, HTML should give us that, but that's part of what users gave up when we decided it was acceptable to allow random websites to run code on our machines and tell us how our content should be displayed.
- singpolyma3 4y ago
  I agree with you, but also I think the section tag is one of the biggest leaps forward we've had. Putting an id on a whole section instead of a name= crap for references, and actually using nesting for hierarchy. All the HTML5 input types are also an example of semantics impriving. It could be way better, but it's not a total stalemate
  - kerkeslager 4y ago
    > I agree with you, but also I think the section tag is one of the biggest leaps forward we've had. Putting an id on a whole section instead of a name= crap for references, and actually using nesting for hierarchy. How does this differ from how <div> was being used before? I've switched to using <section> simply because it's a better name, but I'm not sure it's made any meaningful difference in my code. Another example of the pointlessness of this issue is <em> and <strong>. I've rarely seen code where these weren't used exactly the same as <i> and <b> were before. In rare cases, I've seen someone do something like make <em> a different color rather than italic, and that's almost always been a bad idea, because when HTML authors use <em> they almost always intend for it to be italic. In fact, I'd say we should just continue using <i> and <b> because those communicate intent better, but at this point I've worked in too many codebases that decided that <i> could be hacked to mean "icon" (i.e. using FontAwesome) which is a horrible, awful, no-good, bad, hack. > All the HTML5 input types are also an example of semantics impriving. It could be way better, but it's not a total stalemate That's true, but I think we'd be moving forward a lot more quickly if we weren't devoting most of standards development resources toward giving companies more fine-grained control of our browsers through CSS/JS.
Vrondi 4y ago
Yes. HTML gives the structure and hierarchy (if done properly) which is also what then gives the accessibility. CSS can do lovely things that will help a blind user with a screenreader not one bit unless you're kludging in "hacks" to give them extra hints for specialized use.

> Good information design, clear visual hierarchy, accessibility, etc. all help with communication Isn't that what HTML gives us?

by ghusto 4y ago

> Good information design, clear visual hierarchy, accessibility, etc. all help with communication Isn't that what HTML gives us?

martin_a 4y ago

Somewhat subtle, but: Yes and No. I'd say HTML for itself just gives us a way to give meaning or imply how something should be styled "headline of first order". In the end it's a markup language, not some magic styling tool. How it is actually styled (in absence of CSS) is in the hands of the default rendering of your browser. That might very well be a very bad rendering, due to lack of knowledge/time/engagement of the people building/maintaining that renderer. Also those renderes might come from a time and system where technical limitations where different, markup was different, lots of things were very different. So I don't think we should expect HTML alone to "look nice" or work well in regards of readability.

berkes 4y ago
> I'm quite certain that a large part of the web would need no CSS or just a few lines of it, if the basic (browser applied styles) were good. As in: designed I think we would win a lot if browsers default styles were beautiful (as in: really good, not merely fancy) designed. Many websites then would need just a few lines to set some colors, style that weird-custom thing they do or make it feel just a bit more personal.
- kerkeslager 4y ago
  I think the bigger thing would be to have more semantic HTML. <dropdown>, <tab-area><tab>Content</tab></tab-area>, <carousel><slide>Content</slide></carousel>, <rich-text-editor>, etc. Instead we've got a million immature implementations of these that are slower because they are written in JS instead of native code, slowly break over time as they aren't maintained, and typically have terrible accessibility.

kerkeslager 4y ago

Well, that was what HTML was on track to give us. But once JS and CSS were introduced, semantic HTML that was actually semantic stopped developing, under the assumption that if someone needed, for example, a tab area or slide show, they could develop those themselves with CSS/JS. What we've gotten instead is extremely vague elements like "section" that don't communicate what the elements are. If HTML were truly semantic, browsers could implement accessibility features around it, but because they're so vague, there's no real way for browsers to do that, which offloads the responsibility onto web developers, who in most cases aren't granted budget to do it. There are a handful of features such as alt properties, but these are pretty limited. So yeah, HTML should give us that, but that's part of what users gave up when we decided it was acceptable to allow random websites to run code on our machines and tell us how our content should be displayed.

singpolyma3 4y ago
I agree with you, but also I think the section tag is one of the biggest leaps forward we've had. Putting an id on a whole section instead of a name= crap for references, and actually using nesting for hierarchy. All the HTML5 input types are also an example of semantics impriving. It could be way better, but it's not a total stalemate
- kerkeslager 4y ago
  > I agree with you, but also I think the section tag is one of the biggest leaps forward we've had. Putting an id on a whole section instead of a name= crap for references, and actually using nesting for hierarchy. How does this differ from how <div> was being used before? I've switched to using <section> simply because it's a better name, but I'm not sure it's made any meaningful difference in my code. Another example of the pointlessness of this issue is <em> and <strong>. I've rarely seen code where these weren't used exactly the same as <i> and <b> were before. In rare cases, I've seen someone do something like make <em> a different color rather than italic, and that's almost always been a bad idea, because when HTML authors use <em> they almost always intend for it to be italic. In fact, I'd say we should just continue using <i> and <b> because those communicate intent better, but at this point I've worked in too many codebases that decided that <i> could be hacked to mean "icon" (i.e. using FontAwesome) which is a horrible, awful, no-good, bad, hack. > All the HTML5 input types are also an example of semantics impriving. It could be way better, but it's not a total stalemate That's true, but I think we'd be moving forward a lot more quickly if we weren't devoting most of standards development resources toward giving companies more fine-grained control of our browsers through CSS/JS.

Vrondi 4y ago

Yes. HTML gives the structure and hierarchy (if done properly) which is also what then gives the accessibility. CSS can do lovely things that will help a blind user with a screenreader not one bit unless you're kludging in "hacks" to give them extra hints for specialized use.