S5 1.1a2
Published 19 years, 5 months pastI’ve posted an update to the testbed file that incorporates the new font-scaling routines from Michaël, and also a slightly corrected version of the internal-link slide routines contributed by Henryk Plötz back in the 1.0b2 days. These routines all seem to work fine, except the internal-link routines don’t seem to work at all in Safari. I tried several times to fix it, but I can’t figure out the problem. So fixing that is now on the to do list.
Speaking of which, here’s the current to-do list for S5 1.1, categorized by their importance. Any of these are, of course, subject to modification, deletion, and so forth.
- A way to trigger simple in-slide changes by hitting “next”. For example, having a list of bullet points appear one at a time as the space bar (or other “next” action) is hit, and then moving on to the next slide.
- The ability to cleanly list multiple authors in the metadata. I’ll get back to this in just a minute.
- Better, possibly more dynamic, theme selection. I don’t know how yet, nor am I sure how it might impact the outline/slide show view toggling.
- A way to choose whether to show/hide all of the navigation controls, or just the menu. Ordinarily, I’d say “do it in the CSS!” and you can in fact do that right now… as long as you don’t care that the behavior won’t be quite right in Internet Explorer. The problem is that I’m not quite sure how to manage this in a fully cross-browser fashion, short of scanning the CSS files for certain rules, and firing JS based on that. Which, frankly, sounds kind of ooky. Adding that information via a
metatag doesn’t seem like the right answer, but maybe I’m wrong. - A way to indicate the target resolution in the CSS, so that the scripts can use that for scaling purposes (thus making the scaling more intelligent). I’m not really sure this is needed, and I’m open to being convinced one way or the other.
If there’s anything missing, let me know. Also feel free to comment on what you think of the above plans.
Now for the metadata situation. As I understand things, having read RFC 2068, you can have multiple HTTP headers that share a name so long as they’re interpreted as a comma-separated list of values associated with that name. (Apologies if I’m mangling terminology, but HTTP headers aren’t really my thing.) So given the following:
<meta name="author" content="Eric Meyer" /> <meta name="affiliation" content="Complex Spiral Consulting" /> <meta name="author" content="Joe Public" /> <meta name="affiliation" content="ConHugeCo Corp." />
…this is an equivalent construction:
<meta name="author" content="Eric Meyer, Joe Public" /> <meta name="affiliation" content="Complex Spiral Consulting, ConHugeCo Corp." />
I find this to be a long way from ideal. In addition, since commas are the default value separator, if I understand the situation correctly, I can’t really do something like this:
<meta name="authors" content="Eric Meyer, Complex Spiral Consulting; Joe Public, ConHugeCo Corp." />
…because that ends up as equivalent to:
<meta name="authors" content="Eric Meyer" /> <meta name="authors" content="Complex Spiral Consulting; Joe Public /> <meta name="authors" content="ConHugeCo Corp." />
That’s even further from ideal. So here’s my current thinking for a way to represent multiple authors and affiliations:
<meta name="authors" content="Eric Meyer - Complex Spiral Consulting, Joe Public - ConHugeCo Corp." />
Anyone have a better idea than what I’ve proposed? I’d love to hear it. As part of said proposal, please keep in mind possible expansion of the information carried in the meta element. For example, titles might be added, which in my current thinking would go like this:
<meta name="authors" content="Eric Meyer - Principal Consultant - Complex Spiral Consulting, Joe Public - VP of IF - ConHugeCo Corp." />
It isn’t pretty, but it conforms to my understanding of meta value syntax. As I say, I’d be very happy to be shown a better way of forming the meta values.