Skip to content

7: Adjust signature CSS example#226

Open
vr8hub wants to merge 1 commit into
standardebooks:masterfrom
vr8hub:letter_sig
Open

7: Adjust signature CSS example#226
vr8hub wants to merge 1 commit into
standardebooks:masterfrom
vr8hub:letter_sig

Conversation

@vr8hub

@vr8hub vr8hub commented Apr 7, 2026

Copy link
Copy Markdown
Contributor

Per SEMoS 5.10, a signature only needs CSS if it is the only element in the paragraph; if it's just a part of a clause, then formatting is done with <b>. (This is also already discussed in the letter section.) For this reason, the example CSS in 7.7.4.4 should have a p in front of it, and the existing text on that example should probably mention when the CSS is needed.

I expect you'll want to change the wording, just let me know what you would like it to be. :)

@acabal

acabal commented Apr 7, 2026

Copy link
Copy Markdown
Member

Let's not include p in the selector, because its current state is a formula since signatures might not just apply to p. In a book that has both kinds of signatures a producer could get confused and include both, redundant, CSS.

@vr8hub

vr8hub commented Apr 7, 2026

Copy link
Copy Markdown
Contributor Author

Right, signatures don't apply to just p, but that's when we use b with the semantics, as per the examples. And the latter doesn't need CSS. So the only time we need CSS is for the instances when it's the only element in the p.

@acabal

acabal commented Apr 7, 2026

Copy link
Copy Markdown
Member

I understand. However I think this is inconsistent with the current case where it is a formula applied elsewhere, and can lead to duplicate CSS with an inattentive producer.

@vr8hub

vr8hub commented Apr 7, 2026

Copy link
Copy Markdown
Contributor Author

I'm sorry, I'm not catching what you're saying. What "current case"? And whatever it is, lint catches dup CSS, right?

Plus this is reducing the possibility of duplicate (or actually unnecessary) CSS—with the p in front, they know it's only intended for that one use, and that it isn't needed when it's only part of a clause, which is not obvious with the current CSS.

@acabal

acabal commented Apr 7, 2026

Copy link
Copy Markdown
Member

[epub|type~="z3998:signature"] is all over the corpus as a general selector for anything with a signature. It applies to many things and not just p. I don't want to narrow this example down to just p because then the inattentive producer will copy and paste it and possibly duplicate CSS if there are other non-p signatures in the book.

@vr8hub

vr8hub commented Apr 7, 2026

Copy link
Copy Markdown
Contributor Author

It must be Denseday where I am, because I'm still not understanding what "duplicate CSS" you're worried about. The CSS isn't needed for non-p signatures, so how could it possibly be duplicated? And, again, even if it was somehow duplicated, lint would catch it.

Yes, the CSS without the p is all over the place in the corpus. That was before we clarified that b should be used when it is part of a clause with other elements. So what is in the corpus now, in many cases, is wrong. Along with a thousand other things that are wrong in the corpus. But that has no impact on what we do going forward.

Going forward, we want to use CSS only in the case of the signature in a p by itself. If it's part of a clause, then CSS isn't needed. And that's what the wording that goes along with this change says—the CSS is only needed if it's by itself in the clause.

If the "inattentive producer" (who didn't bother to read the text that went along with the CSS) copies and pastes CSS but doesn't need it because nothing uses it, lint will flag that, too.

I literally don't understand what you're worried about. I'm still not getting it.

@vr8hub

vr8hub commented May 3, 2026

Copy link
Copy Markdown
Contributor Author

The review I'm working on has the exact problem this is trying to prevent—they used the span CSS from the manual and a span tag on a partial clause to format both salutation and signature, instead of using b in both cases per SEMoS 5.10 and the letter examples.

I still don't know what you meant by "where it is a formula applied elsewhere, and can lead to duplicate CSS with an inattentive producer," so would you please expand on that, give a concrete example, something?

I'll also note again that in addition to the CSS change, this includes text to explicitly say the CSS should only be used if it is the only element in a paragraph.

@acabal

acabal commented May 4, 2026

Copy link
Copy Markdown
Member

If the problem is that they're adding CSS when they should instead be getting small caps for free with <b>, then we should add that directive to the manual and I'm happy to do that.

However as I've already mentioned, the pattern of [epub|type~="z3998:signature"] is already all over the corpus and it's useful because we often want to style various types of elements that are not <b>. I want to keep that pattern in place as a broad general option, instead of forcing everyone to construct narrow selectors for this very, very common case.

@vr8hub

vr8hub commented May 4, 2026

Copy link
Copy Markdown
Contributor Author

That's what I'm trying to do here. :) That was the point of both the text and the CSS change; to indicate this CSS should only be used in cases where the signature is by itself in the paragraph.

And as I've already mentioned, I know it's all over the corpus, and that's a large part of the problem. People look at the corpus instead of SEMoS (or after looking at SEMoS), and repeat what's there, and the vast majority of the corpus is wrong on this particular point.

it's useful because we often want to style various types of elements… I want to keep that pattern in place as a broad general option…

I'm sorry, truly, but I still don't understand what you mean. Again, a specific example would help. When/where are you saying that span[epub|type~="z3998:signature"]{ font-variant: small-caps; } would be useful where a b shouldn't be used?

The CSS is only used to small-cap a signature, and it's a binary choice whether a signature exists by itself in the paragraph or is only part of the clause. So it's a binary choice whether CSS or b is used, and thus there's no need for the CSS except on a paragraph.

Or are you saying that a signature could appear by itself as part of an element other than a paragraph? If so, what element (honest question)? We require children on all of our containers, so I can't think of any other element a signature could appear in by itself. (This is again where an example would help.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants