C-0001.htm

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 ---------------------------------------------- <table width=100%> <tr valign=top> <td> <td>"BIGELOW,JIM (HP-Boise,ex1)" <jim.bigelow@hp.com> Sent by: owner-xp@pwg.org 12/18/2002 03:38 PM <td>                To:        xp@pwg.org         cc:                 Subject:        RE: XP> Consideration of CSS selector support in CSS Print Profil        e  and recommendations for support        </table> <tt>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 </tt>