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 http://www.w3.org/2009/07/29-CSS-irc
- 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]
- +[Mozilla]
- 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]
- +[Microsoft]
- 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]
- +??P32
- 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 http://www.muturzikin.com/countries.htm
- 16:04:26 [Bert]
- "Linguistic map of antarctica" and it isn't even empty...
- 16:04:27 [Zakim]
- +SteveZ
- 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]
- http://lists.w3.org/Archives/Public/www-style/2009Jul/0120.html
- 16:06:11 [annevk]
- Zakim, passcode?
- 16:06:14 [fantasai]
- STYLE
- 16:06:22 [dbaron]
- 78953
- 16:06:28 [Zakim]
- the conference code is 78953 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), annevk
- 16:06:35 [glazou]
- http://lists.w3.org/Archives/Public/www-style/2009Jul/0114.html
- 16:06:38 [szilles]
- Item: Background-break and border-break
- 16:07:00 [Zakim]
- +[IPcaller]
- 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]
- er
- 16:07:20 [annevk]
- hi
- 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]
- +ChrisL
- 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]
- http://lists.w3.org/Archives/Public/www-style/2009Jul/0014.html
- 16:18:49 [szilles]
- Mean and Max functions in CSS3
- 16:19:06 [dbaron]
- s/Mean/Min/
- 16:19:09 [glazou]
- http://lists.w3.org/Archives/Public/www-style/2009Jul/0015.html
- 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]
- +[Apple]
- 16:23:51 [Zakim]
- -dsinger_
- 16:23:55 [dsinger]
- zakim [apple] has dsinger
- 16:24:16 [sgalineau]
- +1
- 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]
- min(1em,thick)
- 16:27:04 [sgalineau]
- whoa
- 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]
- min(auto-10px,10%+2.5em)
- 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]
- See http://www.w3.org/2009/07/29-CSS-irc#T16-42-18
- 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_]
- q+
- 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]
- http://lists.w3.org/Archives/Public/www-style/2009Jul/0046.html
- 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]
- http://lists.w3.org/Archives/Public/www-style/2009Jul/0120.html
- 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]
- -[Mozilla]
- 17:04:11 [ChrisL]
- zakim, drop bert
- 17:04:11 [Zakim]
- Bert is being disconnected
- 17:04:12 [Zakim]
- -Bert
- 17:04:15 [ChrisL]
- :)
- 17:04:39 [glazou]
- bert: but you were the only one :)
- 17:05:10 [glazou]
- lol
- 17:05:13 [szilles]
- decision: allow CL time to read the RC/DH discussion
- 17:05:29 [Zakim]
- -ChrisL
- 17:05:30 [Zakim]
- -hyatt
- 17:05:31 [szilles]
- Adjourned at 10:05 PDT
- 17:05:32 [Zakim]
- -plinss
- 17:05:32 [Zakim]
- -[Microsoft]
- 17:05:34 [Zakim]
- -annevk
- 17:05:42 [Zakim]
- -Daniel_Glazman
- 17:05:47 [glazou]
- /quit
- 17:05:51 [fantasai]
- http://lists.w3.org/Archives/Public/www-style/2009Feb/0361.html
- 17:05:57 [Zakim]
- -[Apple]
- 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]
- -fantasai
- 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