[whatwg] [html5] Semantic elements and spec complexity

[Ian Hickson]

On Thu, 11 Nov 2004, Matthew Thomas wrote:
> 
> I believe the past 15 years of semantic markup have shown these three 
> things to be true:
> 
> 1.  Most authors Just Don't Care about semantic markup. They'll only use
>     it if it's the easiest way of getting the visual effect or behavior
>     they want in their own favorite browser, or if they can use it to
>     game search engines. (That's why authors use <ul> and <li>, for
>     example, but not <address>.)

I don't know if the thrust of this argument is true, but I am pretty sure 
the parenthetical isn't. If authors don't use <address> I think it's 
because of a variety of reasons including its poor name, and its lack of 
particularly useful purpose.

I think there is a wide range of authoring styles, ranging from the author 
who really hasn't any idea that there is such a thing as semantics, and 
just thinks visually, to the author who just wants to get stuff done but 
understands that there are elements for specific purposes like lists, to 
the author who has bought the semantics religion but doesn't really 
understand it, leading to all kinds of "innovative" (and wrong) uses of 
HTML's less well known elements.


> 2.  Those authors who do care about semantic markup often do so
>     overzealously, using it even when it's not appropriate. For example,
>     they use <em> whenever they want italics or <strong> whenever they
>     want bold.

There are certainly authors who misuse semantic markup for reasons other 
than desiring presentational effects, yes.


> 3.  The more complex a markup language, the fewer people understand it,
>     the less conformant the average article will be, so the less useful
>     the Web's semantics will be. Current HTML authors may clamour for
>     new features, but they have forgotten what it was like to be a new
>     HTML author; and new authors are neither subscribed to this list nor
>     employed by browser vendors, so it is easy to forget about them.

Agreed.


> So if <section>, <navigation>, <header>, <footer>, <article>, and <sidebar>
> are introduced, with the default presentation currently suggested {display:
> block; margin: 0;}, I predict the following:
> 
> *   The A-list of Web developers will begin using all the elements
>     correctly on their Weblogs, and they will feel good about it.
> 
> *   A greater number of Web developers will never use most of these
>     elements, but they will replace all occurrences of <div> on their
>     pages with <section> because it's more "semantic" (just like they
>     did with <em> for <i> and <strong> for <b>), and they will feel good
>     about it.
> 
> *   The vast majority of article producers (Weblogs and online
>     newspapers) will never use <article>, because there's no visual or
>     behavioral benefit from doing so. So <article> will never become a
>     reliable way of dissecting or aggregating pages.
> 
> *   The number of knowledgable HTML authors, the proportion of HTML
>     pages that are valid, and therefore the overall usefulness of the
>     Web, will be less than it otherwise would have been because of
>     HTML's increased complexity.

I don't really think that such a dire consequence is likely.


> One way of improving this situation would be to reduce the number of new 
> elements -- forget about <article> and <footer>, for example.

These elements map pretty closely to common class values (in particular 
footer is the most common class name), so I don't think this is 
necessarily a good way to go.


> Another way would be to recommend more distinct default presentation for each
> of the elements -- for example, default <article> to having a drop cap,
> default <sidebar> to floating right, default <header>, <footer>, and
> <navigation> to having a slightly darker background than their parent element,
> and default <header>...<li> and <footer>...</li> to inline presentation. This
> would make authors more likely to choose the appropriate element.

I agree that this would be interesting. However, I'm at a loss as to what 
styles to use. Doing things like drop caps sounds cool, but in practice I 
fear it would actually discourage use due to weirdness and people not 
knowing how to override it (you'd have to do "article > p:first-line { 
font-variant: normal; }", which is pretty esoteric for the authors you 
mentioned just a little earlier).

Similarly, floating sounds like a good idea until you start considering 
how to make it interact with other text -- you'd need margins, and 
probably a top and bottom border, and padding, and a min-width, and a 
max-width... and soon you're at a level so complex that new authors are 
never going to be able figure it out, which defeats the whole point.


> A complementary long-term approach would be to deprecate the most 
> redundant and/or least effectual elements and attributes from HTML 4.01 
> -- for example, <acronym>, <big>, <small>, <q>, <var>, accesskey=, 
> cite=, longdesc=, and name= -- in preparation for removing them. This 
> would eventually help reduce the complexity of the spec.

Many of these, and many others, are indeed obsoleted in HTML5.


On Wed, 10 Nov 2004, James Graham wrote:
>
> This isn't really true, in general. For example, many sites fail to use 
> headings (and use odd combinations of <font> and <b> and <big> to get 
> the same effect) even though headings are the easiest way to get 
> something that looks kindof like a heading. In fact, unwanted styling on 
> elements has an adverse effect on their use (e.g. I have heard people 
> say "h1 shouldn't be used because the font is too big").

I'm not sure what to do about this, but it is an argument against 
providing complicated styles for the new elements.


> > So if <section>, <navigation>, <header>, <footer>, <article>, and 
> > <sidebar> are introduced, with the default presentation currently 
> > suggested {display: block; margin: 0;}, I predict the following:
> > 
> > *   A greater number of Web developers will never use most of these
> >     elements, but they will replace all occurrences of <div> on their
> >     pages with <section> because it's more "semantic" (just like they
> >     did with <em> for <i> and <strong> for <b>), and they will feel good
> >     about it. 
> 
> This could be a problem. In principle, the 'visual difference' should be 
> the link between <section> and headings. That might not be enough.

I'm not sure what else we can do.


> Did I already suggest an official authoring guide for the spec that 
> would explain the difference between <div> and <section> (and other such 
> issues) in a more approachable way than the spec itself can? If not, it 
> seems like a good idea.

Lachlan and DanC are now working on this, as I understand it.


> > , default <header>, <footer>, and <navigation> to having a slightly 
> > darker background than their parent element
> 
> It seems like there should be something more obvious that could be done 
> for these elements. For <header> and <footer> a border below and above, 
> respectivly, would seem obvious.

That would be simple enough, I guess; what do other people think?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'