IRC log of CSS on 2009-07-29

Timestamps are in UTC.

15:37:30 [RRSAgent]
RRSAgent has joined #CSS
15:37:30 [RRSAgent]
logging to
15:55:17 [oyvinds]
oyvinds has joined #css
15:55:37 [glazou]
tjena oyvinds
15:56:10 [glazou]
Zakim, this will be Style
15:56:10 [Zakim]
ok, glazou, I see Style_CSS FP()12:00PM already started
15:56:21 [Zakim]
+ +1.408.398.aabb
15:56:45 [dsinger_]
dsinger_ has joined #css
15:56:53 [glazou]
Zakim, +aabb is dsinger_
15:56:53 [Zakim]
sorry, glazou, I do not recognize a party named '+aabb'
15:57:05 [glazou]
Zakim, aabb is dsinger_
15:57:05 [Zakim]
+dsinger_; got it
15:57:09 [dsinger_]
Zakim, mute me
15:57:09 [Zakim]
dsinger_ should now be muted
15:58:45 [Zakim]
15:58:49 [dbaron]
Zakim, [Mozilla] has David_Baron
15:58:49 [Zakim]
+David_Baron; got it
15:59:22 [dbaron]
Zakim, who is on the phone?
15:59:22 [Zakim]
On the phone I see +95089aaaa, dsinger_ (muted), [Mozilla]
15:59:23 [Zakim]
[Mozilla] has David_Baron
15:59:39 [dbaron]
Zakim, aaaa is Daniel_Glazman
15:59:39 [Zakim]
+Daniel_Glazman; got it
16:00:06 [dbaron]
That way we wont disconnect glazou when we're puzzled by the number.
16:00:13 [sgalineau]
sgalineau has joined #css
16:00:19 [glazou]
hehe :)
16:00:44 [dsinger_]
Zakim, who is here?
16:00:44 [Zakim]
On the phone I see Daniel_Glazman, dsinger_ (muted), [Mozilla]
16:00:45 [Zakim]
[Mozilla] has David_Baron
16:00:46 [Zakim]
On IRC I see sgalineau, dsinger_, oyvinds, RRSAgent, Zakim, glazou, dbaron, Lachy, karl, myakura, MikeSmith^away, shepazu, arronei, dsinger, anne2, krijnh, plinss_, Hixie,
16:00:49 [Zakim]
... jdaggett, fantasai, trackbot, Bert, plinss
16:01:05 [Zakim]
16:01:05 [hyatt]
hyatt has joined #css
16:01:16 [sgalineau]
Zakim, [Microsoft] has sylvaing
16:01:16 [Zakim]
+sylvaing; got it
16:01:21 [Zakim]
+ +49.238.aacc
16:01:34 [dbaron]
Zakim, aacc is Bert
16:01:40 [Zakim]
16:01:44 [Zakim]
+Bert; got it
16:02:06 [dbaron]
Zakim, ??P32 is fantasai
16:02:23 [hyatt]
i joined
16:02:24 [Zakim]
+ +1.281.419.aadd
16:02:26 [Zakim]
+ +1.858.216.aaee
16:02:28 [Zakim]
+fantasai; got it
16:02:28 [hyatt]
that is me
16:02:34 [hyatt]
the 281 one
16:02:38 [dbaron]
Zakim, aadd is hyatt
16:02:38 [plinss]
zakim +1.858.216 is me
16:02:42 [dbaron]
Zakim, aaee is plinss
16:02:59 [dbaron]
Zakim is pretty slow today
16:03:04 [Zakim]
+hyatt; got it
16:03:08 [Zakim]
+plinss; got it
16:03:09 [glazou]
for those interested in linguistic maps of the whole world, I strongly recommend
16:04:26 [Bert]
"Linguistic map of antarctica" and it isn't even empty...
16:04:27 [Zakim]
16:04:49 [dbaron]
Zakim, who is on the phone?
16:04:49 [Zakim]
On the phone I see Daniel_Glazman, dsinger_ (muted), [Mozilla], [Microsoft], Bert, fantasai, hyatt, plinss, SteveZ
16:04:51 [Zakim]
[Mozilla] has David_Baron
16:04:51 [Zakim]
[Microsoft] has sylvaing
16:05:09 [annevk]
annevk has joined #css
16:05:24 [szilles]
szilles has joined #css
16:05:39 [glazou]
ScribeNick: szilles
16:05:58 [fantasai]
16:06:11 [annevk]
Zakim, passcode?
16:06:14 [fantasai]
16:06:22 [dbaron]
16:06:28 [Zakim]
the conference code is 78953 (tel:+1.617.761.6200 tel:+ tel:+44.117.370.6152), annevk
16:06:35 [glazou]
16:06:38 [szilles]
Item: Background-break and border-break
16:07:00 [Zakim]
16:07:10 [annevk]
Zakim, [IPcaller] is me
16:07:10 [Zakim]
+annevk; got it
16:07:13 [glazou]
hi anne2
16:07:14 [glazou]
16:07:20 [annevk]
16:07:34 [szilles]
DH: 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
16:07:56 [szilles]
EE: I think a combination does make sense, but I am not sure what the values should be
16:08:16 [szilles]
EE: what behaviors should we be trying to acheive
16:08:35 [szilles]
EE: for border break we might want more sophistication in the styling
16:08:54 [szilles]
EE: e.g. "hidden" adds padding
16:08:56 [ChrisL]
ChrisL has joined #css
16:09:10 [szilles]
DH: I might want to see a different background in each box
16:09:17 [Zakim]
16:10:02 [szilles]
DH: Is this the right way to do the "bounding box" because some of the current renderings are awkward
16:10:37 [szilles]
DH: could we drop certain features from the combined property knowing that we might do things better in a future version
16:11:26 [szilles]
Most oftern the authors will just be specifying background-break
16:12:24 [Bert]
DBaron: author...
16:12:25 [dbaron]
DB: Most of the time authors won't be using both borders and backgrounds.
16:12:29 [szilles]
s /oftern/often/
16:13:22 [szilles]
DG: there is also the issue of authors being able to reduce complexity and still allow authors to get the features they want
16:13:54 [szilles]
DB: having just one property does not necessarily help with readability in the most common case
16:14:48 [szilles]
DH: a simplification is that the author would say the same thing whether they were only doing borders, only doing background or both together
16:15:36 [glazou]
16:15:48 [szilles]
BB: concern about the name
16:15:57 [glazou]
even glazou has initials can you believe it ?-)
16:16:20 [szilles]
BB: i like having a single property describing how to handle boxes near (page) breaks
16:17:32 [szilles]
DH: by using a new mechanism, like background attachment fixed, you can get backgrounds on the page when there are multiple columns on the page
16:17:47 [szilles]
DH: for otherwise, you can only affect the column boxes
16:18:20 [szilles]
Action: EE: Draft a proposed combindation of the properties
16:18:20 [trackbot]
Created ACTION-167 - Draft a proposed combindation of the properties [on Elika Etemad - due 2009-08-05].
16:18:40 [glazou]
16:18:49 [szilles]
Mean and Max functions in CSS3
16:19:06 [dbaron]
16:19:09 [glazou]
16:19:20 [szilles]
DB: there is a message that says these should be added inside Calc; I support that addition
16:19:36 [annevk]
EE: would calc() be required to do this?
16:19:57 [fantasai]
I don't want to write width: calc(min(80ch, 100vw));
16:20:00 [szilles]
EE: Allowing it in calc makes sense, but do we need to require it in calc
16:20:38 [Bert]
I think EE asks if it is always calc(min(A,B)) or is min(A,B) on its own also fine?
16:20:45 [annevk]
calc(min(80em-2px,100vw)) ?
16:20:51 [szilles]
DH: do you mean that you could just say min width instead of requiring calc(min(width))
16:21:25 [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)
16:21:26 [szilles]
DH: it might be simpler to just allow usage in calc right now
16:21:51 [szilles]
DH: if we specify it and not allow it inside calc people would object
16:22:18 [szilles]
BB: But this changes the model of calc, changing calcs output from a vector to a tree
16:22:26 [fantasai]
min(calc(20em-2px), 19em);
16:22:27 [annevk]
calc(min(80em - max(12em+16px,12.5em),100vw))
16:22:48 [dbaron]
I'd actually probably be happy with making min() just be syntactic sugar for calc(min()), etc.
16:23:08 [szilles]
EE: How about allowing calc inside min, but not min inside calc; that would solve most of the use cases people seem to want
16:23:13 [annevk]
+1 to dbaron
16:23:35 [Zakim]
16:23:51 [Zakim]
16:23:55 [dsinger]
zakim [apple] has dsinger
16:24:16 [sgalineau]
16:24:46 [szilles]
DB: what I meant by my syntactic sugar suggestion is that you could use other calc expressions inside the min()
16:25:06 [dbaron]
min(20em-2px, 19em)
16:25:07 [dbaron]
rather than
16:25:12 [dbaron]
min(calc(20em-2px), 19em)
16:25:23 [glazou]
alc(min(80em - max(12em+16px,12.5em),100vw))
16:25:29 [sgalineau]
dbaron, are we saying we like the latter or the former ?
16:25:52 [annevk]
(that one was rather crazy :) )
16:26:55 [dbaron]
another possibility is that we allow calc() inside calc(), as the same thing as ()
16:26:58 [Bert]
16:27:04 [sgalineau]
16:28:03 [fantasai]
someone mentioned also width: min(20em, auto);
16:28:04 [szilles]
BB: some keywords are easier than others; for example what about 'inherit"
16:28:57 [szilles]
DG: the expresion calcultaion should be based on the used or computed value, but certainly not the specified value
16:29:49 [szilles]
EE: if we are allowing keywords, that makes the storage of the result value more complicated; it is no longer just a triple
16:30:24 [szilles]
DB: you have to already deal with complexity in values like width
16:30:36 [glazou]
auto - 10px
16:30:39 [dbaron]
DB: so having trees isn't much additional complexity
16:30:42 [sgalineau]
16:31:26 [szilles]
SZ: there are some "auto"s that when used in expressions would give circular calculations
16:32:20 [szilles]
DG: I hear that people agree on allowing min inside calc; but do we want keywords too
16:32:35 [dsinger_]
dsinger_ has joined #css
16:33:13 [szilles]
BB: I would like the result of computing the result be independent of the property for which the value is being computed
16:33:23 [dsinger_]
dsinger_ has joined #css
16:33:40 [szilles]
DB: but, percentages already have different meanings for different properties
16:34:29 [szilles]
EE: I think having calc inside min would solve most of the use case why should we do more
16:34:44 [fantasai]
EE: s/calc/calc and keywords/
16:35:00 [fantasai]
I think it's more important to allow keywords inside min than min inside calc
16:35:30 [szilles]
CL: The implementations that currently do not require spaces around "+" and "-" might change if keywords are allowed giving them a use case for the spaces
16:36:22 [szilles]
DG: Summary: I hear peoiple supporting both calc inside min and keywords
16:37:02 [szilles]
DG: I hear no objection to DB's proposal that min(x, y) is siyntactic sugar for calc(min(x,y))
16:38:01 [Bert]
I think "syntactic sugar" means: if the only thing inside calc() is another functional notation ("foo()"), then calc() can be left out.
16:38:41 [szilles]
Action: DG: negotiatie with HL to update his module with the above additions
16:38:41 [trackbot]
Created ACTION-168 - Negotiatie with HL to update his module with the above additions [on Daniel Glazman - due 2009-08-05].
16:39:15 [fantasai]
RESOLVED: add min() and max() to calc(), allowing min() and max() alone assuming wrapped calc()
16:39:23 [fantasai]
RESOLVED: allow keywords in expressions
16:41:37 [szilles]
CSS Media Queries
16:41:52 [fantasai]
Topic: Media Queries
16:41:55 [hyatt]
"happy" :)
16:42:15 [fantasai]
dsinger, there will be
16:42:18 [Bert]
rrsagent, pointer?
16:42:18 [RRSAgent]
16:42:42 [szilles]
AvK: What is the next step; do we publish a new draft
16:42:57 [dsinger_]
Sorry, Insufficient Access Privileges :-(
16:43:25 [dbaron]
rrsagent, make logs public
16:43:36 [szilles]
AvK: I can make edits to satisfy the 4 comments so far. Should the next step be WD or CR
16:43:40 [dsinger_]
16:44:21 [szilles]
BB: if the changes are only editorial then the new draft can also be a CR
16:44:53 [dbaron]
It might be nice to see a diff at some point (e.g., when we're about to make the decision to publish).
16:44:55 [szilles]
AvK: I will have a new draft for next week
16:45:11 [szilles]
Action: AvK: prepare new CR with the editorial changes
16:45:11 [trackbot]
Created ACTION-169 - Prepare new CR with the editorial changes [on Anne van Kesteren - due 2009-08-05].
16:46:18 [szilles]
DS: the media and audio tags allow a media query in the source selection; should the users accessability needs be added to thet query
16:46:39 [szilles]
CL: that sounds like a good idea
16:47:22 [szilles]
EE: people have said that they want different styling when an image is loaded, but this like the above should be in a future version
16:48:19 [szilles]
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
16:49:06 [szilles]
DS: The idea is that one could inquire about the accessability features that might be included in a given source file
16:49:23 [annevk]
media="all" media="all and (captioning)"
16:49:31 [oyvinds]
oyvinds has joined #css
16:49:34 [szilles]
Summary: people think this is a good idea
16:49:59 [glazou]
16:50:21 [szilles]
Specificity increass due to repetition of psuedoclasses
16:50:57 [hyatt]
seems hacky but legal to me
16:51:04 [szilles]
EE: yes, specificity inreases and multiple occurances are legal and it does work
16:51:17 [hyatt]
i'd hate to have to special case this to not increase specificity
16:51:18 [fantasai]
and it is hacky :)
16:51:24 [hyatt]
that would just create work for implementors
16:51:33 [szilles]
BB: it is a bit hacky and I am not sure it should increase specificity
16:51:59 [szilles]
SG: I would just like an example that shows that it is legal and it does increase specificity
16:52:31 [szilles]
PL: This is a giant hack and calling it out is bad form
16:52:45 [szilles]
DB: this applies to everything but tags
16:53:32 [szilles]
DG: it does not apply to tags because only one element selector is allowed per chain
16:54:17 [szilles]
Action: EE: Add a clarifying note to the selector to say multiple occurances are allowed and increase specificity
16:54:17 [trackbot]
Created ACTION-170 - Add a clarifying note to the selector to say multiple occurances are allowed and increase specificity [on Elika Etemad - due 2009-08-05].
16:54:50 [hyatt]
some of the pseudo elements are sufficiently complex (nth-child) that i suspect most implementors just do a list for selectors :)
16:54:56 [fantasai]
16:55:02 [szilles]
Box Shadow and Border Image
16:55:48 [szilles]
EE: I want to lock down a practical version of the spec. I would prefer leaving the spec as it currently is
16:56:14 [szilles]
EE: I posted my reasons for wanting this;
16:56:50 [szilles]
EE: The main question is how to handle "spreads";
16:58:37 [szilles]
CL: 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
16:59:24 [szilles]
PL: are we OK with saying the spread is (may be) ignored for borders (it works on boxes)
17:00:15 [szilles]
EE: I am happy with saying implementations may choose to implement spread on border images if they want
17:02:18 [szilles]
EE: I am arguing for the proposal posted by RC and DH, rather than what CL proposed; We want the UA to compute an appropriate shadow for a border imaged box
17:02:58 [szilles]
CL and DH: We should say "spread" is ignored for border-image
17:03:08 [glazou]
argl noise !
17:03:13 [dsinger_]
zakim, who is noisy?
17:03:23 [Zakim]
dsinger_, listening for 10 seconds I heard sound from the following: Bert (24%)
17:03:48 [Zakim]
17:04:11 [ChrisL]
zakim, drop bert
17:04:11 [Zakim]
Bert is being disconnected
17:04:12 [Zakim]
17:04:15 [ChrisL]
17:04:39 [glazou]
bert: but you were the only one :)
17:05:10 [glazou]
17:05:13 [szilles]
decision: allow CL time to read the RC/DH discussion
17:05:29 [Zakim]
17:05:30 [Zakim]
17:05:31 [szilles]
Adjourned at 10:05 PDT
17:05:32 [Zakim]
17:05:32 [Zakim]
17:05:34 [Zakim]
17:05:42 [Zakim]
17:05:47 [glazou]
17:05:51 [fantasai]
17:05:57 [Zakim]
17:06:05 [fantasai]
That's the start of the thread
17:06:15 [szilles]
Above is start of RC/DH discussion on shadows
17:06:29 [Zakim]
17:06:30 [Zakim]
Style_CSS FP()12:00PM has ended
17:06:31 [Zakim]
Attendees were +95089aaaa, +1.408.398.aabb, dsinger_, David_Baron, Daniel_Glazman, sylvaing, +49.238.aacc, Bert, +1.281.419.aadd, +1.858.216.aaee, fantasai, hyatt, plinss, SteveZ,
17:06:33 [Zakim]
... annevk, ChrisL, [Apple]
17:17:41 [sgalineau]
sgalineau has joined #css
17:23:03 [dbaron]
boy, Zakim forgot all the identification we did
18:01:43 [sgalineau]
sgalineau has joined #css
19:08:24 [sgalineau]
sgalineau has joined #css
19:23:01 [Zakim]
Zakim has left #CSS
19:41:22 [annevk]
annevk has left #css
19:48:18 [annevk]
annevk has joined #css
19:49:49 [dbaron]
dbaron has joined #css
21:01:29 [sgalineau]
sgalineau has joined #css
21:02:19 [dbaron_]
dbaron_ has joined #css
21:59:55 [szilles]
szilles has joined #css