W3C home > Mailing lists > Public > www-style@w3.org > April 2008

[CSSWG] Minutes F2F 2008-03-28

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 02 Apr 2008 12:30:38 -0700
Message-ID: <47F3DEDE.6040507@inkedblade.net>
To: www-style@w3.org

Meeting: CSS Working Group Face-to-Face Meeting, San Diego, CA
   David Baron
   Bert Bos
   Tantek Çelik
   Arron Eicholz
   Elika Etemad
   Ming Gao
   Daniel Glazman
   Molly Holzschlag
   Chris Lilley
   Peter Linss
   Jason Cranford-Teague
   Anne van Kesteren
   Steve Zilles

<RRSAgent> logging to http://www.w3.org/2008/03/28-css-irc

ScribeNick: SteveZ


   <anne> http://dev.w3.org/csswg/cssom-view/
   AVK: the introduction needs to be edited
   AVK: most of the comments have been replied to
   AVK: there are no examples in the spec
   AVK: there are tests (not exactly a test suite)
   CL: put a section in the spec that links to a W3C CSS test page which will
       link to the test
   ACTION: Anne put link to CSS test page in the document
   AVK: most of the attributes come from Internet Explorer, but the spec does
        not mimic them exactly, instead it is a union of what the browsers do
   CL: this statement should be in the document
   DG: strongly suggests that the spec document whether or not the width of
       the scroll is taken into account in the computations
   CL: should have an example, screen shot from some browser, that shows the
        handling of scroll bars
   AVK: two new things, the media type and a way to find whether a media type
        applies to the current view
   AVK: was a proposal to extend the ClientRect interface with an explicit
        height and width (not implemented by anyone yet)
   AVK: these values can be computed using top and bottom and left and right
   EE: these seem useful and simple to implement. Why not put them in and
       mark them "at risk".
   AVK: most of the changes suggested are editorial so we should be able to
        go to last call after these edits are made
   RESOLVED: take the CSSOM spec to last call after the edits are made
  * Bert sees some very old resolutions on


   <anne> My draft: http://dev.w3.org/csswg/cssom/
   DG: Since 1998-9 where has been a view that the CSS object model is badly
       designed, but an effort to fix it went nowhere
   DG: usage of some of the facilities, esp get computed style
   DG: should we improve the model, to make it more useful
   AVK: we should clarify the existing model before extending it; I am
        working on the clarification
   AVK: doing CSS animations would likely solve many of the use cases for an
        extended Object Model
   AVK: we should wait and see what is left to do after CSS animation is done
   <chris> http://www.w3.org/TR/SVG/svgdom.html#RelationShipWithCSSOM
   PL: should we require every module to identify the extensions to the CSS
       Object model that come from that module
   <anne> http://dev.w3.org/csswg/cssom/#history
   CL: I would like to ask that other specs that use the CSS Object Model be
       considered in any changes to the spec
   AVK: I have attempted to be clear about what is happening to the spec and
        notify relevant people. There is a complete change history in the spec
   EE: can we action AVK to create a list of what needs to be defined for new
       properties added in other modules
   <chris> Please review the spec section I linked to above to see what impact
           that will have on implementations that did the existing CSSOM
   AVK: I do not plan to introduce new interfaces so you would only need to
        define the string representation (canonicalize) for the property values
   AVK: this "text" interface can also be used to set values, but it is not
        clear what parsing rules need to apply in this case
   BB: putting the canonicalization information into CSS is adding information
       that is only required for a non-DOM implementation of CSS.
   <Bert> The canonicalization info is required for the DOM, it should be in
          the DOM spec. It's not required for implementing CSS, it should not
          be in the CSS spec.
   Elika: It's intrinsic to the property.
   <chris> I agree that its intrinsic to the property
   Many: that the canonicalization information is part of the property
         definition and, therefore, is best put with the property in the
         CSS specification.
   Strawpoll: Should the canonicalization information be put in the
              specification for non-CR modules
   Strawpoll: 10 yes, 1 no
   BB: I am strongly opposed to adding this information in the CSS spec
   DB: is there a document that shows what has been done w.r.t. canonicalization
       for existing properties. This information would help drive future
   ACTION: Anne develop a list of the existing canonicalizations
   <dbaron> and just that at least the part for existing properties ought
            to be reviewed as a coherent whole rather than reviewed (or,
            more likely, not noticed) during the review of each module.
   ACTION: Anne e-mail the group with information on how to create and document
           the Object Model part of a module
