CSS request

[Rob Beezer]

A request for some CSS work, please?

"Table notes" just got announced over on "pretext-announce". For HTML they are
in a "div.tablenote". They look OK now.

* Maybe they should be explicitly in the CSS, even if it is a no-op?

* The two PDF flavors seem to use a font that is about 70% in size (I can check
that). Maybe HTML should go with something smaller.

* Not sure if themes would want different treatment, but here's the chance.

Section 13 of the sample article is a good test bed, and specifically Table 13.2.

Thanks,
Rob

[Andrew Scholer]

I'll bite.

Also, it looks like accessibility best practice is to have the notes provide backlinks to the reference so you can find your way back easier if using a screen reader and/or keyboard. Should I add those and some aria-labels ("jump to table note a", "back to table note a")?

--
You received this message because you are subscribed to the Google Groups "PreTeXt development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pretext-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/MTAwMDA0SnFxRThzZDU.1785800128%40pnsh.

[Rob Beezer]

Thank-you. I guess a backlink should use a 100% automatic HTML @id. Right now an @xml:id and @label are banned in the schema. Probably ok to use the standard "html-id-attribute" and we get what we get. I think.

Thanks again,
Rob

[Rob Beezer]

We recently added "table notes" - sorta like footnotes for entries of tables. I
asked Andrew S about some CSS for the HTML version. Which he graciously did.
He also cleaned up the output (a list structure) to help with accessibility and
improve the styling/presentation. A great improvement.

But - and here's the rub - that made the CSS compulsory; and that same HTML is
used for EPUB, Reveal slideshow, and Jupyter.

Here's the takeaway on this post from me. Those conversions have been whipped
into shape and will no longer be allowed to suffer from neglect. (Braille is
the same way.) So if you are designing new output structures because you are
devoted to the HTML output, you are also responsible for the downstream
conversions as well, which have their own quirks. No claiming ignorance, no
foisting it off on others (me). (I am not accusing Andew of this!!! To the
contrary.).

Now, from Andrew on https://github.com/PreTeXtBook/pretext/issues/3121,

> If you want to keep Reveal/Jupyter up to date on features, it would help to
simplify testing/development for them.
>
> Suggestions/questions:
>
> * Is there a simple turnkey way to view the Jupyter build output? If not,
could there be?

Great question. I always have a Sage CLI executable around and it has a Jupter
notebook server built-in. @Sean (or anybody with experience) - what is the
dead-simplest way to go? Can we pip-install something into our Python virtual
environments. Is there an online server that would suffice? Don't send us down
some Anaconda rat hole, please. ;-)

> * Move the Jupyter CSS out of the XSL

Mostly for Andrew. Jupyter notebooks are totally paranoid. We have to put
inline CSS into a cell and ask the reader to execute it. So - where exactly?
And maybe also - how does this help? The XSL has to get it somehow and park it
in a cell, which I guess we can do by reading some file in. See above about quirks.

> * Make sure the sample-slideshow gets examples of anything considered
"slideable". There likely will be constructs that don't make sense there. But
anything that does make sense should be there.

Right. I'm leaving that to grow organically, so I guess "new" CSS could come
with new examples/features.

> * Those formats need a developer champion. I've essentially volunteered to be
a web CSS champion and will generally be happy to advise/help there on issues.
EPUB kind of follows from that. I'm not eager to spend time on these separate
branches of CSS for issues I didn't directly cause (by adding the feature in
question).

The champions right now are me and my assistant. But if the people who use
these would speak up when they try something not in the samples, then I think we
can now make short work of adding them. On-demand development, not speculative
development. And of course, champions are always welcome (Sean!).