XP Mail Archive: RE: XP> Consideration of CSS selector suppo

RE: XP> Consideration of CSS selector support in CSS Print Profil e and recommendations for support

From: BIGELOW,JIM (HP-Boise,ex1) (jim.bigelow@hp.com)
Date: Thu Dec 19 2002 - 15:20:24 EST

  • Next message: BIGELOW,JIM (HP-Boise,ex1): "XP> December 19, 2002 versions of CSS Print Profile and XHTML-Print r eleased"

    Don,

    There is already one negative vote for the addition of attribute selectors
    from Michael Sweet, so what does that mean?

    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: don@lexmark.com [mailto:don@lexmark.com]
    > Sent: Thursday, December 19, 2002 11:54 AM
    > To: ElliottBradshaw@oaktech.com
    > Cc: BIGELOW,JIM (HP-Boise,ex1); xp@pwg.org
    > Subject: Re: XP> Consideration of CSS selector support in CSS
    > Print Profile and recommendations for support
    >
    >
    >
    > 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/selec
    tors/first_chi

    ld_selectors.html



    This archive was generated by hypermail 2b29 : Thu Dec 19 2002 - 15:20:43 EST