Underlining

[UncleIvor]

I needed to underline a section of text, so I selected it, and clicked on the underline icon. The tags "<u>" and /u duly appeared.

When I run F7, this throws up two errors:
'no declaration found for element 'u' '
and
'element 'u' is not allowed for content model '(a|br|span|bdo|map|object|img|svg|tt|i|b|big|smal l|em|strong|dfn|code|q|samp|kbd|var|cite|abbr|acro nym|sub|sup|input|select|textarea|label|button|ins |del|script)'

The paragraph in question is simply:

<p><u> ... text ... </u></p>

Anyone know why?

[KevinH]

Is this with the latest Sigil-0.9.0? If not, which version? Also, did you add the underline in BookView mode? If so, if you look in CodeView, were "u" beginning and end tags inserted anyplace else but inside the p tag?

KevinH

[UncleIvor]

Version 0.7.4.

It was added in codeview, and the appearance in code view is as above.

[eschwartz]

Well, <u> is supposed to be deprecated in favor of styles. I don't think Epubcheck will accept it, so it makes sense that Flightcrew will complain too...

[UncleIvor]

Removed 0.7.4 and installed 0.9.

Problem disappeared.

Any way of scrubbing this thread?

[KevinH]

No,

Actually you did not run Flightcrew in Sigil-0.9.0, Your ran sanitycheck. If you want to run FlightCrew you must load its plugin and launch it. Sanitycheck just checks if the source is parseable, it is **not** an epub2 validator. If you want to validate in Sigil-0.9.0 you must load either the epubcheck plugin or the flightcrew plugin.

As for the u tag, it exists in html4 but is deprecated, it exists in xhtml 1.0, it does not exist in xhtml 1.1, but now it is back in html5, xhtml5 but with a more restricted meaning and use.

Flightcrew uses the official xhtml 1.1.dtd when validating the epub and it does not allow the u tag.

Hope this explains things.

KevinH

[UncleIvor]

Thanks. Flightcrew now installed.

I'll use a <span style=""> for underlining.

[Notjohn]

Originally Posted by UncleIvor

I'll use a <span style=""> for underlining.

The logic of such rules escapes me. Occam's razor tells us that <u> is a much better solution than <span style="">, never mind having to include another style!

[Doitsu]

Originally Posted by Notjohn

The logic of such rules escapes me. Occam's razor tells us that <u> is a much better solution than <span style="">, never mind having to include another style!

Unfortunately, if you use <u> in ePub2 books, it'll fail epubcheck, however, you can use it in ePub3 books.

[DiapDealer]

I honestly don't think there will ever be a browser/renderer/reader that doesn't honor <u></u> ... regardless of whether the document claims to be (x)html4|5. But specs are specs.

[GrannyGrump]

Can't you declare "u" in your css? I often do that for "em" and "strong"

u {text-decoration: underline}

[eschwartz]

Originally Posted by Notjohn

The logic of such rules escapes me. Occam's razor tells us that <u> is a much better solution than <span style="">, never mind having to include another style!

A silly rule is still a rule.

And as DiapDealer said, the chances of any browser or ereader or any piece of code designed to render HTML NOT supporting it is... unlikely.

But if you want to conform to the spec and thus pass Epubcheck, you need to follow the silly rule. And if you want to submit an ebook to a store that demands you pass Epubcheck, you gotta conform to the spec...

Originally Posted by GrannyGrump

Can't you declare "u" in your css? I often do that for "em" and "strong"

u {text-decoration: underline}

That just forces the renderer to use the right styling for em/strong/u/b (in case it had a different default for some odd reason) -- but the element itself is still going to get noticed and trip a silly error.

[Arios]

The funny thing is that Sigil insert the codes <u></u>, the less funny thing is, as Doitsu and eschwartz said, epubcheck as well as FlightCrew do not like those codes... And specs are specs

[DiapDealer]

Originally Posted by Arios

The funny thing is that Sigil insert the codes <u></u>, the less funny thing is, as Doitsu and eschwartz said, epubcheck as well as FlightCrew do not like those codes... And specs are specs

True. But the button is there because there was a wysiwyg cry for such a thing. And making the button underline text in a spec-compliant AND sane method would be nothing but trouble: do we create inline styles; do we create a new class in the css file for each occurrance (do we create/link a css file if one doesn't already exist)? Do we parse existing css (both inline and external) to see if a suitable class to be used already exists? What if inheritance from a pre-existing class clobbers Sigil's efforts to create the underline? It's a nightmare any way you look at it.

My personal preference would be to give U tags a free pass in Sigil's well-formed check, if at all possible. Let the epub validators do all the barking about them. Short of that, I guess I'd like to see it (the button) made unavailable in documents where Sigil/gumbo deems them un-spec-worthy.

Good stuff!

[Jellby]

Originally Posted by GrannyGrump

Can't you declare "u" in your css? I often do that for "em" and "strong"

u {text-decoration: underline}

No, you can't create new elements in CSS, you can only define the formatting for existing ones. And <u> is not an existing element in XHTML.

But you can re-define <em>, for example (if you are underlining, it is probably because you want to emphasize), or give it a class:

em {text-decoration: underline; font-style: normal}

em.u {text-decoration: underline; font-style: normal}

In the second case, you'd use <em class="u">like this</em>.