ScribeNick: chris
   BB: What to do with comments in the CSSOM?
   DG: We allow comments everywhere in CSS, even between tokens, so extremely
       hard to preserve them
   ... only if we restricted comments to occur between rules would it be
   AVK: All comments dropped during parsing
   DG: Big issue for editors, need to preserve rules and comments not understood
   AVK: Editors need a specialised CSS OM
   ... but no need to standardise it, browsers will not expose it
   CL: if you "content editiable" how is that handled
   CL: If you have editable text and the editing is ricjh, so has editable
        styling, it might be relevant to a browser ...
   BB: Want to use this for pretty printing etc and preserve all comments and
   DG: How to rrepresent a comment between two values?
   SZ: Agree an editor needs this but a presenter does not and the burden on
       implementation is much harder
   PL: If the browser throws all comments but an editor preserves them, a
       script may run in a browser and fail in an editor
   DG: Online editors use browsers and are increasingly common
   SZ: The interface that gives you comments can be different
   AVK: Not relevant to The Web
   DG: Inserting comments has to be text based, not object based
   AVK: Still doesnt help if you also drop declarations
   CL: in the regular DOM people oftern want to run a pass that eliminates
       spaces because they are irrelevant to most processes
   AVK: Would break existing stuff if we no longer preserve rules not understood
   PL: Normal interface would skip, but if preserved then it could be
   AVK: 80% case is scripts in browsers, editor case is not relevant and is
        the 2% case
   ... editor needs a complete new model
   PL: This is more for a future editor model, do we need one
   SZ: DG said a standard one would be good, so what is the reason for one?
       Are editor scripts needed to be cross-implementation?
   <Bert> (I could use a CSSOM to replace, e.g., -moz-opacity by opacity in
          all rules.)
   AVK: Those are mosyly not dom based, they are textarea based
   DG: No, increasingly they are DOM based and this is improving
   DG: CSS OM released in 98, saw first uses only 4 years ago
   SZ: This is a new (potential) module and not something to add to the existing
       one, so it needs an advocate
   PL: Any advocate?
   DG: (... pause ..... ) YES
   RESOLVED: Daniel is the advocate for a CSS DOM Editing Module

CSS Namespaces

   ScribeNick: SteveZ
   <fantasai> http://dev.w3.org/csswg/css3-namespace/issues-2
   DG: the XHTML2 WG issued a formal objection:
   DG: can we have the exact date that their comment was rejected and the
   EE: it was raised formally on 27 March, 2008
   EE: the rejection was sent by Anne on 13 March, 2008
   <chris> DG: Its up to the WG not the editor to decide formal objections
   DG: the WG did not formally consider this rejection, therefore it was not
       formally rejected.
   AVK and EE: the editors sent the response with the rationale based on
               their best judgement
   DB: it is reasonable that the editors issue a reply and not bring it to
       the WG unless the commenter stays unhappy
   DG: using "we" means that the commentor could not tell whether it was the
       editor or the WG had taken the action
   <chris> The rejection was here, by fantasai
   CL: in addition, saying in the reply, the if the commentor was unsatisfied
       they should raise a formal objection before the WG had reviewed the
       comment was not the right step
   <chris> The original comment seemed reasonable to me; the arguments against
           also seem well argued. I don't see that this needed to go to a
           formal objection; there was resoned discussion on both sides
   <chris> Fantasai summed it up well:
   <chris> ======== quote ===
   <chris> Nobody is forcing authors to declare a default namespace. They can rely
   <chris> on prefixes only. But they also have the option of declaring a default
   <chris> namespace. This allows the author to choose whether backwards-compatibility
   <chris> would be better served by hiding the rules or letting them fall back to
   <chris> more generous matching.
   <chris> ===== end quote =======
   <dbaron> I'm tired of one or two people in a WG who are interested in
            another WG's spec to use the authority of the WG they're in
            to raise the level of the conflict (as in so many comments
            from some people being "this is the XHTML2 WG's comment" when
            it's really just one person in that WG who has an opinion on
            the spec), and thus turning it into a WG coordination issue
   CL: note that having the editors "reject" a comment is the same thing
       as having a subset of the WG speaking with authority of the WG
   EE: I was under the impression that asking for a formal objection was
       the correct next step in the discussion of this comment.
   * Bert wonders if we should take a break before discussing the content
          of the comment
   DG and PL: But, the affect of taking this step is to take the resolution
              of the issue out of the hands of the WG (before the WG has
              officially considered it) and putting it in the hands of the
   TC: The process that has been followed is the editor replies to the
       commentor and asks if the commentor is satisfied. If the commentor
       is not satisfied, then they should reply to the editor and these
       comments are then reviewed by the WG
   <chris> It is possible to add more discussion and then ask for the formal
           objection to be withdrawn
   DG: please do not use "we reject"  unless it is the action of the WG.
       It is the use of "we" that is ambiguous. It is also the case that
       "reject" should not be used because it is a word that has a formal
        meaning in the W3C.
   DG: Use "I disagree" instead.
   PL: It is not likely the case that the WG disagrees with your conclusions
       nor your rationale, it is simply that the WG did not have the
       opportunity to make that assessment prior to requesting a formal
   DG: do not "request a formal objection" unless that action is taken by
       the WG.
   Break till 11:00

   Topic: Technical discussion of the Namespace comment from
   Action: chris propose a response to the XHTML2 WG comment on namespaces
            based on the e-mail log on this issue
   DG: I hope that continuing the discussion with the XHTML2 WG will help
       them withdraw their formal objection and hopefully resolve the open
   DB: it seems that the comment might be satisfied by a note which gives
       guidance to authors on how to use the facility
   CL: the next step is to develop a note for the spec that would resolve
       their issue.
   SZ: it is up to the commentor to decide if the comment was satisfactorily

   Topic: Test Suite for Namespaces
   EE and AVK: there are tests
   AVK: there is agreement on the spec, but there are some areas where
        implementatons need to be brought up the spec
   AVK: these are whether you can declare the empty string to be the default
        namespace and the handling of case sensitivity
   AVK: otherwise the existing implementations do the spec and would support
        a positive implementation report
   <chris> It would be useful to collect that implementation experience in a
           draft implementation report

