Modified:
/PasteIns.wiki
=======================================
--- /PasteIns.wiki Thu Aug 11 19:45:58 2011
+++ /PasteIns.wiki Wed Sep 21 11:06:49 2011
@@ -2,56 +2,17 @@
#labels Phase-Design
=Introduction=
-Since Hawidu CSS is a single file, plug-in files or modules go against the
main goal of the project. What designer/developers need is a means to apply
a set of changes to their file in order to add certain
style 'functionality'.
-
-RCS patch files would be great, except:
- * They tend to rely on line numbers
- * They tend to be sensitive about file version
- * They tend to be context-unaware
-Given that Hawidu CSS is the basis for working files that are less
predictable than these constraints, the following article lays out a spec
for a patching system more suited to the Hawidu CSS workflow.
-
-=Requirements=
-==Designer Readable==
-These files will be included with Hawidu CSS download packages and
designers toying with the framework might not wish to mess with a
patch-applying script or anything of the sort. An ideal patching format
will be straightforward for humans to apply manually.
-
-==Machine Readable==
-A script must be able to parse the PasteIns file and apply the patch to an
implementation of Hawidu CSS in a manner that complies with the goals of
the project.
-
-If a selector exists in the hawiducss file, declarations can be
inserted/updated in the rule. The exact "if exists" behavior of the script
(to some degree of granularity) can be parametrized specific to a whole
file, a rule, or an individual declaration.
-
-If a selector does not exist (or does, but should not be overwritten), the
patch suggests context-appropriate place(s) for the script to insert the
rule. The last-ditch insertion point is the bottom of the file.
-
-==Forgiving==
-We want people to contibute PasteIns with a minimal barrier to entry. As
such, any valid CSS file should be able to be successfully applied to a
Hawidu CSS file, even if the result isn't _pretty_ from a project
standpoint.
-
-Given this requirement, this page ends up *specifying a 'smart' means to
apply any one CSS file to any other CSS file*.
-
-=Proposed Implementation=
-The smart insertion instructions will be contained within comment blocks.
Here's an example:
-{{{
-/*~
-:next-rule{
- -pastein-if-destination-rule-exists:insert;
-
-pastein-insert-after-family:first-selector('html'),comment-contains('body-reset');
- -pastein-other-comments:exclude;
- font-family:replace;
- font-style:preserve;
- }
-~*/
-
-/* This PasteIn prettifies the default font. */
-
-body{font-family:Chalkboard,Comic
Sans,serif;font-style:normal;line-height:1.5em;}
-}}}
-
-In the example, note the following:
- * A PasteIn comment block opens with a tilde. The closing tilde is not
required for parsing, but adds a soothing symmetry
- * The meta-language instructions use CSS syntax, which designers will
hopefully be able to grok (files made specifically as PasteIns should
probably start with a "what the hell is this?" comment)
- * CSS properties get written verbatim, but the values
are 'replace', 'preserve', and possibly others
- * There are some PasteIn-specific properties that use a -pastein vendor
prefix
- * The comment between the PasteIn comment and the rule will be excluded
- * If the same rule exists in the destination file, the PasteIn script
will insert the declarations via the given property rules. Other possible
values: 'replace', 'cascade', 'dumb-insert'
- * If the destination rule doesn't already exist, the PasteIn script will
first try to insert the new rule after the first html{} rule it finds, or
will try after a comment that contains the string 'body-reset'. Finding
neither, it will insert the rule at the bottom of the file
- * The selector for the instruction rule is ':next-rule'. Other possible
selectors include ':next(n)', ':all'
-
-The PasteIn script would have a set of reasonable defaults, for instance
assuming that declarations should be inserted within existing rules. Having
some level of JavaScript expression support might also be useful.
+Since Hawidu CSS is a single file, plug-in includes or modules go against
the main goal of the project. What designer/developers need is a means to
apply a set of changes to their file in order to add certain
style 'functionality'.
+
+=Pasteins=
+==Descriptive Directories==
+Pasteins are included in the source and all download packages in
the 'pasteins' directory. This section of the repository is separated into
*approved*, *pending*, and *unsupported* sections. A very early draft (with
potential incompatibilities with hawiducss syntax and guiding principles)
starts in the unsupported section. The pending section contains pasteins
that have been confirmed by a maintainer to be compatible, but have not
been tested enough to a stamp of approval. The approved section contains
tested CSS and 'demoted' styles previously in core. Approved pasteins are
candidates for core inclusion.
+
+Each pastein resides in a third-level directory named: mainelement-effect
+or a scheme resembling such. If the main element styled is the `<nav>` tag
and the stylistic effect is that of the apple.com main menu, a fitting
directory name would be *nav-apple*.
+
+==HTML Pages==
+A pastein loads hawiducss core via a relative link, then uses a style
element in the `<head>` to override. The styles to be pasted, instructions,
and examples are all included in the markup of the page, thereby enforcing
the concept of pasting these styles into the core stylesheet rather than
including them or other bad practices.
+
+==Automation==
+Previous versions of this page lay out a specification for _merging_
styles into the core stylesheet via a build script. While this initiative
is tabled for the time being, the feasibility of automating the application
of pasteins will be explored before 100 pasteins are included.