Canonical repository?
Todd A. Jacobs
be a wiki and a source code repository. I've done a bit of noodling
around on GitHub, but all I'm finding are fractured projects.
What is the canonical repository for any ongoing development of S5?
Scott Reynen
I think the link you found from Eric's site is probably years old. A few
months ago I followed a link like that, and found the s5project.org
domain was no longer active. So I contacted the person who owned the
domain and asked about it, and he transferred the domain to me so I
could create a simple site for people who are interested in working on
the project.
I'm not aware of any current canonical repository for code. Would that
be for the JavaScript implementation? What would qualify it as canonical?
--
Scott Reynen
MakeDataMakeSense.com
Todd A. Jacobs
> be for the JavaScript implementation? What would qualify it as canonical?
repository, as opposed to a clone or a fork. I'm personally happy to
set one up (most of the work is already done on my end, actually, and
could be running in half a day). If the community uses it, then it's
canonical. :) I just don't want to bother managing a public repository
if no one but me is going to use it.
I'm also a bit concerned about the license. IANAL, so take this with a
grain of salt. :) The original code is public domain, but derivative
works (if enough creative juice is added to the work) might be
copyrightable. This raises the issue of how to handle patches and
contributions.
What do we do? Ask everyone that contributes to add "this patch is
released into the public domain" in their log message? Because of the
Berne Convention, any "work" not explicitly released to the public
domain (or otherwise licensed) is assumed to be 100% copyright of the
author. This is one of the problems that GPL solves neatly by making
all derivative works subject to the same license, but public domain is
a horse of another color.
On of my thoughts was to explicitly state that new contributions were
licensed under the GPL, while the original code-base remains public
domain. I'm not sure how kosher that is, though, or how such a move
would be received by the potential contributors...it's just an idea I
had to resolve what I see as a potential problem for the community.
Thoughts?
Thomas K
should be public domain, otherwise you end up with an unwieldy
mishmash of code under different licenses. If someone should build a
substantial new system on top of it (e.g. a slideshow editor), then
it's up to them how to license it (personally, I favour BSD style
licensing).
Scott Reynen
I'd like to take a step back here and clarify exactly what code we're
talking about licensing. Is this the code currently hosted on Eric's
site here?
http://meyerweb.com/eric/tools/s5/
Or a new version of that code? Or a completely new code base reflecting
a thoroughly documented and updated markup standard for slide shows on
the modern web?
I'm personally most interested in the last one. I don't see much value
in maintaining the existing code base, as much of it has been made
irrelevant since it was written. If we're talking about something based
on the existing public domain code, I don't see how that could be
anything other than public domain without making things incredibly
confusing.
--
Scott Reynen
MakeDataMakeSense.com
Thomas K
> I'd like to take a step back here and clarify exactly what code we're
> talking about licensing.
the original S5 has kind of been superseded), then there's no
constraint on what license to choose.
I'm unsure about using GPL: a presentation system might well be
distributed with the presentation, and I don't know if that would
force the presentation (or other code that's included with it) to be
GPLed. I tend to use the MIT license (do whatever you want, but keep
the copyright notice intact), myself. Ultimately, I suppose the
decision will be made by whoever knuckles down to start writing the
codebase, but that's my two cents.
Thomas K
improving and updating the original S5 system; Scott, you're more
interested in something entirely new. What sort of thing are you
imagining? In terms of modernity, I think S5 is well behind the Apache-
licensed unnamed code from Google used at http://slides.html5rocks.com/
. If we want a new presentation system, I'd suggest using that as a
starting point.
To my mind, the missing piece of the puzzle is a WYSIWYG editor of
some sort: creating presentations by manually editing HTML is never
going to become very popular. I mentioned Slimey, a web based editor,
in another thread. Is anyone interested in reviving that? I might set
up a site on Appengine where we can test it out easily, and see the
presentations it produces rendered.
Or should we be looking to define a standard format for HTML
presentations? Reuse the same slides in different slideshow engines?
I'm not quite sure that it's necessary, but maybe there's a reason. We
could also look at using data URIs (to hold entire presentations in a
single file), or dynamic loading of slides using AJAX for large
presentations.
Thomas
Todd A. Jacobs
> licensed unnamed code from Google used athttp://slides.html5rocks.com/
> starting point.
> To my mind, the missing piece of the puzzle is a WYSIWYG editor of
> some sort: creating presentations by manually editing HTML is never
in mind: building slides from HAML and YAML files. I've already
stubbed out something like that for myself, but I think it will take
some work to generalize it and make it useful to a wider audience.
At the end of the day, I'm scratching my own itch. I suppose that's
the mark of any good project:
1. It scratch someone's itch, and
2. It have a bus-factor great than 1.0. :)
Personally, I want to avoid the projects that require custom
presentation software. Hence, my lack of current interest in ShowOff
and similar. That doesn't mean such projects don't scratch someone
else's itch, though.
Scott Reynen
> What are we trying to achieve here? Todd, you seem to be interested in
> improving and updating the original S5 system; Scott, you're more
> interested in something entirely new.What sort of thing are you
> imagining?
I wouldn't say _entirely_ new. I took over the s5project.org domain
because the S5 implementations are heavily fragmented and there was
previously no central place to discuss standardizing them. As these
implementations are written in different languages, the place to
standardize them is the markup, not the code. If they all use the same
markup, the same slideshows can be passed between implementations
without compatibility problems.
So that's where I'd like to start. But that's just me.
> In terms of modernity, I think S5 is well behind the Apache-
> licensed unnamed code from Google used at http://slides.html5rocks.com/
> . If we want a new presentation system, I'd suggest using that as a
> starting point.
In terms of markup, that's very similar to S5. Both have a top-level
container of class="presentation" and each slide is class="slide". The
big difference is in the whole class="layout" section of S5, which
Google (I think rightly) does away with entirely. That said, I think the
place to start is here:
http://meyerweb.com/eric/tools/s5/structure-ref.html
There's a lot of other implementations, such as Google's, that should
inform changes to that, but we should start with a full documentation
like that so we don't have to write something new from scratch.
> To my mind, the missing piece of the puzzle is a WYSIWYG editor of
> some sort: creating presentations by manually editing HTML is never
> going to become very popular.
The Drupal S5 module can create slides (just like all other Durpal
content) with WYSIWYG editors:
Google also has a WYSIWYG slideshow creator:
http://www.google.com/google-d-s/presentations/
Of course, that can't be used in their HTML5 slideshow player, because
it uses slightly different markup (differences that have nothing to do
with HTML5).
> Or should we be looking to define a standard format for HTML
> presentations? Reuse the same slides in different slideshow engines?
> I'm not quite sure that it's necessary, but maybe there's a reason.
It's certainly not necessary, not any more than it's necessary for all
browsers to share a common understanding of HTML, at least. But the
benefits of standards are huge. Even within a single slideshow player,
if something isn't working, how do we know if it's a problem with the
player or a problem with the HTML? By adding standards, we solve this
problem with validators (e.g. http://validator.w3.org/) and test suites
(e.g. http://www.acidtests.org/). These give us better browsers, not
just because they're interchangeable, but because clearly defining
"works" makes it a lot easier to make tools that work.
With S5 today, I don't think it's very clear how things should work, and
I see documenting changes to the markup standard as the first step
toward fixing that.
--
Scott Reynen
MakeDataMakeSense.com
Thomas K
> If they all use the same
> markup, the same slideshows can be passed between implementations
> without compatibility problems.
mean a standard theme format for presentations (largely CSS--I don't
know if some HTML/JS would be needed). But, while I'm all for
standards, standardising S5 isn't going to achieve much if Slidy &
html5slides (as I'll call Google's thing) are incompatible, not to
mention that most of the world is still on Powerpoint/Keynote. For a
standard to gain any traction, people have to want to use it, and I
think that a WYSIWYG editor able to produce standard-compliant
presentations is the obvious way to get people using it.
> The Drupal S5 module can create slides (just like all other Durpal
> content) with WYSIWYG editors:
not just a rich text HTML editor). The screencast only shows editing
raw markdown and HTML.
> Google also has a WYSIWYG slideshow creator:
its presentation view is nothing like S5/Slidy/html5slides), and I
doubt Google are going to let you use it anywhere other than their
servers.
There's an old (not really working) skeleton of an editor for Slidy
using ContentEditable*, and Slimey, which produces an extended form of
S5 it calls SLIM. These are the only editors for this sort of
presentation that I know of.
* http://people.w3.org/~dsr/editor/old/editor.html
Scott Reynen
>> http://slides.html5rocks.com/
>
> I couldn't even get it to run on my system. I did peek at it, though.
That's doing a bunch of stuff that only works in newer browsers, but the
underlying HTML is very similar to S5. If S5 had layout defined by CSS
(where it belongs) rather than in the HTML, I think you might actually
be able to play that slideshow with Eric's player.
On 11/14/10 12:33 PM, Thomas K wrote:
> On Nov 14, 5:55 pm, Scott Reynen<sc...@makedatamakesense.com> wrote:
>> If they all use the same
>> markup, the same slideshows can be passed between implementations
>> without compatibility problems.
>
> OK, I can agree with that. A standard presentation format should also
> mean a standard theme format for presentations (largely CSS--I don't
> know if some HTML/JS would be needed).
I think CSS is probably enough for slide display. I can see defining
transition styles in JS being really useful. Transitions aren't really
defined at all in S5 1.1 and I'd like to add them in a future revision.
The technology is there (e.g. jQuery UI) to get much closer to
PowerPoint or Keynote quality presentations with web standards.
> But, while I'm all for
> standards, standardising S5 isn't going to achieve much if Slidy&
> html5slides (as I'll call Google's thing) are incompatible, not to
> mention that most of the world is still on Powerpoint/Keynote. For a
> standard to gain any traction, people have to want to use it, and I
> think that a WYSIWYG editor able to produce standard-compliant
> presentations is the obvious way to get people using it.
Yeah, formats and implementations are a classic chicken-egg problem, and
that's a good reason to defer to existing implementations as much as
possible when trying to establish a standard format. I think the
experience of both HTML5 and microformats suggest people will implement
tools around a practical format that doesn't stray too far from the
tools that are already built. But even ignoring that potential, if we
only focus on Eric's JS implementation and a new WYSIWYG slideshow
editing functionality, we'll still need documentation of the format used
between the two.
Google does imports of PowerPoint, so establishing a standard for
Google's slideshow HTML would mean a PPT-to-S5 converter.
>> The Drupal S5 module can create slides (just like all other Durpal
>> content) with WYSIWYG editors:
> I don't see any evidence of a WYSIWYG editor (as in, a slide editor,
> not just a rich text HTML editor). The screencast only shows editing
> raw markdown and HTML.
Markdown can be easily swapped out for TinyCME, CKEditor, etc. in
Drupal. I'm not sure I understand the distinction you're making between
WYSIWYG HTML editors and WYSIWYG slideshow editors in a format where the
slides are HTML. Are you just saying the HTML WYSIWYG editors need more
slideshow-specific controls? Or do you think slideshows are different
enough that they should have completely separate WYSIWYGs?
>> Google also has a WYSIWYG slideshow creator:
> But it doesn't offer a way to save in any HTML format (the source of
> its presentation view is nothing like S5/Slidy/html5slides), and I
> doubt Google are going to let you use it anywhere other than their
> servers.
Right, there's no "export S5" option because there's no established
format to export. But the "start presentation" option creates an HTML
document that looks very similar to S5.
> There's an old (not really working) skeleton of an editor for Slidy
> using ContentEditable*, and Slimey, which produces an extended form of
> S5 it calls SLIM. These are the only editors for this sort of
> presentation that I know of.
> * http://people.w3.org/~dsr/editor/old/editor.html
Adding slideshow-specific controls to existing well-maintained WYSIWYG
HTML editors seems like the best place to start getting that kind of
functionality, both because most of the work is already done there, and
because those are familiar interfaces for end users.
A lot of this seems like it would be useful to document in a wiki, so I
think I'll set something up soon.
--
Scott Reynen
MakeDataMakeSense.com
Thomas K
> I think CSS is probably enough for slide display. I can see defining
> transition styles in JS being really useful. Transitions aren't really
> defined at all in S5 1.1 and I'd like to add them in a future revision.
> The technology is there (e.g. jQuery UI) to get much closer to
> PowerPoint or Keynote quality presentations with web standards.
supported, with a way to fall back to javascript based transitions
elsewhere. Once Firefox 4 is out, IE will be the only one of the main
five browsers not to support them. But transitions wouldn't be too
high on my priorities overall: you can create perfectly professional
looking presentations without them, and horribly distracting
presentations with too many, although they're alright in moderation.
> I'm not sure I understand the distinction you're making between
> WYSIWYG HTML editors and WYSIWYG slideshow editors in a format where the
> slides are HTML. Are you just saying the HTML WYSIWYG editors need more
> slideshow-specific controls? Or do you think slideshows are different
> enough that they should have completely separate WYSIWYGs?
basically rich text, with a few illustrations, to be displayed on one
page. Slides are very different: most obviously they are designed to
be displayed slide-by-slide, not run together into a document. But
layout is also much more important with slides: you want to be able to
move elements around on the slide independently, overlap them, and so
on. It's much like the difference between Word and Powerpoint. Perhaps
it's clearer if I point you at the demo of Slimey:
http://slimey.sourceforge.net/slimey/slimey.html
I think it would be much better to build up Slimey (which is already
roughly working), than to try to shoehorn rich text editor controls
into a role they're not designed for.
> Right, there's no "export S5" option because there's no established
> format to export. But the "start presentation" option creates an HTML
> document that looks very similar to S5.
source of the presentation I get bears no resemblance to S5/Slidy/
html5slides at all. The first slide is contained in Javascript in the
page, and it seems that subsequent slides are loaded via AJAX. Even if
they do have a more plain HTML version, I wouldn't count on it staying
around.
Scott Reynen
> But
> layout is also much more important with slides: you want to be able to
> move elements around on the slide independently, overlap them, and so
> on. It's much like the difference between Word and Powerpoint. Perhaps
> it's clearer if I point you at the demo of Slimey:
> http://slimey.sourceforge.net/slimey/slimey.html
I do my slide layouts in CSS, so I hadn't thought of that as something a
slide editor would do, but it definitely makes sense after looking at
Slimey. I can see how layout wouldn't work in normal HTML WYSIWIG
editors, and doing it in CSS wont' work for most people.
> Am I getting a different version of Google Docs to you? The HTML
> source of the presentation I get bears no resemblance to S5/Slidy/
> html5slides at all. The first slide is contained in Javascript in the
> page, and it seems that subsequent slides are loaded via AJAX.
I see now I was looking at the DOM rather than the source. It does
eventually create a document, but as it does so via JS within the
browser, it's not a document anyone else could read.
> Even if
> they do have a more plain HTML version, I wouldn't count on it staying
> around.
I wouldn't count on any individual vendor to adopt standards, no, but I
would definitely count on the web in general moving in that direction,
as it historically has at almost every opportunity.
--
Scott Reynen
MakeDataMakeSense.com