- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 02 Apr 2008 12:30:38 -0700
- To: www-style@w3.org
Meeting: CSS Working Group Face-to-Face Meeting, San Diego, CA
Present:
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
CSSOM View
----------
<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
http://www.w3.org/Style/CSS/Tracker/resolutions
CSSOM
-----
<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
canonicalization
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
tractable
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
rules
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
reserialised
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
minutes
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
http://lists.w3.org/Archives/Public/www-style/2008Mar/0283.html
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
Director
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
objection.
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
issue.
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
resolved
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
permission."
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
suite
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
http://www.w3.org/Graphics/SVG/Group/repository/testsuite/1.2T/htmlObjectHarness/tiny-paint-color-04-t.html
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
means
DB: Issue 16, people have argued that "system colors" should not be
deprecated
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
re-affirmed
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
work
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
bar
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
alternative
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
problem
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:
http://www.w3.org/Style/Group/css3-src/css3-links/Overview.html#dual-mode
ACTION: Bert update proposal
http://www.w3.org/Style/CSS/Tracker/
<glazou> NEXT TELECONF 2 OR 3 APRIL CANCELLED
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
Constants
---------
http://csswg.inkedblade.net/ideas/constants
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
implement
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
consistency
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
proposals.)
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
http://www.webstandards.org/2008/01/18/tell-the-css-wg-what-you-want-from-css3/#comments
<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
problem
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
processor
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
implementors
<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
sequence-of-simple-selectors
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
page-break-inside
-----------------
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
No
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