CSS extra space after section titles before periods

[Alex-Jordan]

Line 3310 of mathbook-3.css has .title::after { content: " ";}. Line 3286 of mathbook-3.css has .heading::after { content: ". ";}.

The net effect is that we see output like Definition 1.1.1 Average Velocity . instead of Definition 1.1.1 Average Velocity.

The space at 3310 is the one that I'm not sure has a purpose. I suppose there are places where a title has something come right after it, and that space is necessary for those occasions?

A similar issue makes for Exercise 1 . What... instead of Exercise 1. What... where a space follows a codenumber. That space is needed back in Definition 1.1.1 Average Velocity though.

Question: since all this stuff that comes before the period is visually separate from the body elements through CSS, is the period necessary? And if it is, then can we make the extra space showing up before periods go away?

[rbeezer]

Dear Alex,

I think the root cause of this problem is the HTML source written by xsltproc. But I'd love to be proved wrong.

Look at the HTML and see if their isn't an extra carriage return at the problem location. Generally, line breaks in the HTML seem to happen at "good" places, not in content.

I'm tempted to make a MWE and track it down to xsltproc, since it is very annoying. I wonder if some fresh, experienced eyes (ie you) will see something different, or a fix. This is the one long-running technical problem of writing out good source (of any kind) that I have not been able to solve.

Thanks, Rob

On 04/05/2015 10:19 PM, Alex Jordan wrote:

Line 3310 of |mathbook-3.css| has |.title::after { content: " ";}|. Line 3286 of |mathbook-3.css| has |.heading::after { content: ". ";}|.

The net effect is that we see output like Definition 1.1.1 Average Velocity . instead of Definition 1.1.1 Average Velocity.

The space at 3310 is the one that I'm not sure has a purpose. I suppose there are places where a title has something come right after it, and that space is necessary for those occasions?

A similar issue makes for Exercise 1 . What... instead of Exercise 1. What... where a space follows a |codenumber|. That space is needed back in Definition 1.1.1 Average Velocity though.

Question: since all this stuff that comes before the period is visually separate from the body elements through CSS, is the period necessary? And if it is, then can we make the extra space showing up before periods go away?

— Reply to this email directly or view it on GitHub https://github.com/rbeezer/mathbook/issues/80.

[davidfarmer]

There are some things in the CSS that didn't quite get converted properly when Michael switched my plain CSS to SCSS, so there could be a CSS issue. At some point I want to go through things carefully. I particularly want to eliminate CSS that applies to markup that should not actually happen.

But if there is an extraneous carriage return, then that is the real cause.

Rob: it would be good if your minimal example was accompanied by correct HTML, with a check that the CSS does the right thing.

On Mon, 6 Apr 2015, Rob Beezer wrote:

Dear Alex,

I think the root cause of this problem is the HTML source written by xsltproc. But I'd love to be proved wrong.

Look at the HTML and see if their isn't an extra carriage return at the problem location. Generally, line breaks in the HTML seem to happen at "good" places, not in content.

I'm tempted to make a MWE and track it down to xsltproc, since it is very annoying. I wonder if some fresh, experienced eyes (ie you) will see something different, or a fix. This is the one long-running technical problem of writing out good source (of any kind) that I have not been able to solve.

Thanks, Rob

On 04/05/2015 10:19 PM, Alex Jordan wrote:

Line 3310 of |mathbook-3.css| has |.title::after { content: " ";}|. Line 3286 of |mathbook-3.css| has |.heading::after { content: ". ";}|.

The net effect is that we see output like Definition 1.1.1 Average Velocity . instead of Definition 1.1.1 Average Velocity.

The space at 3310 is the one that I'm not sure has a purpose. I suppose there are places where a title has something come right after it, and that space is necessary for those occasions?

A similar issue makes for Exercise 1 . What... instead of Exercise 1. What... where a space follows a |codenumber|. That space is needed back in Definition 1.1.1 Average Velocity though.

Question: since all this stuff that comes before the period is visually separate from the body elements through CSS, is the period necessary? And if it is, then can we make the extra space showing up before periods go away?

— Reply to this email directly or view it on GitHub https://github.com/rbeezer/mathbook/issues/80.

— Reply to this email directly or view it on GitHub.[AAM6LO0NiKTBfy8GsVPe6BX7c04UN7rLks5n8rRSgaJpZM4D6tVW.gif]

[Alex-Jordan]

I can see the CSS that causes these spaces, and I don't think this has to do with carriage returns. I think it's just CSS pseudo elements and their CSS. The heading and title classes have :after {content " ";} and :after {content ". ";} in them.

Here is the actual HTML output that produces the definition example above, with carriage returns in place:

<article class="definition-like" id="definition-average-velocity"><h5 class="heading">
<span class="type">Definition</span><span class="codenumber">1.1.1</span><span class="title">Average Velocity</span>
</h5>
<p>If \(p\) is a position function...

And here is the same that produces the exercises. Since the <h5> begins without a carriage return from the previous line, I'm also pasting the entire previous line.

</h1></header><article class="introduction" id="introduction-1"><p>According to simplified Newtonian physics, if an object is dropped from an elevation of 200 m and allowed to free fall to the ground, then the elevation of the object (measured in m) is given by the position function \(\fe{p}{t}=200-4.9t^2\) where \(t\) is the amount of time that has passed since the object was dropped (measured in s).</p></article><article class="exercise-like" id="exercise-1"><h5 class="heading">
<span class="type">Exercise</span> <span class="codenumber">1</span>
</h5>
<p>What...

[davidfarmer]

The final example above has a carriage return before the closing h5 tag. That is the cause of the space before the period. (I say that based on an experiment I just did with the Exercises section of the sample document.)

[rbeezer]

I have something to try which may fix this - using an XHTML namespace might actually pretty-up the produced HTML. I'll try tonight or this weekend.

Rob

On 01/29/2016 09:37 AM, davidfarmer wrote:

The final example above has a carriage return before the closing h5 tag. That is the cause of the space before the period. (I say that based on an experiment I just did with the Exercises section of the sample document.)

— Reply to this email directly or view it on GitHub https://github.com/rbeezer/mathbook/issues/80#issuecomment-176877231.

[rbeezer]

I think this is fixed by moving to all the right commands to make legitimate XHTML output, which is necessary for EPUB anyway. At cae344d0

Now all the HTML is totally smashed together and unreadable by humans, but seems to have no faults. If you want something readable, use

xmllint --format some-file.html > a-pretty-file.html

but don't try to feed the pretty version to a browser, the CSS then fails totally.

[davidfarmer]

Will it be possible to go back later and automatically insert some blank lines at places which are irrelevant to the appearance in a browser, but which help readability for people?

On Sun, 31 Jan 2016, Rob Beezer wrote:

I think this is fixed by moving to all the right commands to make legitimate XHTML output, which is necessary for EPUB anyway. At cae344d

Now all the HTML is totally smashed together and unreadable by humans, but seems to have no faults. If you want something readable, use

xmllint --format some-file.html > a-pretty-file.html

but don't try to feed the pretty version to a browser, the CSS then fails totally.

— Reply to this email directly or view it on GitHub.[AAM6LKZLyH_E1p9vJJ9p_KxFwCgPRR7Wks5pfp6ggaJpZM4D6tVW.gif]

[rbeezer]

Don't know. At the moment, I don't know of any easy way. As we've seen, a newline in the wrong place breaks things, so we'd need to be very careful.

The xsl:output command has an @indent attribute which I have not been able to make effective. No amount of searching around has shed any light on that. I suppose that'd be the thing to explore first.

<xsl:output method="xml" encoding="utf-8" indent="yes" />

[davidfarmer]

Maybe something lowbrow like explicitly writing a carriage return after certain closing tags, such as "article"?

On Sun, 31 Jan 2016, Rob Beezer wrote:

Don't know. At the moment, I don't know of any easy way. As we've seen, a newline in the wrong place breaks things, so we'd need to be very careful.

The xsl:output command has an @indent attribute which I have not been able to make effective. No amount of searching around has shed any light on that. I suppose that'd be the thing to explore first.

— Reply to this email directly or view it on GitHub.[AAM6LD-3OK4HpprVaLFN6BUIxVlHgzaoks5pfskXgaJpZM4D6tVW.gif]

[rbeezer]

I think the "output serializer" is stripping out those sorts of things right now.

I've spent far too much time the past 48 hours pounding my head against the wall on this, and other such things, so testing will need to wait for another serious influx of patience. ;-) Am getting a few important things straight though.

Rob

On 01/31/2016 07:40 PM, davidfarmer wrote:

Maybe something lowbrow like explicitly writing a carriage return after certain closing tags, such as "article"?

On Sun, 31 Jan 2016, Rob Beezer wrote:

Don't know. At the moment, I don't know of any easy way. As we've seen, a newline in the wrong place breaks things, so we'd need to be very careful.

The xsl:output command has an @indent attribute which I have not been able to make effective. No amount of searching around has shed any light on that. I suppose that'd be the thing to explore first.

— Reply to this email directly or view it on GitHub.[AAM6LD-3OK4HpprVaLFN6BUIxVlHgzaoks5pfskXgaJpZM4D6tVW.gif]

— Reply to this email directly or view it on GitHub https://github.com/rbeezer/mathbook/issues/80#issuecomment-177742002.