Status of CSS2.1 Test Suite

   AE: Microsoft released 700 tests and there is a need for help in reviewing
       these tests; note that more are coming
   DB: what is the process for re-releasing test that have recieved comments?
   AE: that is still under discussion
   AE: areas were there are issues are: background positions, language
       selector, EM and EX calculations
   AE: will probably release additional tests with each IE8 beta release.
   EE: HP is contributing tests on the Paged Media module; EE is reviewing
      these and they will be posted when that review is completed
   EE: Ming has another Team working on the test suite, esp. the harness.
       It is an extension of the Mobile Web Initiative's harness that will
       interfere less with the tests and give better implementation reports
   EE: Main issue is the test suite licensing; we need to agree on that. EE
       wants to change the test suite license or post a second copy under
       the BSD license.
   BB: I want it to be clear what the W3C test suite is. I would like the
       license to say that a user cannot change the test and make any
       claims for compliance
   Many: It is not necessary to say anything in the test itself. it suffices
         to say in the document where the official test suite is and that
         the tests at that location have the W3C document license
   EE: Any extra licensing requirements on the "open" tests would only help
       protect against claims based on derived tests; it would not help with
       claims based on newly contributed tests
   <fantasai> http://www.opensource.org/licenses/bsd-license.php
   <fantasai> "Neither the name of the <ORGANIZATION> nor the names of its
               contributors may be used to endorse or promote products
               derived from this software without specific prior written
   TC: it is the community exposure and process that will protect against
       such claims.
   * glazou Pierre Saslawsky (former WG member on behalf of Netscape) waves
            at everyone in the WG
   EE: I am willing to do the work needed to implement a double posting of
       tests, one under W3C Document License and one under BSD 3-clause
   CL and SZ: asking the lawyers to change the licensing requirements
              introduces a long delay in getting tests posted
   Resolved: the intent of the WG to post two copies of the test suite, one
             with the W3C license and one with the BSD 3 clause license;
             the copy with the W3C license is the W3C CSS test suite.
   * chris waves back at Pierre
   ACTION: Elika update contribution guidelines to require agreement to
           BSD 3-clause
   ACTION: Elika update scripts to generate BSD and non-BSD copies of test
   ACTION: Elika update test suite documentation to reflect licensing
   <tantek> please consider all my contributions to the CSS working group
            as an invited expert to be placed into the public domain. This
            includes any test cases, examples, and text submitted for
            working drafts or other working group documents.
   <tantek> public domain per http://creativecommons.org/licenses/publicdomain/
   DB and AVK: Provided the above policy on test case goes into implementation,
               Mozilla and Opera will submit test cases to the test suite.
   <dbaron> but most of our current tests aren't in the CSS test suite format,
            so it will be a gradual process

