Well, that would seem to make sense to me.... if my understanding of the
charter is still accurate.
----------------------------------------------
Harry Lewis
IBM Printing Systems
----------------------------------------------
don@lexmark.com
12/19/2002 08:53 AM
To: Harry Lewis/Boulder/IBM@IBMUS
cc: "BIGELOW,JIM (HP-Boise,ex1)" <jim.bigelow@hp.com>,
xp@pwg.org
Subject: RE: XP> Consideration of CSS selector support in
CSS Print Profil e and recommendations for support
Would it make sense to add these for Enhanced mode only where we are
trying
to have more control?
**********************************************
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)
**********************************************
Harry Lewis <harryl@us.ibm.com>@pwg.org on 12/19/2002 10:01:36 AM
Sent by: owner-xp@pwg.org
To: "BIGELOW,JIM (HP-Boise,ex1)" <jim.bigelow@hp.com>
cc: xp@pwg.org
Subject: RE: XP> Consideration of CSS selector support in CSS Print
Profil e and recommendations for support
OK... I'll chime in. I may need a reset. I thought a major premise of
XHTML-P (per the charter) was "content is king". I recognize that the CSS
Print Profile emphasizes an enhanced mode which I thought was mainly aimed
at photo albums etc. It now sounds like we're getting into mandating more
and more "guaranteed" formatting. Where do we draw the line? Do the goals
of CSS-PP need to be restated (or have they?). How does CSS-PP stack up
against XSL:FO?
----------------------------------------------
Harry Lewis
IBM Printing Systems
----------------------------------------------
"BIGELOW,JIM (HP-Boise,ex1)" <jim.bigelow@hp.com>
Sent by: owner-xp@pwg.org
12/18/2002 03:38 PM
To: xp@pwg.org
cc:
Subject: RE: XP> Consideration of CSS selector support in
CSS Print Profil e and recommendations for support
Hi,
First, I want to clarify that I'm recommending only the addition of
E[Attr],
E[Attr=val], and adjacent selectors. If these are too much, my fall back
position is to only add E[Attr] since this is in the Bluetooth conformance
tests. However, I think we have a usefull set of features and that
authors
can produce useful and pleasingly formatted documents without these
selectors.
Secondly, I'm not well versed on PWG Process, is a simple majority
sufficient or should the vote for a new feature be unanimous and conducted
via email?
Jim Bigelow,
Editor: XHTML-Print & CSS Print Profile
IEEE, Printer Working Group
http://www.pwg.org/xhtml-print
Hewlett-Packard
208-396-2068
jim.bigelow@hp.com
> -----Original Message-----
> From: ElliottBradshaw@oaktech.com
> [mailto:ElliottBradshaw@oaktech.com]
> Sent: Wednesday, December 18, 2002 7:36 AM
> To: don@lexmark.com
> Cc: BIGELOW,JIM (HP-Boise,ex1); 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/selec
tors/first_chi
ld_selectors.html
(See attached file: C.htm)
#### C.htm has been removed from this note on December 19 2002 by Harry
Lewis
This archive was generated by hypermail 2b29 : Thu Dec 19 2002 - 11:28:23 EST