Jim:
Since we are still in the Working Group stage for these documents, the goal
is consensus as determined by the Chair. If all else fails then a vote
could be called. I just want to make sure we don't simply assume those
that never speak up always are in agreement with a proposal.
**********************************************
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/18/2002
05:38:39 PM
Sent by: owner-xp@pwg.org
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
This archive was generated by hypermail 2b29 : Thu Dec 19 2002 - 08:22:09 EST