CSS3 Color Module

   CL: the current conformance requirements on color profiles mean that an
       implementation can conform doing almost nothing.
   CL: at the moment the only requirement for color profiles is that the be
       parsed; this makes testing difficult
   <dbaron> http://csswg.inkedblade.net/spec/css3-color
   CL: I don't object to dropping this feature
   <dbaron> http://lists.w3.org/Archives/Public/www-style/2008Mar/0304.html
   AVK: currently, color profiles are not implemented in CSS; the current
        plan is to drop the color profile feature for Lv3 and add it back
        in Lv4
   CL: this is an OK plan
   DB: I have reiviewed all the messages that I could find concerning CSS3
       Color; there are 24 issues
   DB: 2 of these were to remove features that have not evidenced 2
       implementaitions: these features are: color profile property, the
       rendering intent property, the @color-profile #rule and the flavor value
   DB: there are a number of editorial issues; the editor will handle these
   DB: there are a bunch of comments that I propose to reject; these are
       primarily ones adding features to the spec.
   DB: The answer should be that the suggestion is reasonalble, but the
       document has been in CR and we want to progress it. Such suggestion
       will be considered in the next version.

   DB: summarizing issue 2; remove the ATTR fcn to remove dependendcy on
       Values level 3

   DB: Issue 5: clarifying the defintion on 3D borders

   DB: Issue 4; the most complex issue
   <Bert> http://www.w3.org/Style/Group/css2-src/syndata.html#color-units
   DB: in RGB space, values outside the device gamut are clamped to the
       border of the gamut on a component by component basis (this does
       not, of course, work)
   CL: can i see the wording
   DB: "the red, green and blue values must be changed to lie within the gamut"
   DB: there are examples that imply a component by component by comoponent clip
   <chris> system-color test

   SZ: we can add an explicit provision that "this specification does not
       define how the adjustment is made  to get a within gamut value'
   DB: has done an update to specify the HSL clipping to attempt to preserve
       the Hue
   <chris> I agree with these changes for HSL processing
   DB: another issue is that we have not defined the clamping for the "A"
       versions of RGB and HSL
   DB: the proposed solution is that clamping of the color gamut occur
       before the compositing occurs
   CL: compositing has a lot of implementation outside of CSS and I would
       like to see what those do before making a decision on this part of
       the spec
   ACTION: Bert ask Chris L to gather the information on compositing clamping
           are report that back to the WG.
   <chris> http://www.w3.org/TR/SVG/masking.html#SimpleAlphaBlending
   <chris> 14.2 Simple alpha compositing

   DB: Issue 9 site section 14.2 of SVG 1.1 for definition of what opacity
   DB: Issue 16, people have argued that "system colors" should not be
   CL: Deprecated means that new content shouldn't use the feature, and
       implementations need to support the feature.
   CL: 'deprecated" means that new content should not use the feature and,
        because old content may have the feature new implementation must
       implemented it.
   TC: this was already resolved in the existing disposition of comments;
       no new information has been raised. this existing rejection is

   DB: Issue 17, current color works like EM and font-size
   <chris> what is the computed value for color: currentColor ?
   DB: the computed value should be color; when this happens is not so clear
   <chris> dbaron: the computed (ie actual) actual color (of the parent)
   DB: we should remove "at parse time" from the current description
   No objections were raised

   DB: Issue 20 this is my issue which I have rejected

   Issue 22 which requests a more formal grammer for something that is not
     clear; resolution please propose text if you want me to make a change
   <anne> bjoern, ^^
   * bjoern looks up
   * bjoern gave up on that and did most things manually as needed
   * bjoern ... but do fix the <name> error please
   <dbaron> bjoern, the <name> thing is a dropped feature -- no longer in the spec
   <dbaron> is in a dropped feature
   <bjoern> excellent
   <Bert> http://csswg.inkedblade.net/spec/css3-color#issue-22
   PL: as a matter of process we cannot always expect that a commentor
       can provide :"proposed text" so we should ask for clarification and
       if it can be provided proposed text
   AVK: Bjoern is a member of the WG

   DB: given Anne's new issues (25 and 26) the draft is not quite ready for
       last call
   DB: once I have test for the new issues I will also publish a new test suite
   <chris> http://www.w3.org/TR/SVGPrint12/#named
   DB: I think Firefox 3 passes all the test currently in the test suite
   This topic is closed
   LUNCH till 1:30
   <anne> http://dev.w3.org/CSS/css3-color-test-suite/src/

Tree List Styles

