SEO

May 27, 2011

#1 Stylesheet Greatest CSShits (1994) PLUS...

#1 Stylesheet Greatest CSShits (1994)

PLUS More Historic Docs Posterous CAN'T ParseW3C Workshop on Style Sheets

 

I used the first stylesheet for this post, but then gave up  WHEN I REALIZED  POSTEROUS CAN NOT EVEN PARSE THE DECLARATION OF STYLE INDEPENDENCE from 1994

Este_document_es_honorado_4

White_template_with_just_lines

Woolly_outline-l

Wolly_css_goat_crop
Extern_0000
F1116ed33a7a9686e3768b7c4d1608
The W3C CSS Validation Service

W3C CSS Validator results for TextArea (CSS level 2.1)

Congratulations! No Error Found.

This document validates as CSS level 2.1 !

Valid CSS information

div, ul, dl, dt, dd, pre, ol, li, blockquote, address {
color : black;
a, address, blockquote, body, cite, code, dd, del, dfn, div, dl, dt, em, form, h1, h2, h3, h4, h5, h6, iframe, img, kbd, li, object, ol, , , samp, small, span, strong, sub, sup, ul, var, applet, big, center, dir, font, hr, menu, pre, abbr, acronym, bdo, button, fieldset, ins, label {
word-spacing : normal;
letter-spacing : normal;
text-transform : none;
text-decoration : none;
border-color : black;
border-style : none;
}
body {
color : black;
background : white;
}
em {
font-style : normal;
font-weight : bold;
color : black;
background : white;
}
strong {
font-style : italic;
background : white;
font-weight : bold;
color : black;
}
em strong, strong em {
text-transform : uppercase;
font-style : normal;
font-weight : bolder;
background : white;
color : red;
}
{
font-weight : bold;
}
i {
font-style : italic;
}
.warning {
text-transform : none;
font-style : normal;
font-weight : bolder;
background : white;
color : red;
}
del {
text-decoration : line-through;
background : #f66;
}
ins {
text-decoration : underline;
background : yellow;
}
var, cite, dfn, .note {
font-style : italic;
}
address {
font-style : normal;
letter-spacing : 0.1em;
}
acronym {
font-variant : small-caps;
letter-spacing : 0.1em;
}
h1, h2, h3, h4, h5, h6, dt, th, thead, tfoot {
color : black;
background : white;
}
hr {
color : black;
}
#colophon {
display : none;
}
col, colgroup, table, tbody, td, tr {
color : black;
text-decoration : none;
border-color : black;
border-style : none;
background : white;
}
a:link {
text-decoration : none;
font-weight : bold;
color : #c00;
background : #ffc;
}
a:visited {
text-decoration : none;
font-weight : bold;
color : #999;
background : #ffc;
}
a:active {
text-decoration : none;
font-weight : bold;
color : #f00;
background : #fc0;
}
a:hover {
text-decoration : none;
color : #c00;
background : #fc0;
a.offsite {
text-decoration : none;
font-weight : normal;
color : #c00;
background : #ffc;
body {
margin-top : 1.58em;
margin-left : 4%;
margin-right : 2%;
margin-bottom : 1.58em;
padding-top : 0;
padding-left : 0;
padding-right : 0;
padding-bottom : 0;
border-top : 0;
border-left : 0;
border-bottom : 0;
border-right : 0;
width auto;

Historical Style Sheet proposals

During the history of the Web there have been a number of style sheet proposals, and this page links to most of them. The proposals are roughly in chronological order. They contain ideas that current specifications build upon, and serve as background material.

Several of the above proposals were presented at a W3C workshop on style sheets in Paris Nov 6-7 1995. The notes are available.

Bert Bos, W3C Style Sheets Activity Lead
and Håkon Wium Lie, former W3C Style Sheets Activity Lead

Copyright  ©  1997-1999 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.

QACSS

 

I heart Validator logo

------------------------------------------------------

Copyright © 1994-2009 W3C ® ( MIT -----------------------

APPENDIX II Stylesheet Layout and Parsing Considerations -- (TECHNICAL DETAIL) -------------------------------------------- An example stylesheet follows the discussion of the various styles, and details the recommended layout of a stylesheet. Each element of the stylesheet is uniquely marked and the name of each style and style attribute has been chosen to be unique to the first two letters, which makes parsing the style-sheet a simple task. Parsing Rule #1: Lines which do not have as their first non-whitespace character either an '@' which signals the beginning of a new object definition or an alphabetic [a-zA-Z], will be ignored to the end of the line. Parsing Rule #2: Next we throw out all the newlines and scan the remaining buffer. An '@' (at-sign) signals the beginning of a new HTML object definition. Parsing Rule #3: After the '@' and possible intervening whitespace, we expect the name of an HTML object (eg. TITLE, H1, B, STRONG, etc.) Parsing Rule #4: After the name, and intervening whitespace, we expect at least two characters which signal the beginning of a style. Legal values are: fo, ju, co, br, ma, ve, in, li Parsing Rule #5: After the two character style specifier, scan to the '(' (open-paren) and ignore intervening data or whitespace. ... (I think you get the idea, but I'll fill this in later if necessary) ----------------------------------------------------------------------------- The style sheet workshop was held in Paris Nov 6-7. Here are the notes.
WWWW3C

W3C Workshop on Style Sheets

November 6-7, 1995

Paris, France

Organized by the World Wide Web Consortium and INRIA.

Workshop Profile

For background information on web style sheets, see the style sheet resource page.

Style sheets have the potential of adding style to the web without sacrificing device-independence or document structure. Instead of adding visual tags to HTML, style sheets attach presentational information to the structure of SGML and HTML documents.

The goal of the workshop is to present the current status of style sheets, and to provide a forum for discussing future development and deployment of style sheets on the web. We want to bring together browser implementors, content providers and the people behind current style sheet initiatives. The outcome of the workshop will help W3C focus its effors in this area. In particular, we hope the workshop will produce a list of short term objectives to standarization, and a list of volunteers from member organizations committed to providing a specified amount of their time to help bring these things about on a given timescale.

The workshop will run over two days. On the first day, presenters will describe proposed style sheet mechanisms, demonstrate current software, and outline their views on future deployment. On the second day, smaller discussion groups will identify work, specifications and code needed for style sheet deployment on the web.

Some likely discussion topics:

  • Which content providers are significant for style sheet deployment? Home page writers, newpapers, publishing houses? Web-site designers?
  • What are the requrements for a successful style sheet mechanism on the web?
  • The scope of style sheets mechanisms: should they handle UI aspects (toolbar, menus, window size, etc.), link behaviour (single/double click, drag), forms, etc.?
  • How does the concept of style sheets fit with alternate UI metaphors, e.g. outline editors, filtering agents, and virtual realities?
  • Is multiple style sheet formats beneficial or distracting?
  • How to resolve presentation preference conflicts between authors, publishers and readers?
  • Is time on the side of style sheets? If not, how much time do we have?
  • How to classify style sheets in as Internet Media types (MIME types). Can style sheets be a case study for content negotiation?
  • In HTML, how should styles be linked and embedded? STYLE element? STYLE attributes?
  • How can non-visual media be supported through style sheets.
  • How do the formatting models of the different proposals match? Is code-sharing possible?
  • How can we improve the robustness of style sheet implementations w.r.t. environment resources? E.g., should the output device provide alternate fonts and colors? Can lessons be learned from current DTP? Can one determine when a style rule is successful?
  • What support software is determinant for the success of style sheets? HTML browsers, SGML browsers, style sheet editors, DTP conversion tools, link management tools, off-line rendering software for high-quality printing, conversion tools between various style sheet formats?
  • Software: what should W3C make available, what can others contribute?
  • What needs to be done on a short time scale and who will do it?

Preliminary Agenda

Chair/facilitator: Steven Pemberton (CWI)

Monday 6 November:

We also invite presentations from W3C member companies. Please contact Håkon Lie (howcome@w3.org) if you want to present.

  • 09:00 Opening statement: Jean-Francois Abramatic (W3C/INRIA)
  • 09:10 Introduction Steven Pemberton (CWI)
  • 09:40 David Siegel "What do Web-site Designers Really Want?"
  • 10:15 Daniel Connolly (W3C/MIT) "Style Sheets as a Tool for Information Management"
  • 10:45 Coffee break
  • 11:00 James Clark "DSSSL and DSSSL Lite on the Web"
  • 11:45 Håkon Lie (W3C/INRIA) "Cascading Style Sheets"
  • 12:15 Cecile Roisin (INRIA, OPERA) "P: a Style Sheet Language for Structured Documents"
  • 12:45 Lunch
  • 13:45 Kevin Hughes (EIT) "Why I don't use HTML extensions"
  • 14:30 Dave Raggett (W3C/MIT/HP) "Style Sheet support for tables"
  • 15:00 Break
  • 15:15 William Perry (Spry) "Implementing Style Sheets in emacs-w3"
  • 15:45 George Williams (Navisoft) "Style Sheets in the NaviPress Browser/Editor"
  • 16:15 Break
  • 16:30 Glenn Adams (Stonehand/Unicode), "Style Sheets and International Text"
  • 17:00 Bert Bos (W3C/INRIA) "CSS level 2"
  • 17:30 Louis Weitzman (MIT Media Lab), "Beyond Style: Adaptive graphic articulation within HTML"
  • 18:00 End of presentations
There will be an informal workshop dinner Monday night.

Tuesday 7 November

  • 09:00 Brainstorming session. Goal: identifying topics for working sessions. Chair: Steven Pemberton
  • 10:00 Break
  • 10:30 Working session
  • 12:00 Lunch
  • 13:00 Report from working sessions
  • 15:00 Break
  • 15:30 Call to action: commitments for follow-up activities
  • 16:30-> Optional informal gatherings

Organizational information

Workshop chair: Steven Pemberton (CWI)
Program coordinator: Håkon Lie
Administrative coordinator: Josiane Roberts (Josiane.Roberts@inria.fr)

The workshop will take place at INRIA/Rocquencourt, close to Versailles outside Paris.

Unless otherwise arranged, workshop participants must book and pay their own travel and accomodation. Lunch, coffee and an informal dinner on Monday night will be covered by W3C.

The workshop is open for W3C member representatives (one per member), and researchers in the field can participate by invitation. There is no registeration fee. To register, please contact:

Josiane Roberts email: Josiane.Roberts@inria.fr phone: +33 1 39 63 51 02 fax:   +33 1 39 54 38 50  INRIA BP 105 Domaine de Voluceau Rocquencourt 78153 LE CHESNAY CEDEX FRANCE
howcome
APPENDIX III Use of Stylistic Hints or Suggestions - Typical Scenario -- (MUY TECHNICAL!!) -------------------------------------------------------- A renderer which understands the tag would use the URL to retrieve the stylesheet, and run it through the WWW style library, (libStyle.a -- to be supplied, currently in development.) Once the stylesheet has been loaded, when an HTML element is encountered within the document, the renderer has the option of calling the style library, asking for advice on how to render the specific element. For example: (scans all styles and renderer sets attributes) ***Renderer begins to scan document*** ***Renderer recognizes *** loadStyleSheet( {URL}); ***Renderer sees a tag in the document*** current = firstStyle( styles = queryStyleSheet( TITLE)); while( current) { switch( styleName( current)) { case FONT: { while( nextAttr( current)) { switch( attr) { case FAMILY: switch( attrValue(attr)) { case TIMES: ***Renderer decides what to do here*** case HELVETICA: case SYSTEM: case TYPEWRITER: default: } case SPACING: case SIZE: case WEIGHT: case SLANT: case FOREGROUND: case BACKGROUND: case LINE: case LONGNAME: default: } } break; } case JUSTIFY: break; case COLUMNS: break; case BREAK: break; case MARK: break; case VERTICAL: break; case INDENT: break; case LINK: break; default: ***Ignore -- Illegal style*** } current = nextStyle( styles); } Another example: (renderer sets attributes only for styles needed) ***Renderer begins to scan document*** ***Renderer recognizes *** loadStyleSheet( {URL}); ***Renderer sees a tag in the document*** switch( getValue(TITLE, FONT, FAMILY)) { *** renderer decides what to do here*** case UNKNOWN: case TIMES: case HELVETICA: case SYSTEM: case TYPEWRITER: } ***Renderer sees a <H1> tag in the document*** switch( getValue( H1, BREAK, STYLE)) { case UNKNOWN: case BEFORE: case AFTER: } <p class=center>Stylesheet Language Pei Y. Wei (wei@sting.berkeley.edu) Fri, 22 Oct 93 14:03:11 -0700 Messages sorted by: [ date ][ thread ][ subject ][ author ] Next message: Pei Y. Wei: "Stylesheet Language" Previous message: Alan Emtage: "Current documents" Hi. I'm working on a stylesheet library that will hopefully be useful for all W3 browsers. A prototype is implemented in viola, but before I get too far on this-- producing a more formal RFC and stand-alone library and testing code, I'd like to get people's impression on it. Particularly, any problem with the the syntax of the style description language? Here is a sample stylesheet: (HEAD,BODY fontSize=normal BGColor=white FGColor=black (H1 fontSize=largest BGColor=red FGColor=white) (H2 fontSize=large) (P) (A FGColor=red) (CMD,KBD,SCREEN,LISTING,EXAMPLE fontFamily=fixed) (BOLD,EMPH,STRONG fontWeight=bold) (I fontSlant=italic) (ADDRESS (P fontSlant=italic)) (OL (LI numStyle=roman (LI numStyle=number (LI numStyle=alpha) ) ) ) (FOOTNOTE fontSize=small (P) ) )<br> <div class=gallery>All, Could I suggest that rather that re-invent the wheel, we consider using an SGML DTD for specifying stylesheets. Below is Pei Wei's example reimplemented using an *existing* SGML DTD that was designed as a page description language. <outspec> <docdesc> <charlist> <font size="12pt" bckcol="white" fontcol="black"> </charlist> </docdesc> <e-i-c gi="h1"><font size="24pt" bckcol="red", fontcol="white"> </e-i-c> <e-i-c gi="h2"><font size="20pt" bckcol="red", fgcol="white"> </e-i-c> <e-i-c gi="a"><font fgcol="red"> </e-i-c> <e-i-c gi="cmd kbd screen listing example"><font style="monoser" _mce_style=""> </e-i-c> <e-i-c gi="bold emph strong"><font weight="bold"> </e-i-c> <e-i-c gi="i"><font posture="italic"> </e-i-c> <e-i-c gi="p" context="address"><font posture="italic"> </e-i-c> <e-i-c gi="li" context="ol"><counter style="romanlc" _mce_style=""> </e-i-c> <e-i-c gi="li" context="ol li ol"><counter style="alphalc" _mce_style=""> </e-i-c> <e-i-c gi="footnote"><font size="10pt"> </e-i-c> </outspec> (The e-i-c tag is element in context - I hope the rest are reasonably self evident). This compares to the example below in Pei Wei's original posting. (HEAD,BODY fontSize=normal BGColor=white FGColor=black (H1 fontSize=largest BGColor=red FGColor=white) (H2 fontSize=large) (P) (A FGColor=red) (CMD,KBD,SCREEN,LISTING,EXAMPLE fontFamily=fixed) (BOLD,EMPH,STRONG fontWeight=bold) (I fontSlant=italic) (ADDRESS (P fontSlant=italic)) (OL (LI numStyle=roman (LI numStyle=number (LI numStyle=alpha) ) ) ) (FOOTNOTE fontSize=small (P) ) ) There are several advantages to this - and several disadvantages. On the plus side: 1. It is SGML and so it can be validated with the tools some of us already use. 2. Once we have a public domain SGML editor, we can use that to write our stylesheet. 3. It is a standard already. The Formatting Output Specification Instance DTD is used as the page description language as part of the US Dod CALS initiative. 4. It is supported by several commercial SGML editors. 5. Given that it is a standard, implementations of tools supporting it may/will appear in the public domain. 6. As the requirements made of stylesheets expand (as they undoubtedly will) there is the framework already there to guide development. (The FOSI DTD has many features not demonstrated in the example above). 7. Why reinvent the wheel? On the minus side: 1. it is probably less easy to read. 2. it is therefore less easy to write without assistance. How about it? As something to mull over - *not* as a request to add these to the specification for style sheet as currently conceived, here are some of the other formatting attributes that the FOSI DTD includes: <presp> amount of space to render before element. | not currently handled <postsp> amount of space to render after element. | consistently by browsers <indent> left/right indent. <boxing> place box around element (I think Marc mentioned this). <textbrk> whether to break text at start/end of element, create new page etc. <quadding> left/right/center. And some more exotic options: <savetext> save copy of text. <usetext> place saved text in output stream. <enumerat> control the behaviour of element counters i.e. section numbers, list numbering etc. Steve. </html>

#1 Stylesheet Greatest CSShits (1994) PLUS More Historic Docs Posterous CAN'T ParseW3C Workshop on Style Sheets   I used the first stylesheet for this post, but then gave up  WHEN I REALIZED  POSTEROUS CAN NOT EVEN PARSE THE DECLARATION OF STYLE INDEPENDENCE from 1994 The W3C CSS Validation Service ...»See Ya
at