Re: html structure revisited

[Per Bothner]

On 8/8/20 1:16 PM, Gavin Smith wrote:
> One is the large space above the chapter headings, which is due to
> the h2 { margin-top: 3em } style on line 53 of kawa.css.

Good catch.  This seems to work better (consistent and smaller)
h1, h2 { margin-top: 2ex }

> I don't know exactly what you mean by inconsistent padding ...
> there is a slight margin around all of the pages apart from the top one.

I was using padding generically to refer to the symptom (extra space - padding 
and margin
and possibly other css properties), and noted the cause seemed related to the 
CSS margin.

I will play with your suggestions [not quoted here].
An acceptable solution may not *need* to tweak the html structure -
though I hope we can do that anyway.

> I'll try to have a look at this but it would be better to avoid using
> HTML5 tags without a good reason, or to have the complication of trying
> to support different versions of HTML.

The only extra HTML5 tag I'm proposing is <section>, which according to
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/section
appeared in Firefox and Chrome around 2010/2011.

However, older browsers will presumably just ignore the <section> tag,
which should be harmless. I'm assuming they wouldn't also ignore the 'id'
attribute, which would not be harmless.  Assuming that is the case (which
should be tested), we don't need to do anything different for older browsers.

The advantage of using <section> rather than <div> is that <section>
conveys some extra semantic information, which some tools (EPUB readers?)
might make use of.  I don't actually know though.

I think the advantage of using <section> outweighs the risk - but we should
do some testing on older browsers (both with and without info.js)
once we have a structure that we like.

> > * Fewer <span> elements added just for anchors: The 'id' refers to a 
> > corresponding
> > element, not just a point at the start of the element.
>
> That sounds good assuming there is an appropriate element for it.  If I
> understand right you are adding <div>'s where there weren't any before.

Yes - <div>s and <section>s (which are essentially a kind of <div>).

> It seems logical but I'd like to understand the practical benefits of
> it.

Some reasons that come to mind:

* You can style based on chapter/section and/or node. For example
showing the nested chapter/section structure using borders:

  <style type="text/css">
    section { border: 2px solid red; padding: 2px; margin: 1px }
    section.chapter { border-color: blue }
    div.node { background: #E0F0E0 }
  </style>

* Easier for JavaScript to manipulate elements of the document.
For example, you could have info.js work on a --no-split html file,
and still only display a single chapter or section at a time.

* Other tooling that analyses or post-processes the HTML can extract
or re-arrange chapters/sections or nodes.  More tooling would be available
if the HTML were well-formed XML.  (We're close, but not quite there.)
There obviously exit tooling that analyzes generic HTML,
but they might be able to do a better job with more logical structure.
> Regarding this part of your patch:
>
> > -  $result .= "<span id=\"$element_id\"></span>"
> > -    if (defined($element_id) and $element_id ne '');
> > +  $result .= '<div class="convert-heading-' . $cmdname . '"';
> > +  $result .= " id=\"$element_id\""
> > +      if (defined($element_id) and $element_id ne '');
> > +  $result .= ">\n";
>
> I don't follow as the text "convert-heading-" doesn't appear in your
> sample structure.

Sorry I was unclear.  The patch shows my experimentation, so I included
the "convert-heading-" prefix as an aid purely to my testing/understanding.
We do not want that in the actual code.  The patch also has other problems, as 
noted.
--
        --Per Bothner
per@bothner.com   http://per.bothner.com/