ScribeNick: molly
   <glazou> http://www.terrainformatica.com/htmlayout/images/tree-view-lines.png
   <plinss> http://lists.w3.org/Archives/Public/www-style/2008Feb/0220.html
   Daniel: Issues: rendering or behavioral, I don't know where the limit is in
           this proposal
   <Bert> Earlier similar proposal: http://www.w3.org/Style/Group/WD-CSS-future.html#tree-style
   Daniel: If it doesn't do the folding/unfolding it does fit under rendering
   Daniel: It solves something that authors implement
   Daniel: Proposal is okay based on rendering rather than behavior
   Daniel: will help a lot of web designers
   SteveZ: what does just rendering mean in your sentence?
   Daniel: Purely stylistic
   David: Two concerns here. One: This is one of those areas where authors
          are going to be somewhat picky visually about results
   David: And I'm not sure if we have a proposal that's going to satisfy
          90% that it's useful - hard for me to tell whether this is useful
          to many or few
   David: The problem is that there's a bunch of different cases within trees;
          node; child; visually the last child looks different - some of those
          things seem like they'd be better addressed using selectors with
          multiple types
   Daniel: I see your point, but I think the intent is to get rid of
          selectors, one value for tree
   David: Can we write rules for how the equivalent of those selectors would
   Daniel: The problem is ensuring pixel precise, drawing the line
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2008Feb/0236.html
   David: I should respond to the proposal on list
   Fantasai: Authors want to control design of lines - color, width, etc.
   Fantasai: without that control, we can't solve 80% .. more like 10%
   Peter: Proposal suggested using outline
   Daniel: Agree with David if we solve 80% of cases
   Arron: I think the color issue is probably easy to address if we support
          the marker pseudo element
   Daniel (at whiteboard): Can markers span? How can you make sure it acquires
                           exactly the height of the element
   <Bert> Some things that need to be specified: What parts of the style do
          authors want to control? color? more? What happens with
          'list-style-position: inside'. Anything automaticly drawn for nested
          lists with the same style?
   Anne: Think this out and write a proposal?
   Daniel: We have to see the interest
   Bert: Some brainstorming
   SteveZ: The way you solve the element with margin and treeline, three
           cases - same as shaping in Arabic. Initial, final, medial
   The medial treeline is one that goes from the top to the bottom of that
   element /including/ any margins
   Peter: Instead of it being part of the market that's part of the list
          item make it belong to the list
   Daniel: you should be able to combine tree-line and a bullet
   Bert: We don't have an object for the list at the moment in CSS
   Daniel: "display: tree" or whatever the name will be
   Molly: Seems to me, what authors would really like..
   Molly: Steve says there are these initial, middle, and final pieces of
          the tree
   Molly: If you gave authors control over what these look like, that should
          give authors enough control
   <Bert> We call it a tree, but it's actually a sequence. It has a first
          element, but not a root.
   SteveZ: the marker is the horizontal piece and the line is what connects
           them - the line goes from the top of the list - that defines the
   Daniel: That's good
   SteveZ: that gives us places to put all the color and so forth
   Fantasai: No because if the parent has its own marker, you need something
             other than :: marker.
   <Bert> (Steve gives a model in which there are two pieces: the parent's
          piece is the verticla bar, the childrens' piece is a symbol that is
          connected to that bar.)
   ACTION: Daniel to contact Andrew regarding his company joining group
   ACTION: Daniel report back to Andrew re: tree proposal

Multi-style Elements (aka Collapsible Elements)

   Daniel: This was commented on
   Bert: Collapsing is what's mentioned, but I think that's not the right
         concept. It's an element with two styles
   Bert: Like XSL fewer/more
   Bert: My idea was to have either one or two pseudo classes - normal and
   Daniel: How will this be linked to the document tree
   Anne: The user agent will provide the UI to toggle between element styles
   <fantasai> Elika, Daniel: Need to define a toggleable element
   Bert's proposal is that simply defining the different styles makes the
     element toggleable
   Peter: Merely offering an alternative style doesn't make it toggleable
   Peter: That behavior should not be defined by CSS
   SteveZ: I'm arguing that you have two presentations and you toggle between
          the two - this is within the scope of CSS
   SteveZ: it seems reasonable that if you have alternative presentations
           that makes those elements styles accessible in some way
   Peter: I don't have a problem with a property or display type to change
          to toggleable: The presence of a pseudo classes in a selector
          should not give me the ability to toggle
   :hoverability :)
   propose :toggleability pseudo class
   * chris agenda+ to ask how many angels can dance on the head of a pin
   <anne> hmm, :toggle
   <fantasai> This sounds related to Presentation Levels
   <anne> anyway, I think it would make sense to move on
   Bert: Do we need two states or any?
   <anne> there's no concrete proposal here
   Peter: All elements have n states
   Bert: I didn't propose that because the syntax becomes ugly
   <glazou> http://lists.w3.org/Archives/Public/www-style/2008Feb/0247.html
   Chris: So you're saying :hover sets a precedence
   Peter: :hover is a clearly defined state, toggled is not
   Anne: :hover isn't either, in mobile devices
   Peter: Daniel talked about extensible pseudo classes
   <chris> hover is very clearly defined in mobile decices. Unless there
           is a pointer device, nothing *can* be hovered; but its very
           clearly defined

Scriptable Selectors

   Daniel: It's an old dream / I know that Bert is going to scream
   Daniel: Needs for extension in selectors. script+extending the set of
           pseudo classes for a specific web site only
   Daniel: The performance could be terrible, but that's the web site's
   Daniel: Not saying it's the best, but could be useful
   Anne: How's this better than manipulating classes?
   Bert: If you have a script already, why don't you manipulate the
         variable in the script
   Pete: the idea is that it would be outside the DOM
   Bert: What does this have to do with CSS
   <chris> so you avoid triggering mutation events. plus point for doing
           it outside the document tree
   Fantasai: I don't want to execute any functions
   <glazou> I suggest :hasUserData(key)
   <glazou> or an equiv
