- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Mon, 08 Sep 2008 18:58:00 -0700
- To: www-style@w3.org
Attendees:
David Baron
Bert Bos (staff contact)
John Daggett
Arron Eicholz (via IRC)
Elika Etemad
Daniel Glazman (chair)
Richard Ishida (observer)
Anne van Kesteren
Philippe Le Hégaret
Håkon Wium Lie
Peter Linss (chair)
Alex Mogilevsky
Saloni Mira Rai
Steve Zilles
<RRSAgent> logging to http://www.w3.org/2008/08/22-css-irc
Scribe: alexmog
Agenda
------
Styling for implicit video controls (discussing who added it to the
agenda and if there is a proposal)
Philippe: There are two kinds of controls for the HTML5 video element.
There's the default controls, then you can make controls with JS
elika: is there a proposal?
elika: suggest we skip the topic
(further discussion on why implicit video controls are on the agenda and
if it needs an action item to follow up)
discussion: video control buttons need to be styled. Define pseudo elements
for it?
bert: if we don't provide style, the only solution is script
daniel: suggest a proposal comes from implementers
peter: if this is something we want to address, we should at least discuss
if this something we need to tackle
steve: we don't need to solicit a proposal, it will happen or not happen
<dsinger> I think we should have a discussion of styling of multimedia,
including but not limited to controls, 'stylable aspects' (volume,
brightness, contrast, perhaps) and control of optional aspects of
the content, particularly accessibility
<dsinger> but I agree the discussion should be anchored by proposals...
<dsinger> and that today may not be the best use of time
bert: if we do something we should do it soon or it will fall off the table
<dsinger> the video-on-the-web group seems to be a good place to discuss
cross-group aspects such as CSS implications of media elements,
right?
david: looking at what mozilla is doing now
david: controls with SVG, not seeing anything with custom controls
<dsinger> (I am in another stds meeting and cannot call in, only IRC when
I am not paying attention here!)
(it is noted that David Singer is interested in the topic)
anne: We already have problems styling form controls
anne: The appearance property is way underspecified
anne: people are implementing form controls in JS, makes it unusable for
mobile phones
peter: propose action dsinger and bert to contact someone in mozilla and
come up with a proposal
Philippe: someone being Chris Double
<dsinger> I'm happy to work with Bert on "CSS aspects of HTML5 media
elements", yes
action bert: come up with a proposal for implicit video controls
<dbaron> And for what it's worth, I think what we're doing with the
controls attribute is pretty much what HTML5 says to do.
Block Flow
----------
elika: molly proposed syntax for block-progression
elika: block-flow: tb | rl | lr | bt (bt is optional)
elika: richard, what do you think
richard: reasonable
david: "flow" could be one of multiple things...
richard: when do we want to talka about case A (on the whiteboard - tbrl
flow)
richard: should it be called "block-flow-direction" ?
elika: when we talk about vertical, we'll say "in left-to-right block
flow"
RESOLVED: Molly's proposal accepted
steve: when this replaces property name, do we still say "block flow
direction"?
elika: yes
elika: we have a concept of "normal flow" as opposed to out of flow
elika: ... and inline flow direction...
elika: tblr, tbrl = "horizontal block flow"
elika: lrtb, lrbt = "vertical block flow"
steve: bad idea for general terminology
peter: we should always qualify with "inline" or "block" flow
peter: terminology is fine when talking of block flow, not for general
discussion where "vertical" means "vertical text"
steve: same objection
* anne notes http://www.w3.org/QA/2008/08/css-wg-give-me-a-break.html
elika claims it is a bad idea to use "direction" property in CSS. it
should be in html "dir" property because content knows more
about its direction
alex is surprised and doesn't yet agree with it
richard: I would use "vertical text mode" even if it isn't text
steve: agree, that is the most common usage
richard: do we need "mode"
alex: in a sentence "in vertical text mode table rows are vertical" -
is "mode" necessary?
richard: with "mode" it sounds more specific in terminology
elika: works for me
RESOLVED: "vertical text mode", "horizontal text mode"
richard: So for Mongolian you'd say "left to right vertical text mode"
Bert: I've been using adjective terms mostly
mongolian = "vertical text mode with left-to-right block flow direction"
elika: could say "vertical mode containing block"
elika: ok to use shortened form "vertical block"
alex: define once "vertical block" = "block with vertical text flow
direction"
daniel: list style "tree"
peter: arron wanted to be on call for that
CSS3 Backgrounds and Borders
----------------------------
<glazou> next topic is CSS Backgrounds and Border
daniel: may or may not talk about variables today. it would be good to
have apple people for that one.
<dsinger> (I'm in europe but don't know about variables, I'll ping the
other apple folks, but it'll be late in the day if you catch
them (for you, that is))
<fantasai> http://dev.w3.org/csswg/css3-background/
elika: couple of open issues
-- issues 10 and 11: specify which corner offsets are from
http://www.w3.org/Style/CSS/Tracker/issues/10
http://www.w3.org/Style/CSS/Tracker/issues/11
elika: "background-position: bottom 10px right 25%"
david: what happens when keywords and values are rearranged?
peter: "left 15px" means "0px, 15px" - why?
david: the problem with "bottom right 10px 25%" is, does it mean 10px horiz
25% vert or 10px vert 25% horiz? because currently with coordinates
the horiz is always first
david: another way to solve same problem is calc()
alex would find it more intuitive to have a separate property that defines
alignment direction
davie would rather leave it to calc() at this point
hakon: can we write an example using calc()?
elika: "background-position: 75% calc(100% - 10px)"
hakon: good case for adding calc
<fantasai> background-position: 75% calc(100% - 10px);
<dbaron> I don't see any reason background-position: 75% calc(bottom - 10px)
shouldn't work either
hakon: want inside/outside too
<dbaron> calc(0.25 * start + 0.75 * end)
peter: calc is designed to solve odd cases
peter: you can't build something that depends on direction
* plh background-position: gps(N42°21.69348, W071°5.4957);
saloni: "start + 5px" makes sense
peter: you can't substitute "start" with 0 or 100...
elika: I don't think we should allow keywords in calc
hakon: agree
discussion on difference of start/end and left/right
steve: how do we represent start + 5px?
elika: calc(start + 5px)
<fantasai> background-position: 75% calc(100% - 10px);
<fantasai> background-position: bottom 5px left 45px;
<fantasai> background-position: start 5px top 45px;
<fantasai> background-position: calc(start + 5px) top;
<fantasai> background-position: calc(5px + start) top;
<fantasai> background-position: calc(start + end) top;
<fantasai> background-position: calc(start + bottom) top;
<fantasai> You're going to make Molly cry if you make her do this much
math just to put something in the bottom right corner. :(
<fantasai> (we are looking at examples in
http://dev.w3.org/csswg/css3-background/#the-background-position )
<fantasai> Elika is against putting keywords in calc()
<dbaron> calc(25% + 10px) means you position the 25% point in the image
at the 25% + 10px point in the container
* alexmog is not excited in parsing calc(100% + 5x) separately to determine
anchor point in the image, then again to get the number
<dbaron> The current definition of calc() doesn't allow keywords, so I'm ok
with not allowing keywords too.
<fantasai> discussion of implementing calc()
<dbaron> background-position: 15px 20% (left top);
<Bert> (calc() is a fancy notation for a triple (p, q, r) where p is the
number of percentages, q the number of ems and r the number of px.)
<dbaron> background-position: 15px 20% (start after);
background-position: 0 15px; background-flow: rl-tb;
<fantasai> background-position: [ <length> | <percentage> ]{2} [ keywords ] {2}
<fantasai> Steve attempting to paraphrase Alex: for writing-mode relative
positioning, just add one keyword to make it writing-mode relative
<dbaron> background-position: 15px 20% from-top-left;
<fantasai> RESOLVED: No keywords in calc() for background-position
<dbaron> background-position: 15px 20% from-before-start;
david: I no longer propose calc() as a solution for RTL background
* alexmog is happy to hear that
<fantasai> Richard Ishida draws two images
<fantasai> [ W3C ::: :: : : : ]
<fantasai> [ : : : :: ::: W3C ]
* glazou notes that fantasai is excellent at asciifying graphics :-)
<dbaron> background-position: 15px 20% logical;
it is noted that right-aligned background is possible in CSS2 -
"background-position:100%"
<dbaron> and then calc(100% - 10px) can handle the right-relative use case
<dbaron> to solve vertical, you'd also need background-repeat:
repeat-block-progression | repeat-inline-progression
alex: if there is a keyword "logical" it picks one of 4 corners for
origin, then tiles normally...
<dbaron> and you'd need to make 'logical' on background-position flip the
x and y for the vertical case
Elika: and you'd also need mirroring / rotating of the image
<Bert> Corners NW, NE, SE and SW?
background-position: 15px 20% tb-lr;
peter: we don't want to use "top-right" combinations will explode ...
"start-right", etc.
hakon supports an additional property that defines origin
david: if there are 8 writing modes, do we need all 8 for background
position?
alex: yes, if rotate and mirror are included
<dbaron> Elika: background-remap: absolute | reposition |
[ mirror || rotate ]
<dbaron> Håkon: can't live with this
steve: whatever we do should work if image is designed for arabic, then
mirrored to english version
steve: the real requirement is for semitic pages to have the same
capabilities as western pages
backround-position-mode
background-mode
hakon: why not have a background-offset property?
elika proposes dropping the functionality from CSS3 and taking CSS3 to CR?
Scribe: fantasai
fantasai: New proposal: drop background positioning from other corners,
push that and border-length to CSS4 BB, publish this draft as
WD, then LC/CR around Dec/Jan.
Steve: do we have consensus on using a separate property for defining
origin corner?
fantasai: No, because whether I agree with having a separate property
depends on what it's defining
fantasai: if we're defining which corner the origin is separate from the
offsets, then I don't agree
dbaron: I agree with Elika
Peter: So proposal on the table is to use calc() for positioning from
bottom right, and moving on with this draft
Alex: I like Elika's original proposal with bottom and left keywords
better than calc()
David: I think I agree with what Alex is saying
David: Take the current set of values, those are still valid
David: Then add to that a syntax for four values
Alex: And it's not allowed to mix logical and physical
Alex: can't mix start and top
Peter: My concern is that it makes the background remap unlikely to work
later
Alex: I think this is preferable to dropping values from CSS3
Peter: Are you going to implement this in IE8?
Alex: Unlikely
Alex: If we choose to add something from CSS3 BB in IE8, multiple
backgrounds would come much sooner than this
* plh notes http://www.w3.org/QA/2008/08/css-wg-give-me-a-break.html
* anne notes http://krijnhoetmer.nl/irc-logs/css/20080822#l-207
* anne ;)
* plh is waking up slowly :)
proposal: elika's original version, with restrictions that remove ambiguity
no start/end/before/after in CSS3
<Bert> (background-position: right 1em 1px bottom 1.4em -1px)
elika shows examples
<fantasai> background-position: left top 10px;
<fantasai> background-position: left 10px top;
<fantasai> background-position: 10px 10px; /* CSS1 */
<fantasai> background-position: top 10px left 10px;
<fantasai> background-position: left 10px 10px; /* INVALID */
Scribe: alexmog
hakon: what will dom return here?
elika: 4 values
<fantasai> fallback behavior:
<fantasai> background-position: bottom right;
<fantasai> background-position: bottom 10px right 10px;
<fantasai> background-position: bottom right; /* CSS1/2 clients */
<fantasai> background-position: bottom 10px right 10px; /* CSS3 clients */
<fantasai> Bert: I want to wait for calc
-!- plinss_ [peter.lins@15.243.169.72] has quit [Ping timeout]
<fantasai> Daniel: I disagree, I think web authors will not understand calc()
-!- plinss_ [peter.lins@15.243.169.69] has joined #css
RESOLVED: 4-value syntax, two keywords must be present, zero values can be skipped (examples above)
saloni: how about start/end/before/after
<Bert> I don't think we resolved anything, I think we decided it was unresolved.
no consensus at this point on when start/end are introduced
RESOLVED: new background-position syntax in the draft is ok
<SaloniR> I accept the syntax but I want the discussion on start/end to happen soon.
<Bert> Not resolved. Objection from me.
<Bert> calc() will happen anyway, so don't add redundant syntax.
break
<fantasai> http://www.w3.org/Style/CSS/Tracker/issues/28
elika: there is a proposal to add 'transparent' keyword to border-image
property
elika: it would complicate the syntax, the image can be made transparent too
david: we can skip it, syntax is complicated enough
peter: it seems a misnomer that border-image includes background, although
i see use cases
consensus: no change
RESOLVED: proposal to add "transparent" to border-image is rejected
<fantasai> http://www.w3.org/Style/CSS/Tracker/issues/46
issue 46 -- rename background-origin to background-box
Steve: Why not call it background-position-area
elika: there is background-clip with same values
peter: sounds consistent
elika: there is background-break property (for page boundaries)...
peter: would expect background-clip to take a rect. should it be
background-clip-box?
peter: and background-box
david: don't like background-box since there is also two; this is origin
for positioning
anne: let's keep it stable
(no strong arguments to making the change)
peter: concern about background-clip - will it interfere with adding a
rect clip in the future?
elika: will allow rect in background-clip
steve: background-position-box?
anne prefers to not change; there are implementations already
elika: That's clearer, but my concern is that it breaks the pattern that
given properties foo and foo-bar, foo is a shorthand that sets
foo-bar
<Bert> ('background-origin: NE content-corner')
david: ok with changin background-origin; background-clip is a good name
<anne> ('background-origin' has remained the same since 2002; nobody has
suggested something substantially better it seems, otherwise it
would've been changed)
RESOLVED: no change to background-origin/background-clip naming
<Bert> (Or combine bg-origin and bg-clip into one property?)
elika: added no-clip to background-clip property. marked at-risk.
david: painful to implement... an odd overflow case
elika: no-clip with a no-repeat image overflows the box to however big
the image is
steve: what does it do for scrolling
peter: probably should not trigger overflow
alex: if it looks like overflow it should behave like overflow
elika: shadows currently don't trigger overflow
elika: we currently don't define anywhere what triggers overflow
elika: if your element has scrollbar and background is scrolled you are
allowed to clip to padding edge
saloni: how does overflow background affects other elements?
elika: same stacking order as normal backgrounds
peter: does it belong to the same property?
<fantasai> border-clip: padding-box no-clip
<Bert> (background-repeat: repeat | no-repeat | repeat-x | repeat-y |
no-clip ? Or background-image: url(foo) no-clip ?)
elika notes that no-clip would be marked at-risk
peter: not convinced it is a good idea but if we have to have it I'd
prefer a separate keyword
elika: box-shadow property
elika: adding inner shadow -- inset keyword
elika: brad kemper have images for that
david: is the spread feature still in? I know we implement that
elika: want to publish a working draft
david: plan to last call reasonably soon
anne: is border-radius stable?
elika: yes, and we have accepted your proposal
RESOLVED: publish WD
Template Layout
---------------
Scribe: fantasai
Bert: Can we publish a new working draft of Template Layout that consists
of the first section with Template Layout
Bert: with the second and third parts removed?
Bert: Nobody seems interested in the tabbed layout or row-based layout
http://www.w3.org/Style/Group/css3-src/css3-layout/
Bert: old version http://www.w3.org/TR/2007/WD-css3-layout-20070809/
Elika: I had a comment that you should be able to assign min/max
widths/heights to rows and columns
Bert: there is syntax there for doing that
Daniel: Are implementors interested in this?
Anne, David: we are more interested in flexbox
Howcome, Bert: This has useful things, especially the ability to reorder
content
Saloni: How does this fit with the grid proposal?
Bert: they are complementary, they work together
Bert: With the grid module, you establish a grid, but then you need to
use top/left etc to position things
Bert: With this you establish the grid and create slots at the same time
...
Elika: I think Grid is very useful for snap-to-grid
Elika: I think using positioning with grid is not likely to be as robust
Elika: but being able to snap widths/heights to grid
Bert: or float to grid, or space out N items
would be useful for those
ACTION: Bert update CR Exit criteria to latest wording for CSS3 Template module
<plinss_> Latest version of the text: http://www.w3.org/Style/CSS/Tracker/actions/44
CSS2.1 Issues
-------------
Topic: Revisit Issue 14 in CSS2.1
http://lists.w3.org/Archives/Public/www-style/2008Aug/0154.html
http://lists.w3.org/Archives/Public/www-style/2008Aug/0164.html
# The bottom margin of an in-flow block-level element is adjoining
# to its last in-flow block-level child's bottom margin when:
# * the element's specified 'height' is 'auto',
# * the element's used height is the same as it would have
# been if the specified values of 'min-height' and 'max-height'
# were their initial values
# * the element has no bottom padding or border.
Alex: Maybe the bullet about 'overflow' not 'visible' should be generalized
to block formatting contexts
<dbaron> Elika adds that as issue 70.
RESOLVED: proposal accepted for Issue 14
Change
Vertical margins of elements with 'overflow' other than 'visible'
to
Vertical margins of block formatting contexts (such as floats and
elements with 'overflow' other than 'visible')
for Issue 70
http://csswg.inkedblade.net/spec/css2.1#issue-70
RESOLVED: proposal accepted for Issue 70
http://csswg.inkedblade.net/spec/css2.1#issue-46
http://lists.w3.org/Archives/Public/www-style/2008Jun/0106.html
David: The issue is that we don't really say how media restrictions work
David: We say that if the @media rule matches, then all the rules inside
it apply
David: But we don't say what happens with nesting
David: if you get to a style sheet by multiple links, you don't want to
check only the restrictions on the parent link
David: You want to match the media restrictions on all the links
David: Also you want this to work right if you link to the style sheet
in multiple places.
Daniel: The last sentence in this proposal doesn't handle media queries
David: This is for 2.1, not CSS3
"The import only takes effect if the target medium matches the media
list." <- prepend to last para in 6.3
RESOLVED: Accept dbaron's proposal plus the change above (from plinss).
Bert to figure out exact placement etc.
http://csswg.inkedblade.net/spec/css2.1#issue-49
http://lists.w3.org/Archives/Public/www-style/2008Aug/0167.html accepted with s/will more/will be more/
http://csswg.inkedblade.net/spec/css2.1#issue-62
http://lists.w3.org/Archives/Public/www-style/2008Aug/0168.html
RESOLVED: Proposal accepted for Issu 62/51
Peter: Melinda raised an issue with the grammar
Peter: rule sets can't contain other blocks
discussion of what 'any' means and whether it is permissive enough
inconclusive
http://csswg.inkedblade.net/spec/css2.1#issue-32
Daniel: I hit exactly the same problem in my source code editor.
Daniel: @ followed by an unrecognized ident will not be recognized as an
at-keyword by the parser
David: You shouldn't use Appendix Gs' grammar for parsing
Daniel: If you follow Appendix G you will not recognize @foo as an at-rule.
http://lists.w3.org/Archives/Public/www-style/2008Aug/0165.html
RESOLVED: Proposal by dbaron+fantasai accepted for ISSUE 32
http://csswg.inkedblade.net/spec/css2.1#issue-35
Issue described by
http://lists.w3.org/Archives/Public/www-style/2008Jan/0432.html
and
http://lists.w3.org/Archives/Public/www-style/2008Mar/0026.html
Daniel: I see your point, David, but I think if web authors specify all
four offsets they will expect the replaced element to stretch
to fit
David: I think this would become the only case where a replaced element
with width and height auto would behave differently from a
non-replaced element with explicit width and height.
...and I'm also unsure whether we should be changing the spec at
this point because we don't like what it says.
Elika: I think we should make this change for replaced elements without
an intrinsic size
David: I don't want to half-make this change. I'd rather either make it
or not.
Elika: The results for http://fantasai.inkedblade.net/style/tests/issues/abspos-replaced-intrinsic-unsized
-- using 300px by 150px
Elika: really don't make any sense at all
Seem to agree that this change would make sense for authors, other
questions remain
Peter: Would this break existing content?
Peter: IIRC WebKit tried to match the spec here and ran into broken content
discussion between Bert and Peter
everyone tries to convince Bert that flexing auto makes more sense than
ignoring a specified offset
Bert is not convinced
Straw Poll: Do we make an absolutely-positioned replaced element with
intrinsic size stretch/shrink to fit if all four offsets
are specified?
Discussion about interoperability
Howcome: It's not worth it to fix it. You can fix this today by setting
the width. But we already have interoperability on the
currently-specified behavior
Alex: If we change this in the spec, would FF3 fix it?
David: Not for 3.0, but perhaps for 3.1
David: Not saying that we'd necessarily have time to change it, but that
we'd be willing to
Howcome: I'm not really convinced that this is worth changing from being
interoperable to perhaps years of not being interoperable
Howcome: I think we're taking a risk there.
Howcome: I'm a skeptic
David: Abstain
Daniel: In favor
Saloni: Change
Richard: abstain
Steve: abstain
Peter: in favor
Alex: mixed feelings. I see perfect interop here
Alex: We can improve it, but why
Alex: No change
Bert: No change
Elika: no strong opinion, change iframe not image
Anne: seems there are enough other ways to get this effect that we can
address this case using other means
Anne: So I would say no change
<arronei> From what I have just read I would say no change
Daniel: No consensus at all.
Daniel: So we'll have to say no change.
RESOLVED: No change.
Elika: Can we undefine the behavior for iframes?
<glazou> <br style="reason: bee;"/>
Charter
-------
* glazou has to leave in 45 minutes from now
Daniel: I want to discuss the charter and also to report on Variables
Philippe: I looked into the charter
Philippe: Listent to you for past three days
Philippe: Don't have any significant changes to suggest.
<plh> http://www.w3.org/Style/Group/2008/draft-charter2.html
philippe: I changed the online version of it this afternoon, some minor
changes but perhaps they are major for some people
Philippe: We changed success criteria
Philippe: to be relative to each feature instead of each deliverable
Bert: In some cases you might want per-feature, in some cases
per-deliverable
Bert: For example with a profile you don't want each feature you want
the whole thing
Philippe: My intention was to make it less restrictive.
Philippe: So that you can choose to target the whole deliverable, but
in other case you can also target each feature
Philippe: I didn't see any need to call out the W3C RECs for QA
Framework, Charmod, Web Architecture
Philippe: We just expect everyone to follow the RECs
Philippe: Removed sentence about minutes being public because that is
redundant with the top part of the charter, which says
proceedings will be public
Philippe: Removed paragraph saying that we follow Section 3.4 Votes
because the previous sentence adds extra restrictions
Philippe: Some concerns about your process.
Philippe: Your Decision Policy requires making decisions only during
group meetings
Philippe: And the quorum requirement ...
Elika: The Decision Policy paragraph seems to impose the 2/3 quorum
requirement on all technical decisions
Elika: Not just for formal votes.
Elika: And we almost never have 2/3 of Members in attendance
<dbaron> "When deciding a substantive technical issue" should have
"by formal vote" at the end.
See dbaron's comment in IRC -- we should make that change.
Philippe: Deliverables section
Philippe: I want to be clear that anything not under this section is
not under the patent policy
Philippe: Any contributions made to these drafts will not be under
the patent policy
Philippe: If you want any working drafts to be in REC track they
must be in the Deliverables section.
Steve: The other items are in scope, they're just not expected to be
delivered in this charter
This section seems to need clarification about the other items in the
module list being on the REC track
Philippe: Just add a pointer back into the Scope section from here to
make it clear that those items are in the REC track
Daniel: Steve, when we had these items under the REC track list you
objected that it was way too many items under patent disclosure
and Adobe lawyers would object
Steve does not remember this
...
Daniel: I think if we put everything back under the REC track then W3C
will not accept the charter because they want us to prioritize
more heavily
Philippe: You need to say that these Deliverables are the items that
the WG will deliver, but that the other items in the Scope
section are also on the REC track
Daniel: This is the opposite of what Chris Lilley wanted
Daniel: I suggest you talk with Chris Lilley before we make any changes
here
Philippe: The IP policy would reject publishing any item not on this
deliverable list
Steve: Right, the agreement was that if we wanted to publish something
as a WD we would amend the charter to include it
discussion about being on REC track, covered under IP policy etc
Steve: What surprised me is that the patent policy would not apply to
the items in scope but not deliverable
Daniel: Any other feedback on wg?
Philippe: The WG seems to be working well. Have a resources problem,
that is not uncommon.
Philippe: It would be nice to have CSS2.1 as a REC asap
Daniel: That's the goal
Daniel: Ok, thank you Philippe
<Bert> (I think the easiest change is to change the title from
"Rec-track deliverables" to "milestones" to remove the impression
that the other drafts are excluded from the Rec-track.)
<plh> Bert, I'm fine with that change, but the charter needs to indicate
which deliverables are on the rec track, so you need a statement
somewhere that says that all modules are on the rec track.
<Bert> Plh, I'm fine with saying that explicitly, but I'm sure it's
redundant.
<plh> fantasai, I changed the draft charter to reflect your comment
on quorum requirements
CSS Variables
-------------
Daniel: Dave and I made some changes from the original spec we released
back in April
Daniel: The first change is in the keywords themselves
Daniel: Based on a suggestion it changed @variables into @define
Daniel: In the current nightly builds we can use both of them
Daniel: And we add a media type
<arronei> Is there a link to the updated document?
http://lists.w3.org/Archives/Public/www-style/2008Jul/0545.html
Daniel: Note that for the time being it's vendor-prefixed
Daniel: He added two things I thought were incredibly ugly
Daniel: =foo= and $foo
Danie: It really looks like a programming language now?
John: Doesn't that cause problems in templated situations?
Daniel: In a more recent email, Hyatt added the ability for variable
to be a block of CSS declarations
<plh> Bert, not in what I've seen unfortunately
http://lists.w3.org/Archives/Public/www-style/2008Jul/0571.html
David: Are variables variable or are they constant?
Daniel: The syntax for calling this breaks the forwards-compatible
grammar
Daniel: It's something web authors have wanted for years, but it
breaks CSS as it is
Daniel: I personally like the feature, I don't like the design
Daniel: If you have comments yourself about this, please jump on
thread and make a comment
John: So why is the functional notation a good thing?
Elika: I don't like the functional notation because I don't want
nested parentheses e.g. inside calc()
http://lists.w3.org/Archives/Public/www-style/2008Jul/0571.html
Steve: What if I created a new property that took the variable
substitutions?
Elika: That's a hack. It's not really a property-value combination,
it's meant to be replaced by a set of property-value
combinations
David: The current CSSOM only supports one value per property
per declaration
David: You can't do that and get the cascading order right
David: And change the variables after the fact
Daniel: Then these need to be constants
Steve: Also I could have recursive variable calls
Anne: was there a lot of positive feedback of them being mutable
through the DOM?
Howcome: I don't think that's a very good idea
<anne> (I would like to see pointers fwiw.)
Howcome: A syntactic macro function seems reasonable
Howcome: but manipulating them through the DOM, I don't think so
<fantasai> I still prefer
http://lists.w3.org/Archives/Public/www-style/2008Jul/0031.html
personally for syntax
Several conversations at once
Saloni: font-size: calc( var(black) + 1em); ?
<Bert> (These variables do so little and cost so much :-( Why not design a
*real* macro language, with parametrized macros, conditional macros
and all. It can be much more powerful and at the same time much
easier to spec and use...)
fantasai: I don't particularly like their proposal. I'd prefer something
like macros
Anne: constants would make things easier for the CSSOM
David: It's not that clear whether their proposal is variables or constants
Steve: macros just save typing, they're not that important to have
Elika: maintenance
Elika: Can we make a counter-proposal?
<dbaron> (unminuted discussion with people talking very fast and
simultaneously)
<Bert> (... discussion continues about... scope (from definition
forwards only?)... textual replacement or typed/pre-parsed
replacement...)
<anne> Test:
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A...%3Cstyle%3Ebody%20%7B%20background%3Ared%3B%20test(test)%3B%20background%3Alime%20%7D%3C%2Fstyle%3E
ACTION: fantasai draw up parse-time constants counter-proposal
ACTION: peter draw up parse-time constants counter-proposal
Meeting closed.
Received on Tuesday, 9 September 2008 01:58:41 UTC