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

Re: XP> Consideration of CSS selector support in CSS Print Profile and recommendations for support

From: don@lexmark.com
Date: Wed Dec 18 2002 - 09:30:42 EST

  • Next message: ElliottBradshaw@oaktech.com: "Re: XP> Consideration of CSS selector support in CSS Print Profile and recommendations for support"

    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 : Wed Dec 18 2002 - 09:47:06 EST