If I had the answer for that I would have included them in my first e-mail
:>))
I don't know. Considering the number of people really working on this, I
would suggest something 10 positive votes if there are no negatives.
**********************************************
Don Wright don@lexmark.com
Member, IEEE SA Standards Board
PatCom Chair, SCC Liaison
Member, IEEE-ISTO Board of Directors
f.wright@ieee.org / f.wright@computer.org
Director, Alliances & Standards
Lexmark International
740 New Circle Rd
Lexington, Ky 40550
859-825-4808 (phone) 603-963-8352 (fax)
**********************************************
ElliottBradshaw@oaktech.com on 12/18/2002 10:36:13 AM
To: don@lexmark.com
cc: "BIGELOW,JIM (HP-Boise,ex1)" <jim.bigelow@hp.com>, owner-xp@pwg.org,
xp@pwg.org
Subject: Re: XP> Consideration of CSS selector support in CSS Print
Profile and recommendations for support
And, a voting deadline for each issue.
If we were to say that each issue requires N positive votes (one per
company, as Don says), what would the value of N be?
E.
------------------------------------------
Elliott Bradshaw
Director, Software Engineering
Oak Technology Imaging Group
781 638-7534
don@lexmark.co
m To: "BIGELOW,JIM
(HP-Boise,ex1)"
Sent by: <jim.bigelow@hp.com>
owner-xp@pwg.o cc: xp@pwg.org
rg Subject: Re: XP> Consideration
of CSS selector
support in CSS Print Profile
and recommendations
for support
12/18/2002
09:30 AM
Jim, et al:
While I suspect a "compelling" case can be made to incrementally add many
new features/functions/capabilities, I am concerned that continuing to do
this will forestall closure of the document. In order to stop this feature
creep, I think we need ACTIVE agreement from a significant number of the
participant companies (not 20 people from the same company) to stand up and
say "Let's add these." In other words, we assume silence equals
disagreement and require active participation to reach a consensus.
**********************************************
Don Wright don@lexmark.com
Member, IEEE SA Standards Board
PatCom Chair, SCC Liaison
Member, IEEE-ISTO Board of Directors
f.wright@ieee.org / f.wright@computer.org
Director, Alliances & Standards
Lexmark International
740 New Circle Rd
Lexington, Ky 40550
859-825-4808 (phone) 603-963-8352 (fax)
**********************************************
"BIGELOW,JIM (HP-Boise,ex1)" <jim.bigelow@hp.com>@pwg.org on 12/17/2002
12:49:48 PM
Sent by: owner-xp@pwg.org
To: xp@pwg.org
cc:
Subject: XP> Consideration of CSS selector support in CSS Print Profile
and re commendations for support
Hello,
The latest version of the CSS Print Profile
(http://www.pwg.org/xhtml-print/HTML-Version/CSS-Print.html) list all the
CSS selectors and indicates the ones that a conforming printer must
support.
I recommend adding attribute selectors, E[attr], and E[attr=val], and
adjacent selectors to the list that conforming printer must support. I
also
give an analysis of implementation costs of these and other selectors and
pseudo classes that are not currently required of conforming printer.
Selector with analysis
=======================
E:first-child
---------------
Implementing :first-child in a system using a SAX-style parser would
require
tracking which child, first, second, third, etc., an element is with
respect
to its parent element. Memory requirements, at a minimum, would be a
single
variable. Processing requirements would be incrementing and resetting a
counter, as well as, checking its value. See the end of this message for a
use case for this selector.
:link, :visited, :active,:hover,:focus
---------------------------------------
The printed page is not a browser so none of these selectors are applicable
with the possible exception of :link.
:lang(c)
---------
A conforming printer is not required to support language specific
processing, so no support is required.
E + F
------
Implementing adjacent siblings in a SAX style parser requires keeping
element context. A minimal implementation could use a single variable,
previous_element. The current element and previous_element would be used
when checking adjacent sibling selectors. The processing and memory
required doesn't seem prohibitive.
Use case/rationale:
The rationale for this feature is to add allow addition style beyond the
automatic style such as collapsing vertical margins to adjacent elements. A
designer could also adjust styles so that adjacent presentation elements
blend well in the page's layout.
E[foo]
---------
This is the simplest kind of attribute selector, and is a generalization of
the class and id selectors. No more printer resources are required for
attribute selectors than for class and id selectors. The printer must have
already processed and currently be ready to act on an element's attributes,
as well as, be maintaining a css document tree (a stack at a minimum) to
look up the properties that apply when processing this selector. Adding a
search by attribute shouldn't add a significant burden on printer memory
and
only a slight increase on code size and complexity.
Use case/rationale:
This would allow style rules based on attribute. For example, style rules
could be applied to option elements that are selected or have a value. This
eases the burden on the document authoring application that would otherwise
have to the class attribute.
E[attr=val], E[attr~=val],
----------------------------------------------------
These attribute selectors allow for selection based on the value of the
attribute. No more storage is required than for the simplest attribute
selector, however, more processing would be required to check the value.
Use case/rationale:
This would allow application of properties is situation such as specific
set
of properties for when xml:space is set to preserve. Another possibility is
text-indent could only be applied when the align attribute is set to
"left".
Also different style could be applied to the content of the input element
based on its type: radio, checked, text, etc.. All these would be
difficult
to do with only the classid selector.
E[lang|="en"]
--------------
Since language specific processing is not required, neither would support
for this selector.
:first-line
------------
Implementing :first-line would require a printer to adjust the styles of
the
first line box in the relevant element. Memory would have to be allocated
to
track line boxes and know which one is the first. Extra processing would
occur for each element containing line boxes to check if the style
information must be updated for the first line box.
Use case/rationale
The rationale for this feature is to add allow addition style beyond the
automatic style such as collapsing vertical margins to adjacent elements.
The first line of a paragraph or div could be set off from the remainder of
the content.
:first-letter
--------------
Implementing :first-letter would involve removing the first character from
the first line box (resources would have to be used to determine the first
character of the first line box). In place of the first character, the
printer would have to create a construct with a width and height from style
properties and containing the character. The construct would be in the
normal flow but the remainder of the content would have to flow around it
since it may be taller than a single line and wider than a single
character.
Use case/rationale
The feature can be used to create a "drop cap"
(http://www.w3.org/TR/REC-CSS2/selector.html#first-letter) that is where
the
first letter is enlarged and set into the paragraph.
:before, :after
----------------
These constructs require the construction of content boxes within the
normal
flow of the document, as opposed to the box for list item numbers or
bullets
which are positioned relative to the li's containing box. Resources
similar
but more general than those of list-item numbering boxes are required.
This
would not cause the movement of previously placed content boxes.
Use case/rationale
This feature would allow the automatic insertion of text.
:left, :right
-------------
These pseudo-classes were explicitly left out of the 0.95 version of the
XHTML-Print specification since :first is mentioned on page 20, but not
:left and :right.
Jim Bigelow, Editor
Hewlett-Packard
208-396-2068
jim.bigelow@hp.com
Use case for :first-child
==========================
"Think of the following scenario. We have each chapter of a book as a web
page. Where the chapter is divided into sections, we have created a div.
Within these divs we have the content of our chapter in paragraphs.
Commonly, the first paragraph of a section appears differently from the
remainder of the paragraphs of the section. With CSS1, we could add a
special class, say first-paragraph and mark up each of the first paragraphs
in the HTML using this class. With CSS2, we can use first child selectors
to
save us the trouble. This also means if the chapter is later edited, to
remove certain paragraphs, or rearrange their order, we needn't re-edit the
source of the HTML. Further, by marking up each first paragraph as being of
class first-paragraph, we are subtly introducing appearance into our HTML,
which as we have seen is to be avoided." From
http://www.westciv.com/style_master/academy/css_tutorial/selectors/first_chi
ld_selectors.html
This archive was generated by hypermail 2b29 : Thu Dec 19 2002 - 15:10:55 EST