IRC log of css on 2008-08-22

Timestamps are in UTC.

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