- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 30 Jul 2009 11:07:19 -0700
- To: www-style@w3.org
Summary:
- Discussed combining background-break and border-break into box-break;
fantasai to draft proposal into Editor's Draft for discussion
- RESOLVED: Add min() and max() functions to calc(); min() and max() may
also appear as standalone functions, their contents parsed
as if wrapped in calc().
- RESOLVED: Allow keywords in expressions.
- Reviewed issues raised for Media Queries; they are editorial, so Anne
will prepare a new CR draft.
- Confirmed that repeating a pseudo-class increases specificity; will add
clarification note to Selectors
- Discussed fantasai's box-shadow and border-image message:
http://lists.w3.org/Archives/Public/www-style/2009Jul/0120.html
No resolution yet.
Original discussion was here:
http://lists.w3.org/Archives/Public/www-style/2009Feb/0361.html
====== Full minutes below ======
Present:
David Baron
Bert Bos
Elika Etemad
Sylvain Galineau
Daniel Glazman
David Hyatt
Peter Linss
David Singer
Anne van Kesteren
Steve Zilles
<RRSAgent> logging to http://www.w3.org/2009/07/29-CSS-irc
Scribe: szilles
<fantasai> http://lists.w3.org/Archives/Public/www-style/2009Jul/0120.html
<glazou> http://lists.w3.org/Archives/Public/www-style/2009Jul/0114.html
Background-break and border-break
---------------------------------
Hyatt: I was attempting to simplify the two properites because people will
often want the same values on both properties and not all the
combinations of the independent properties make sense
fantasai: I think a combination does make sense, but I am not sure what
the values should be
fantasai: what behaviors should we be trying to acheive
fantasai: for border break we might want more sophistication in the styling
fantasai: e.g. "hidden" adds padding
Hyatt: I might want to see a different background in each box
Hyatt: Is this the right way to do the "bounding box" because some of the
current renderings are awkward
Hyatt: could we drop certain features from the combined property knowing
that we might do things better in a future version
dbaron: Most often the authors will just be specifying background-break
dbaron: Most of the time authors won't be using both borders and backgrounds.
Daniel: there is also the issue of authors being able to reduce complexity
and still allow authors to get the features they want
dbaron: having just one property does not necessarily help with readability
in the most common case
Hyatt: a simplification is that the author would say the same thing whether
they were only doing borders, only doing background or both together
Bert: concern about the name
Bert: i like having a single property describing how to handle boxes near
(page) breaks
Hyatt: by using a new mechanism, like background attachment fixed, you can
get backgrounds on the page when there are multiple columns on the page
Hyatt: for otherwise, you can only affect the column boxes
Action: fantasai Draft a proposed combindation of the properties
Min and Max functions in CSS3
-----------------------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2009Jul/0014.html
<glazou> http://lists.w3.org/Archives/Public/www-style/2009Jul/0015.html
dbaron: there is a message that says these should be added inside calc();
I support that addition
fantasai: would calc() be required to do this?
<fantasai> I don't want to write width: calc(min(80ch, 100vw));
fantasai: Allowing it in calc makes sense, but do we need to require it
to be inside calc()
<Bert> I think fantasai asks if it is always calc(min(A,B)) or is min(A,B)
on its own also fine?
<annevk> calc(min(80em-2px,100vw)) ?
Hyatt: do you mean that you could just say min width instead of requiring
calc(min(width))
<dbaron> I'm ok with allowing it at toplevel, but then there's the question
of whether to allow or disallow min(20em-2px, 19em)
Hyatt: it might be simpler to just allow usage in calc right now
Hyatt: if we specify it and not allow it inside calc people would object
Bert: But this changes the model of calc, changing calcs output from a
vector to a tree
<fantasai> min(calc(20em-2px), 19em);
<annevk> calc(min(80em - max(12em+16px,12.5em),100vw))
fantasai: How about allowing calc inside min, but not min inside calc; that
would solve most of the use cases people seem to want
<dbaron> I'd actually probably be happy with making min() just be syntactic
sugar for calc(min()), etc.
<annevk> +1 to dbaron
<sgalineau> +1
dbaron: what I meant by my syntactic sugar suggestion is that you could use
other calc expressions inside the min()
<dbaron> min(20em-2px, 19em)
<dbaron> rather than
<dbaron> min(calc(20em-2px), 19em)
<glazou> calc(min(80em - max(12em+16px,12.5em),100vw))
<sgalineau> dbaron, are we saying we like the latter or the former ?
<annevk> (that one was rather crazy :) )
<dbaron> another possibility is that we allow calc() inside calc(), as the
same thing as ()
Someone mentions width: min(20em, auto);
<Bert> min(1em,thick)
<sgalineau> whoa
Bert: some keywords are easier than others; for example what about 'inherit"
Daniel: the expresion calculation should be based on the used or computed
value, but certainly not the specified value
fantasai: The computed value stores the expression, the used value evaluates
it.
fantasai: if we are allowing keywords, that makes the storage of the result
value more complicated; it is no longer just a tuple
dbaron: you have to already deal with complexity in values like width
<glazou> auto - 10px
dbaron: so having trees isn't much additional complexity
<sgalineau> min(auto-10px,10%+2.5em)
SteveZ: there are some "auto"s that when used in expressions would give
circular calculations
Daniel: I hear that people agree on allowing min inside calc; but do we
want keywords too
Bert: I would like the result of computing the result be independent of
the property for which the value is being computed
dbaron: but, percentages already have different meanings for different
properties
fantasai: I think it's more important to allow keywords inside min than
min inside calc
fantasai: I think having calc and keywords inside min would solve most
of the use cases
fantasai: We did resolve to require spaces around - and + to allow for
keywords inside calc().
fantasai: But there are some implementations that currently do not require
spaces around "+" and "-".
ChrisL: They might change if keywords are allowed, giving them a use case
for requiring the spaces
Daniel: Summary: I hear peoiple supporting both calc inside min and keywords
Daniel: I hear no objection to DB's proposal that min(x, y) is syntactic
sugar for calc(min(x,y))
<Bert> I think "syntactic sugar" means: if the only thing inside calc() is
another functional notation ("foo()"), then calc() can be left out.
ACTION: Daniel negotiate with Håkon to update his module with the above
additions
RESOLVED: add min() and max() to calc(), allowing min() and max() alone
assuming wrapped calc()
RESOLVED: allow keywords in expressions
* Bert next topic: adding tan(), sin() and log() :-)
* dbaron waits for asinh
* Bert : sin() and repentance()
* fantasai is happy with the resolution as long as the implementors are happy
implementing it :)
<hyatt> "happy" :)
CSS Media Queries
-----------------
AvK: What is the next step; do we publish a new draft
AvK: I can make edits to satisfy the 4 comments so far. Should the next step
be WD or CR?
Bert: if the changes are only editorial then the new draft can also be a CR
<dbaron> It might be nice to see a diff at some point (e.g., when we're about
to make the decision to publish).
AvK: I will have a new draft for next week
ACTION: Anne prepare new CR with the editorial changes
dsinger: the media and audio tags allow a media query in the source selection;
should the users accessability needs be added to thet query
ChrisL: that sounds like a good idea
fantasai: people have said that they want different styling when an image is
loaded, but this like the above should be in a future version
AvK: I think that we should allow these features, but I would prefer a
"registry" approach to adding new query categories rather than requiring
a spec update for each addition
dsinger: The idea is that one could inquire about the accessability features
that might be included in a given source file
<annevk> media="all" media="all and (captioning)"
Summary: people think this is a good idea
* dsinger did not get any responses on the HTML5 lists
<annevk> prolly because it was obvious dsinger :)
* fantasai would prefer specs to registry, we will get all kinds of
ill-defined/vendor-specific things if it's just a wiki page
<annevk> you'd need a spec to get in the registry of course
Specificity increase due to repetition of psuedoclasses
-------------------------------------------------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2009Jul/0046.html
<hyatt> seems hacky but legal to me
fantasai: yes, specificity inreases and multiple occurances are legal and
it is hacky
<hyatt> i'd hate to have to special case this to not increase specificity
<hyatt> that would just create work for implementors
Bert: it is a bit hacky and I am not sure it should increase specificity
Sylvain: I would just like an example that shows that it is legal and it
does increase specificity
Peter: This is a giant hack and calling it out is bad form
dbaron: this applies to everything but tags
Daniel: it does not apply to tags because only one element selector is
allowed per chain
ACTION: fantasai Add a clarifying note to Selectors to say multiple occurances
are allowed and increase specificity
<hyatt> some of the pseudo elements are sufficiently complex (nth-child) that
i suspect most implementors just do a list for selectors :)
Box Shadow and Border Image
---------------------------
<fantasai> http://lists.w3.org/Archives/Public/www-style/2009Jul/0120.html
fantasai: I want to lock down a practical version of the spec. I would prefer
leaving the spec as it currently is, no new features
fantasai: I posted my reasons for wanting border-image to mask for box-shadow
fantasai: The main question is how to handle "spreads";
Chris: taking an arbitrary geometry bigger takes converting a path around
the object to a stroke; then converting that to two paths and taking
the union of the paths
Peter: are we OK with saying the spread is (may be) ignored for borders
(it works on boxes)
fantasai: I am arguing that we want the UA to compute an appropriate shadow
for a border-imaged box
fantasai: I'm suggesting the proposal posted by Robert O'Callahan and Dave
Hyatt, rather than what Chris Lilley proposed
fantasai: I am happy with saying implementations may choose to ignore
spread on border images if they want
ChrisL and Hyatt: We should require that "spread" is ignored for border-image
decision: allow ChrisL time to read the roc/hyatt discussion
<fantasai> http://lists.w3.org/Archives/Public/www-style/2009Feb/0361.html
Received on Thursday, 30 July 2009 19:07:40 UTC