ScribeNick: fantasai
   Molly: I'm not following this discussion. I think that says something
          about how useful it would be to authors
   <anne> (you could've setState(state, boolean) ...)
   David: Getting a property in JS executes getters
   <anne> (and :matches-state(state) { } )
   Steve: Daniel is asking for scriptable selectors.
   <glazou> yes
   <anne> (but this can be done using classes pretty easily)
   Steve: The issue of a selector for a node is, "does this selector apply
          to this node"
   Steve: The idea is that you determine this with a function that takes
          a node and returns true or false
   Molly: If this were implemented, we're basically putting in CSS hooks
          for JS to be able to manipulate..
   David: Allowing JavaScript to manipulate the DOM tree while you're
          matching selectors is very scary
   David: As in "this feature probably won't get past security review" scary
   <Bert> I'd rather not have machine-readable definitions of extensions,
          unless those definitions are in a declarative language.
  * Bert sees a great semantic Web project, to quote another 'bot
   <chris> doing this with classes thrashes the DOM. Better to hold that
           state outside the DOM

Multi-State Elements

   Going back to multi-state
   Bert volunteers to advocate that
   Steve: part of the issue seems to be how this releates to the UA
   Steve: how does toggle get determined?
   <Bert> A first write-up:
   ACTION: Bert update proposal


Web Fonts

   Anne: I'd like it to be in scope for the next charter. That's all.
   Anne: Advocate was Jason, secondary is me.
   Anne: The proposal is to remove all features except those implemented
         by WebKit and Opera
   Chris: SVG's editor now has some time, should be able to work on it some
   Chris: So I'm putting together a spec
   Chris: IPR issues will need to be resolved before this becomes a workable
          solution, but that doesn't go in the spec
   Peter: So should that be in our charter or stay in SVG's?
   Chris: We'd want review from this group before last call
   Steve: Could list as a joint project with SVG
   Anne finds this acceptable
   Anne: I'm not opposed to them owning it
   Chris: Most implementations use the XML syntax, not CSS syntax
   Chris: All the font synthesis and font emulation stuff is being dropped
   RESOLVED: Add web fonts to charter as coordinated effort with SVG group
   <chris> Would certainly like early review by this group


   Daniel: Main use case is colors..
   Daniel: Don't want to repeat values over and over in style sheet
   Daniel: Has been constant request from web designers since 1997
   <chris> <!ENTITY myteal "#307F5C " >
   Daniel: I'm not saying we have to do it, but we should give a reply.
           Either we do it, or we don't do it because
   <chris> oh -whoops, no xml syntax
   David: I know there have been a lot of requests for it
   David: What I've tried to extract the use cases, and at which points
          in the style sheets does that require constants to be allowed
   David: That has a lot of effect on how hard it is to implement
   David: It could be that the ones people care about are all easy t
   Elika explains that if we want to do this, we should do it for values,
         for property declaration lists, and for selectors
   Elika: These are requests coming in from the WaSP feedback
   Elika: They term them differently, with ideas of "explicit inheritance"
          and stuff like that.. but it seems what they're trying to solve
          would all be solved by macros for these three things
   Daniel: Importing a style sheet of constants would replace system
           colors, would allow site-wide corporate colors to be used
   Chris: Use case is replacing search and replace where you don't want
         to replace, e.g. all instances of 'black'
   Steve: Sounds like &substitution; in XML, and the only warning I'd give is
   Steve: They removed that in XML.
   Chris: No they didn't
   Daniel: XMLization of CSS is not on the radar.
   Chris: You could do it inside the <style> element
   <anne> (I think at this point we need use cases/problem statements and
   Peter: You could do it in PHP
   <chris> in an xhtml document for example
   <anne> (Which are probably better dealt with on the list)
   Daniel: I think authors want the substitution on the client side
   Elika reads some comments from webstandards.org
  * Bert looks at all CSS files on his system: the longest is 4K lines and
         was generated by Framemaker. None of the hand-written ones are
         more than a few hundred lines.
   Elika: I think being able to have macros for values, sequences of
          declarations, and selectors would solve 90%+ of the use cases
   Elika: It would be expanded and then parsed
   Elika: Although I'd keep it well-formed, restricted to a parseable
          value, a parseable sequence of declarations, a parseable selector
   Daniel: I think we should have variables, that can be impacted by scripting
   Daniel writes:
     @var foo white;
     p {background-color: var(foo)}
   Anne: Note that it's different from namespaces because namespaces are
         local to the file.
   <anne> s/the file/the style sheet/
   <anne> (there could actually be multiple style sheets in the same file)
   Chris: You should be able to import them, but they shouldn't cross style
          sheet boundaries otherwise
   * Bert thinks we can write the generic W3C macro language, to be
          applicable to all W3C languages, not just CSS.
   Elika explains that CSS doesn't have a concept of step-by-step process,
         that the content of the style sheet and the content and the DOM
         and the rendered result must always be in sync even as the style
         sheet and the DOM change
   Elika: So whether we call it macros or variables or whatever, if you
           update the statements that declare them in the style sheet the
           update would apply to the entire document
   Daniel, David: We need more detailed use cases.
   Elika: If you put out an open call for use cases, you will get hardly
          any. We've done that so many times before
   Elika: We get syntax proposals, hardly any detailed use cases.
   Steve: Post a simple straw man proposal and ask "does this solve your
          use case, and if not, why not?"
   ACTION: Daniel post straw man proposal of constants and ask web
           designers "does this solve your use case, and if not, why not?"
   ACTION: Elika post Daniel's post to css3.info
   <fantasai> glazou, I would suggest looking at
              http://csswg.inkedblade.net/ideas/constants as well
   <fantasai> glazou, and
   <glazou> fantasai: thx for links

text-orientation vs glyph-rotation

   Steve writes
   england [zhong][guo] LEARSI
   --->        --->      <---
   Steve: If I rotate this right, I get *draws sideways version of the above*
   (the chinese glyphs are sideways too)
   <dbaron> england 中国 LEARSI
   Steve: The next step is that for the characters that are traditionally
          upright, I put them in upright form
   Steve: This is at least semi-readable
   * anne wonders if that was a joke
   Steve: In glyph-orientation this is the default mode
   Steve: It rotates right all the character, then rotate left the fullwidth
          characters to make them upright
          and the ordering is in this order
   Steve:  If I apply 180deg glyph orientation to these pieces, then the glyphs
           rotate individually
   and that makes the characters are effectively ordered in reverse
   Steve draws something that is "unreadable"
   <dbaron> "england 中国 יִשְרָאֵל"
   Steve: The essence of why we're doing this is that you want to spin runs,
          not rotate individual glyphs
   Steve: We're introducing a new property called text-orientation, which
          operates on runs
   Steve: If its value is normal, then you do the default order
   Steve: and if you support glyph-orientation, you do whatever SVG says
   Steve: It has a hang-down value that orders characters in storage order
          and rotates them to handle RTL vs LTR
   Steve: And it has an 'upright' value that keeps each syllabic unit upright
   Steve: We're not sure if required ligatures are kept or split in this
          case.. so there are some details not worked out
   Steve: all values are keywords
   <anne> (If we have some time left after this semi-understandable topic can
          we maybe get back to Media Queries for a few minutes?)
   Steve: in the 80/20 rule, we've left rotate-left as a partially solve
   Almost all uses of vertical text are rotate-right or upright

Changing the Subject of the Selector

   Daniel: This was proposed many years ago, and implemented in my batch
   Daniel: There have been many requests over the years to select not
           just descendants, but also ancestors and previous elements
   Elika: One major use case is links that have images vs links that don't
          have images
   <anne> we need [#col=4] for that or something
   <anne> for column matching
   * fantasai likes hixie's old proposals on that, but can't find them
   Daniel: The technology has improved a lot in these past 10 years
   Daniel: We have faster processors and better layout engines
   Daniel: Can we do it now
   <Hixie> my proposal was to make [#foo=...] match on DOM attributes, iirc
   <fantasai> no for column selectors :)
   <fantasai> colum // cell or something
   * fantasai doesn't quite remember
   <fantasai> but based on table source
   <fantasai> not layout, obviously
   <Hixie> the // combinator was for matching across semantic references
   <fantasai> right
   <Hixie> e.g. img /usemap/ map
   <fantasai> IIRC if it was empty it worked for columns
   <fantasai> that's what I remember, perhaps I misremember
   Elika: I absolutely agree that we should have this functionality in
          Selectors 4
   <Hixie> i prefer [#col=4], [#row>3] etc for tables
   <fantasai> my problem with that is that it requires numbers
   <fantasai> I would want to select based on classes on <col>
   <Hixie> oh well // could work for that too
   <Hixie> col // td
   <Bert> I think // was originally meant for following sibling (back in
          1995/6), but it could be child selector, too.
   <Hixie> col[char=.] // td { text-align: "."; }
   Tantek: I would recommend getting declaration of strong interest from
   <Hixie> er, [char="."] i guess
   Tantek: I agree that we shouldn't put it in and take it out, but I
          think you need to find a strongly interested implementor
   Daniel: Elika, you had some syntax proposal?
   Elika: Yes, just a suggestion. I just don't want us to use pseudo-class
          syntax for this
   Daniel: I originally proposed using ! in front of the selector
   Elika: My suggestion was also to use punctuation in front of the
   Tantek, Molly: It's very confusing because for people with programmer
                  background it means "not"
   <glazou> :nobang
   <tantek> :not(bang)
   * Bert wonders who had the stupid idea to use "!" for "not"...
   Elika: My suggestion was to use a $ sign (for "subject") but other
          punctuation is ok, too
   <glazou> :$ubject  ?
   <fantasai> inverted exclamation point :)
   Daniel: I think we all agree that we need Selectors Level 4
   Elika: As soon as Selectors 3 is published as CR, I'm happy to see
          Selectors Level 4, but not before
   Steve: We should discuss priorities first.
   <plinss> «» ?
   Steve: We need to realistically assess what we are going to do in
          this period.
   Steve: We have more work than we can finish in 2 years
   <glazou> plinss: hey you need charmap on windows to type that :)
   Steve: And if everyone is working on their own drafts, then we can't
          review the drafts
   Elika: I think a FPWD of Selectors 4 is a reasonable thing to expect
          within the next 2 years
   Elika: Not a CR, just a FPWD

Advanced Layout and Non-rectangular Slots

   Bert: All the designers I've spoken to want to put images in the
         middle or in the corners etc and wrap text around it
   Bert: You can do that in Advanced Layout if we allow non-rectangular slots
   Bert: If you know the height, that's not as much of a problem
   Bert: But if you have to do auto height, it's much more difficult
   Bert: Want to know what implementors think about how hard it would be
         to implement
   Elika: If you define it to behave exactly like floats, and don't have
          holes in the shape, it shouldn't be too difficult
   Elika: if you know the size
   Bert: If you want to do a C shape that has as much text above as below,
         then it's still difficult
  * anne ...
   David: That gets into constraint solving
   Elika: It's like the case Alex showed us where you wanted to center
          a paragraph while wrapping it around a non-rectangular float
          that doesn't move...
   Elika: In the interests of finishing Advanced Layout and getting it
          to the implementors, I think we should make this version
          rectangular regions only
   Elika: And tackle non-rectangular regions in a next version
ScribeNick: molly
   Elika: width and height restrictions?
   Bert: what about :slot
   Elika: Designers want it, for backgrounds
   Elika: I have more comments I need to write up but I believe we need
          some kind of a syntax that allows for more properties
   <glazou> deezainorz ?
   Elika: I also think we should remove some of the stuff in the draft
          that isn't about templates
   Elika: Suggest CSS Template Layout Module
   RESOLVED: Rename CSS Advanced Layout to CSS Template Layout
   Elika: need to address rows and columns but not slots
   Elika: width and height should not apply to slots
   Elika: only to columns and rows respectively
   Elika: Need to brainstorm some syntax for this
   Peter: Any other items wrt template
   Peter: any other items at all?
   ACTION: Elika write up Template Layout comments


   Bert: There is a request from Anne from media queries still
   Elika: I'd like to resolve the page-break-inside issue
   Anne: Testing hasn't been done but my recollection of CSS 2.1 was wrong
   Elika: I explained the use cases in detail yesterday
   Bert: I'm worried bcause you can't overwrite avoid
   Bert: With this change you can't until CSS3
   Bert: I'd like to reserve some time to object to this
   RESOLVED: adopt page-break-inside changes with one week open for objections

CSS2.1 Editors

   David: Is it worth discussing CSS 2.1 editing issues?
   Peter: CSS 2.1 editorial
   David: Bert's doing editing, Elika's doing editor type tasks but not spec
          editing: maybe it's worth discussing how it's being split up
   Bert: The best solution is not to raise any issues anymore
   David: There were originally four editors, should I be an editor, Elika
          added as editor
   Bert: The way it is right now is fine but help is always welcome, sure
   Peter: is progress being blocked
   David: It's fine as is then
   Peter: Is that all you want to talk about?

Media Queries

   <anne> http://www.w3.org/Style/Group/css3-src/css3-mediaqueries/
   Anne: removed dependency section
   Anne: Fixed syntax section to build on CSS 2.1 the same way the
         namespace module does
   Anne: There is a reference in the current CR in a note that never
         made it to that
   Anne: Made HTML and XML informative rather than normative
   Anne: Relative units are based on initial value and not initial
         value of root element
   Anne: Updated grids
   Anne: The current rec has a note somewhere within square brackets but
         it wasn't in biblio.ref it was never resolved, tried to fix that
   Elika: White space issues sorted out? We had issues on white space
          defs and syntax
   Anne: The question remains, do we publish another CR or?
   Elika: Needs to go back to last call, we made substantial changes to
          aspect ratio
   Bert: What did we change in aspect ratio?
   Elika: we added it
   RESOLVED: media queries to last call
  * fantasai needs to leave
   Anne: Is it okay if I move draft to public space
   Elika: As long as Hakon is okay - do it
   RESOLVED: move media queries to public space

Daniel: Thank you HP for hosting!
<glazou> ==== ADJOURN ====

<anne> RRSAgent, make minutes
<RRSAgent> I have made the request to generate http://www.w3.org/2008/03/29-css-minutes.html anne
Received on Wednesday, 2 April 2008 19:31:22 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:35 UTC