tonydewan
unread,Sep 28, 2010, 3:40:09 PM9/28/10Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Sign in to report message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to S5 Project
I saw this list of outstanding issues to discuss in a recent post in
this group:
- What should S5 markup look like today? Should it make use of
HTML5? Microformats? RDFa?
- Can we get S5 markup producers to agree on a standard for markup?
- Can we establish a test suite to validate S5 markup?
- Could we maintain a central registry of S5 themes around S5 markup?
- What should the standard S5 JavaScript look like today? Should it
make use of something like jQuery or Prototype?
- Could it include hooks for extensible functionality, e.g. table of
contents? Could we maintain a central registry of plugins?
I'd love to to start to tackle some of these things. I'm not sure if
anyone is really "in charge" of the project, but I have a rather
immediate need for an updated S5 implementation, and will probably
create a public github fork to manage my changes. Unless of course the
person "in charge" has a more preferred method...
In the interest of keeping the conversation going, here my thoughts on
the above question.
- What should S5 markup look like today? Should it make use of
HTML5? Microformats? RDFa?
I don't see a whole lot of the current proposed S5 structure that
would benefit from HTML5. However, slide content certainly could (and
should!). I also generally have an aversion to the required XHTML
doctype and its implications. I understand it's for compatibility with
the Opera project, but I'm not sure I care about that...
- Can we get S5 markup producers to agree on a standard for markup?
I think this is a nonissue. As i mentioned above, very little would
have to change in the current S5 structure to make it "HTML5". Plus,
with a project as seemingly inactive as this one, I think dictating a
structure is fine, as long as whoever dictates it is open to feedback.
- Can we establish a test suite to validate S5 markup?
Sure, though I think it's less important of an issue, but well within
the realm of possibility.
- Could we maintain a central registry of S5 themes around S5 markup?
Absolutely should, yes. I also think it would be great to have a
presentation tool that you could pass a URL to a presentation and it
just works. Perhaps you can choose from a list of themes or apply
you're own (again via URL) and provide a solid presentation mode.
- What should the standard S5 JavaScript look like today? Should it
make use of something like jQuery or Prototype?
From what I've seen, the codebase needs quite a bit of optimization
and modernization. I think basing on jQuery makes the most sense. That
would (will?) be my choice.
- Could it include hooks for extensible functionality, e.g. table of
contents? Could we maintain a central registry of plugins?
An interesting concept. I'm not sure how important that is, though.
We're not talking about a project with much complexity that would gain
much from having a plugin architecture. But I could be wrong.
Some other thoughts:
I would love to incorporate some of the more exciting things going on
right now. For example, transitions and transformations would be a
great addition to themes. I can think of half a dozen UI concepts that
would really improve the experience of using and sharing an S5
presentation.