Julian Mehnle wrote:
The new domains are going to be declared official at the
next meeting, too, after which we will see to them being
transferred to the project's domain trustee, who is also
going to be delegated at the next meeting.
John's openspf.com already works as expected. I wait for
.org before I start to replace spf.pobox URLs "everywhere",
e.g. http://purl.net/net/spf
http://purl.net/xyzzy/rxdyndns.htm
http://dir.gmane.org/gmane.mail.spam.spf.discuss
(= various "SPF project URLs" on GMaNe)
I also have to replace links to the "community position"
URL on my pages as soon as that's clear.
Dito the SPF status URL (from IETF I-D tracker to the RfC
editor queue as soon as it arrived there). Some I-Ds wait
for years (sic!) in the RfC editor queue.
If the URL of the Council pages changes it's also something
I've to update - maybe you plan to transfer your WiKi to
the new "official" SPF server.
The website will be editable by all council members and
the webmaster, who will coordinate community efforts to
flesh out the site.
Technical requirements for that part:
1: all pages are "valid" as determined by the W3C or WDG
validator.
2: no page generates a "warning" with the WDG validator,
such stuff is in theory valid but in practice broken
with every browser (= unsupported SGML-effects).
3: backwards compatibility where possible and reasonable:
3a - no UTF-8 where Latin-1 is good enough
3b - decimal character references instead of hex. (that
violates a W3C Charmod recommendation, but the W3C
is ignorant wrt reasonable backwards compatiblity)
3c - no <del> without <s>. If a page insists on using
<del> it MUST use a "transitional" DTD. The W3C
"accessibility" guidelines want "strict", but the
W3C is ignorant about backwards compatibility,
3d - no weird mixtures of legacy markup and CSS, if in
doubt use CSS for most decorations.
3e - Where colours determine the _semantics_ use legacy
(transitional) markup, or better think, it won't
work for text browsers.
3f - The complete number of absolute heights and widths
should be zero. All cases of "100%" should be "95%".
3g - Any use of fonts and font sizes is verboten, <big>
and <small> are okay if absolutely necessary.
3h - No funny inline images, if absolutely necessary GIF.
No frames, iframes, objects, applets, "embeds",
layers, javascripts, VB scripts, or inline styles.
3i - All critical pages must work with text browsers or
voice browsers. Simple tables are permitted where
necessary, dito simple forms where necessary.
Etc., it all boils down to KISS. Plain and simple pages
are almost always better than "nice" pages with tons of
decorations and other unnecessary "features".
I volunteer to transform PNG to GIF where necessary, for
purists I could even create a GIF-without-LZW. The most
important GIF is 1*1 pixels transparent, grab it from me:
http://purl.net/xyzzy/pub/clear1x1.gif (45 bytes, no LZW)
http://purl.net/xyzzy/pub/clearlzw.gif (43 bytes)
Above all avoid JavaScript.
I also plan to have a wiki as a publicly editable sub-section
of the site so as to provide centralized infrastructure for
creating SPF-related content.
Does anybody in the community want this ? Anything without a
backlink is not very attractive for Googlebot-fans.
A loose collection of an introduction plus some HOWTOs and a
FAQ won't cut it.
No idea what you're talking about. Creating content (starting
with articles published here) is an effort, you should take it
where you find it.
Bye, Frank
