IRC log of css on 2012-02-07

Timestamps are in UTC.

07:23:25 [RRSAgent]
RRSAgent has joined #css
07:23:25 [RRSAgent]
logging to
07:26:04 [dbaron]
dbaron has joined #css
07:38:38 [glazou]
glazou has joined #css
07:43:09 [glazou]
07:43:18 [glazou]
RRSAgent, make logs public
08:07:08 [glazou]
glazou has joined #css
08:16:09 [Zakim]
Zakim has joined #css
08:17:18 [kojiishi]
kojiishi has joined #css
08:18:09 [dbaron]
dbaron has joined #css
08:18:47 [jdaggett]
jdaggett has joined #css
08:22:41 [TabAtkins_]
TabAtkins_ has joined #css
08:25:59 [sylvaing]
scribenick: sylvaing
08:26:05 [howcome]
howcome has joined #css
08:26:12 [smfr]
smfr has joined #css
08:26:22 [sylvaing]
howcome: I think we agreed we want to achieve modern magazine designs
08:26:28 [vhardy_]
vhardy_ has joined #css
08:26:30 [sylvaing]
howcome: we disagree how to reach that goal
08:26:38 [sylvaing]
howcome: I prefer a declarative approach
08:26:53 [sylvaing]
howcome: others prefer a hybrid approach that involves script
08:27:03 [florian]
florian has joined #css
08:27:03 [tantek]
tantek has joined #css
08:27:26 [sylvaing]
steve: I thought we came out of the discussion thinking that we needed declarative as well as scripting
08:28:00 [TabAtkins_]
08:28:19 [Rossen]
Rossen has joined #css
08:28:55 [antonp]
antonp has joined #css
08:29:05 [dglazkov]
dglazkov has joined #css
08:29:37 [sylvaing]
<successful re-enactment of yesterday's discussion>
08:30:23 [sylvaing]
tab: allowing the last region be auto-sized would help a lot
08:30:38 [alexmog_]
alexmog_ has joined #css
08:30:49 [sylvaing]
tab: being able to flow a region into a grid cell (which used to exist with ::slot) would also help
08:30:59 [florian]
florian has joined #css
08:31:01 [sylvaing]
tab: with those two combined, a large number of these layouts would be possible
08:31:16 [alexmog_]
08:31:32 [TabAtkins_]
08:31:36 [TabAtkins_]
zakim, ack
08:31:36 [Zakim]
I don't understand 'ack', TabAtkins_
08:31:40 [TabAtkins_]
08:31:42 [sylvaing]
vincent: the first one is something we have as an issue.
08:32:03 [sylvaing]
vincent: we also talked about making multicol a region; in particular make the last region a multicol
08:32:20 [sylvaing]
vincent: we'd also like to make a proposal for page templating
08:32:39 [jet]
jet has joined #CSS
08:32:47 [sylvaing]
rossen: our goal is to present a page template at the next f2f which would address basic region auto-generation needs
08:33:29 [sylvaing]
rossen: so this would allow us to go back to the regions spec now and work on known issues
08:33:51 [sylvaing]
alexmog: I think we generally disagree on the order of implementation
08:34:15 [tantek_]
tantek_ has joined #css
08:35:00 [sylvaing]
howcome: my concern is that the first implementations coming out will force the creation of dummy divs through script
08:35:19 [sylvaing]
alexmog: we only aim to enable implementation in this space and gather feedback
08:35:42 [ChrisL]
ChrisL has joined #css
08:36:10 [sylvaing]
alexmog: I'd like to discuss issues in the regions spec.
08:36:20 [tantek]
the Microsoft implementation of regions is -ms- prefixed right?
08:36:25 [sylvaing]
tantek, yes
08:36:47 [sylvaing]
howcome: i think a page template spec is necessary
08:36:58 [sylvaing]
howcome: regions and page templates should come together is necessary
08:37:24 [vhardy_]
08:38:07 [plinss]
08:38:12 [alexmog_]
08:38:43 [sylvaing]
vincent: I see it as a two step process. if we do allow regions to be multicol elements I think it mixes well with your solution
08:39:02 [sylvaing]
vincent: this provides a progression that doesn't require scripting
08:39:11 [plinss]
ack vhardy_
08:39:33 [sylvaing]
tab: is there any reason why all regions couldn't be multicols?
08:39:35 [sylvaing]
vincent: no
08:40:06 [sylvaing]
alexmog: can we put region issues on the agenda?
08:41:08 [sylvaing]
howcome: sure, i just don't want to make a general decision on whethe this is the right way forward until we have visibility into your general model
08:42:34 [sylvaing]
vincent: as a way forward we'll submit a page template, add support for multicols and paged overflow
08:42:47 [sylvaing]
vincent: at the f2f we can show something that's much more complete
08:43:13 [sylvaing]
florian: that way we'll be able to compare complete solutions based on use-cases
08:43:39 [sylvaing]
howcome: we should also look at Bert's proposal
08:44:06 [sylvaing]
08:44:51 [sylvaing]
howcome: we need a set of use-cases to evaluate the various proposals
08:46:21 [sylvaing]
jdaggett: I think it would also be useful to share presentation material like this on www-style in advance so as to gather feedback from a wider group
08:46:27 [Bert]
q+ to give example of what looking at a complete example can give
08:47:05 [sylvaing]
rossen: valid feedback, thank you
08:48:03 [sylvaing]
ACTION: vhardy Draft a page template proposal for the May f2f
08:48:04 [trackbot]
Created ACTION-422 - Draft a page template proposal for the May f2f [on Vincent Hardy - due 2012-02-14].
08:49:00 [sylvaing]
TOPIC: Regions issues
08:50:40 [dbaron]
vhardy: Should I put it on
08:50:43 [sylvaing]
Bert: region styling using @-rule is different from pseudo-element styling and creates inconsistencies
08:51:05 [dbaron]
daniel: of course; we have things there that aren't even in the charter; I won't entertain objections to that
08:51:41 [astearns]
astearns has joined #css
08:51:56 [sylvaing]
vincent: there was feedback at the last meeting on the way we presented issues and I wanted to start by showing how we dealt with that
08:52:13 [sylvaing]
vincent projects css3-regions ED
08:52:31 [sylvaing]
vincent: we're filing all the spec issues in Bugzilla
08:52:53 [sylvaing]
vincent: before then we only had issue markers in the spec
08:53:15 [sylvaing]
vincent: now all the issues in the spec link back to bugzilla, and the short description is shown in the margin
08:54:44 [sylvaing]
vincent: this is done in a scripted manner and matches them with the spec and appends them a report at the end of the spec. it lets you know whether new issues are not marked in the spec. this helps editing.
08:55:53 [sylvaing]
vincent: let me know how to make it more useful
08:56:20 [dbaron]
I didn't follow what the buttons at the bottom were supposed to do.
08:56:37 [ChrisL]
inline bug links in the spec are very useful
08:58:20 [ChrisL]
tools better in a subdirectory instead of littering the root
08:58:30 [sylvaing]
ACTION: vhardy Create a shared directory to post the bug helper script and document it on the wiki
08:58:30 [trackbot]
Created ACTION-423 - Create a shared directory to post the bug helper script and document it on the wiki [on Vincent Hardy - due 2012-02-14].
08:59:44 [sylvaing]
first bug was to add use-cases
08:59:46 [sylvaing]
we've done that
09:00:29 [sylvaing]
09:00:48 [sylvaing]
howcome: in addition to the CSS and HTML, it'd be useful to see any script that is needed to flow in more content
09:01:42 [sylvaing]
howcome: do you encourage others to add more to the wiki page?
09:01:43 [sylvaing]
vincent: yes
09:03:16 [sylvaing]
ACTION: vhardy make a generic use-case page linking to proposed markup solutions
09:03:16 [trackbot]
Created ACTION-424 - Make a generic use-case page linking to proposed markup solutions [on Vincent Hardy - due 2012-02-14].
09:03:31 [sylvaing]
RESOLVED bug 15159 is closed
09:03:52 [sylvaing]
09:04:03 [szilles]
szilles has joined #css
09:04:11 [sylvaing]
vincent: this is about creating regions declaratively
09:04:24 [sylvaing]
howcome: let's close it once there is a proposal
09:04:54 [sylvaing]
vincent: this will be solved in the template proposal
09:05:30 [sylvaing]
vincent: we'll update the bug to reference the pending action
09:06:16 [sylvaing]
09:07:00 [sylvaing]
vincent: originally the spec had a section on how regions integrated with different layout systems since regions don't create layout. this was taken out
09:07:16 [sylvaing]
vincent: then we explained how a region could be selected or created but this was not to be covered in the spec
09:08:05 [sylvaing]
vincent: but we were left with this example and we were asked to update it
09:09:18 [sylvaing]
vincent: the goal should be to indicate there is an overflow area and that should be item 4 in Figure 1
09:09:45 [sylvaing]
vincent: the point of the example is to show there is a catch-all area
09:10:31 [sylvaing]
ACTION: vhardy Make item 4 a multicolumn overflow
09:10:32 [trackbot]
Created ACTION-425 - Make item 4 a multicolumn overflow [on Vincent Hardy - due 2012-02-14].
09:10:41 [sylvaing]
howcome: <creep-laugh type="evil">
09:13:17 [sylvaing]
vincent: Bug 15186 is about auto-generation and is to be revisited with future proposals. Same for 15187.
09:13:39 [Bert]
(The example of 15131 doesn't really add a layout-based solution, does it? I still see empty HTML elements...)
09:14:19 [sylvaing]
09:14:34 [sylvaing]
alexmog: we are not proposing to flow content from external resources at the moment
09:15:03 [ChrisL]
09:15:10 [Bert]
09:15:16 [sylvaing]
alexmog: providing flow from external resources could be out of scope, or the Regions spec shouldn't restrict the origin of a resource
09:15:58 [sylvaing]
ChrisL: I don't think it should be out of scope since the alternative would be to write script to pull in content
09:16:08 [sylvaing]
alexmog: out of scope may be the wrong term
09:16:55 [dbaron]
09:17:03 [sylvaing]
alexmog: can regions assume that every element or node comes from the same origin?
09:17:21 [plinss]
ack next
09:17:23 [sylvaing]
alexmog: I think it's useful to assume it but it is limiting
09:17:46 [sylvaing]
dbaron: given the seamless iframes feature of HTLM5, I'm not sure how much this matters
09:17:46 [plinss]
ack next
09:17:58 [sylvaing]
dbaron: if you assume you have seamless iframes then you don't need features in CSS
09:18:07 [ChrisL]
is there a benefit to assuming that all the nodes are in the same document?
09:18:25 [ChrisL]
alex: yes, you can determine element order
09:18:39 [dbaron]
ack dbaron
09:18:49 [sylvaing]
alexmog: but we want to allow indirection into a different document without changing the style of this document
09:19:00 [sylvaing]
alexmog: seamless iframes does not have that option
09:19:24 [sylvaing]
alexmog: I have a options on the wiki but I am not yet ready to commit to any of them
09:19:58 [florian]
florian has left #css
09:20:10 [sylvaing]
09:20:12 [dbaron]
TabAtkins: there are security concerns with integrating iframes and, e.g., determining the height of the contents, without using the mechanisms in seamless iframes
09:20:31 [vhardy_]
09:20:53 [florian]
florian has joined #css
09:21:46 [sylvaing]
alexmog: one option involves using an iframe element; another uses a separate property; a third uses a flow rule. we can discuss these but work remains to evaluate the solutions as well as understand seamless iframes
09:21:58 [sylvaing]
tabatkins: this should be discussed on www-style as there are issues with it
09:22:18 [sylvaing]
alexmog: the Regions spec should note that the content of a named flow may come from another document
09:22:31 [sylvaing]
vincent: should we retitle the bug?
09:23:21 [glazou]
break time at 10:45am
09:23:29 [sylvaing]
vincent: we can note in the spec that the current version assumes the content comes from the same document pointing to an issue to resolve it later
09:23:48 [glazou]
TabAtkins_: selectors 4 after the break ?
09:24:28 [TabAtkins_]
glazou: I'm okay with that. Check with fantasai, since I think it's generally her topic.
09:25:17 [sylvaing]
Bert: this is not really a Regions issue but a general question of whether we can have replaced elements that are reflowing
09:25:34 [sylvaing]
vincent: how do we deal with this issue?
09:25:39 [sylvaing]
bert: put it on the agenda
09:25:49 [glazou]
fantasai: ok with that ?
09:27:35 [sylvaing]
ACTION: alexmog to rework 15811 as a general issue of replaced content and flow
09:27:35 [trackbot]
Sorry, couldn't find user - alexmog
09:28:06 [sylvaing]
09:28:49 [sylvaing]
vincent: the spec identifies the ICB for elements in regions
09:29:01 [sylvaing]
vincent: the defintiion was modeled on the page spec which uses the first page
09:29:36 [sylvaing]
vincent: based on use-cases involving a page preview we thought of using the first region as the ICB for the flowed content
09:29:59 [sylvaing]
vincent: feedback has been that this may not be always useful, and that the normal ICB should be used
09:30:08 [sylvaing]
vincent: we can also keep what we have
09:30:16 [sylvaing]
vincent: or we can provide a switch
09:30:55 [sylvaing]
alexmog: this is also relates to regions' interaction with stacking contexts
09:31:09 [plinss]
09:31:55 [sylvaing]
alexmog: if you model regions based on columns then they're not containing blocks for absolutely positoned elements
09:32:15 [Bert]
q+ to mention that the 'gr' units seems enough in my experiments.
09:32:33 [sylvaing]
anton: it's difficult to understand when you'll want to position within a region or within the wider document. a switch may be too hard to understand
09:33:02 [sylvaing]
plinss: from past feedback, we may want to be able to declare something to be a containing block
09:33:45 [sylvaing]
plinss: i like having a switch to control whether an element positions relative to the ICB but it shouldn't be region-specific. It should be in css3-break and apply to pages and maybe columns
09:33:58 [sylvaing]
vincent: so regions should not discuss this at all
09:34:37 [sylvaing]
ACTION: vhardy to move the issue to css3-break and remove the text from Regions
09:34:37 [trackbot]
Created ACTION-426 - Move the issue to css3-break and remove the text from Regions [on Vincent Hardy - due 2012-02-14].
09:35:23 [sylvaing]
Bert: I've found tha the gr unit should be enough to position objects independently of their containing block
09:36:22 [sylvaing]
steve: if you're simulating multicolumns or something like it, you need a different mechanism
09:37:16 [sylvaing]
alexmog: you may want positioned elements in your flow to start in a region and cover the next one, you don't want to be constrained by your container or its stacking context.
09:38:36 [sylvaing]
09:38:48 [sylvaing]
vincent: I don't have a proposal yet.
09:39:28 [sylvaing]
ACTION: vhardy to update region styling
09:39:28 [trackbot]
Created ACTION-427 - Update region styling [on Vincent Hardy - due 2012-02-14].
09:41:07 [sylvaing]
bert: there might potential confusion between styling the region itself and styling on the elements that end up in a region.
09:43:15 [sylvaing]
09:43:18 [fantasai]
glazou: would prefer css3-background / css3-text, save selectors 4 for tomorrow. Or later. I think I need more time to collect my thoughts and dig up examples from www-style
09:43:39 [sylvaing]
we were missing properties in the CSSOM
09:43:54 [Bert]
(If the div defines a grid and has a child p, then 'div::slot(a) {background: red}' sets a bg on the region, while 'p::slot(a) {background: yellow}' sets a bg only on the part of the p that ends up inside that region.)
09:43:59 [sylvaing]
we added a way to retrive flows by name and return a collection of existing named flows
09:44:08 [sylvaing]
(previous two comments by vincent)
09:44:13 [glazou]
fantasai: I want to have a chance to give my opinion on Tab's Hierarchies during this ftf
09:44:36 [sylvaing]
tabatkins: I'll suggest a different interface
09:44:49 [sylvaing]
glazou: <break>
09:58:10 [glazou]
glazou has joined #css
10:08:06 [fantasai]
Scribe: fantasai
10:08:13 [vhardy_]
ScribeNick: vhardy
10:08:14 [fantasai]
Topic: Nesting Style Rules
10:08:16 [TabAtkins_]
10:08:18 [glazou]
10:08:46 [Rossen]
Rossen has joined #css
10:08:51 [vhardy_]
daniel: i want to discuss this because people discovered the document and started to discuss it as if it was a wg draft. I modified it.
10:09:03 [vhardy_]
... it is a modification of the grammar. Technically, it is not in the charter.
10:09:18 [vhardy_]
... it is about nesting rules and reconstructing the selector based on the parent rule.
10:09:34 [vhardy_]
... the goal is to simplify the selector of the children rules. This has been requested for a long time.
10:09:41 [vhardy_]
... I have a lot of issues and questions.
10:09:55 [vhardy_]
... first the OM. Not enough. Selector text on the style rule is not enough.
10:10:41 [vhardy_]
... selector text is not meaningful, you need to reconstruct looking at the parent style rules.
10:11:09 [vhardy_]
tab: right now, there is only the nested selector. WOuld be more useful if we provided the expanded the selector, including the parent selectors.
10:11:24 [vhardy_]
peter: if you are going to change that, add an attribute to only get the local selector text.
10:11:49 [vhardy_]
daniel: there is a way to navigate the children rules from the parent rule, but not from the children rules to the parent rules.
10:11:55 [vhardy_]
tab: we are following media queries.
10:12:00 [vhardy_]
daniel: you do not say so.
10:12:19 [vhardy_]
tab: we are going to say we follow the structure of the @media rules. If something is missing, we will fix both of them.
10:12:29 [vhardy_]
daniel: I have a problem with example #5.
10:13:10 [vhardy_]
.... the third nested 'thing' have a rule followed by a declaration followed by a rule. This is an issue in the OM, becaues the declaration is stored in one 'thing' and nested rules are in another. Order cannot be maintained.
10:13:22 [vhardy_]
tab: I agree you should put your properties first.
10:13:30 [vhardy_]
daniel: the order should be mandatory.
10:13:50 [vhardy_]
tab: seems fine.
10:14:09 [vhardy_]
florian: I noted that the nested things last rather than first works better. That is where they should be if mandatory.
10:14:37 [vhardy_]
daniel: you are using the &. That could be an issue for embeded stylesheets because of encoding rules.
10:14:47 [vhardy_]
tab: not a problem in HTML.
10:15:11 [vhardy_]
daniel: I do not like the & because there are people will forget to use &amp;
10:15:26 [vhardy_]
... I think we should discourage that. I think this is a problem.
10:15:33 [vhardy_]
tab: Ok, I'll look for a replacement.
10:16:23 [vhardy_]
daniel: editability is a problem. When an editor needs to add a stylerule, you can look for a stylerule with the same selector. With nesting, it is way more complicated. You need to look for a nested style rules as well. It complexifies.
10:16:34 [vhardy_]
tab: if you have the full selector, does that simplify your work?
10:16:52 [jet]
jet has joined #CSS
10:16:57 [vhardy_]
daniel: when you insert a rule, you have to look for all the rules that have an effect in the cascade and modify them.
10:17:21 [vhardy_]
... I understand this is an important request from the user community, but I would like a clear issue created about editability.
10:17:35 [vhardy_]
.... for example, what will happen to legacy browsers.
10:17:46 [vhardy_]
tab: they will ignore the nested selectors.
10:17:53 [vhardy_]
daniel: will that be used?
10:18:00 [vhardy_]
tab: people love that feature.
10:18:39 [vhardy_]
jdagget: for things where we have not really taken on a module, could we have a clear marker, something that says this is a 'proposal', not an editor draft.
10:18:49 [vhardy_]
tab: yes, that is fine.
10:19:01 [vhardy_]
jdagget: the word 'proposal would be ok.
10:19:04 [vhardy_]
tab, others: ok.
10:19:14 [vhardy_]
steve: moving from proposal to ED is an action of the wg.
10:19:17 [vhardy_]
all: yes.
10:19:36 [vhardy_]
jdagget: I think this is better to have it here than on someone's blog.
10:19:53 [vhardy_]
... should be a proposal until the group takes it on.
10:20:21 [vhardy_]
chris: I did not quite understand the 'expand' the selector thing.
10:20:27 [glazou]
10:20:48 [vhardy_]
tab: yes, you have the entire selector.
10:20:54 [vhardy_]
chris: then it is duplicated.
10:21:41 [vhardy_]
tab: we are talking about selector text in the OM, not in the stylesheet. What is editable is still the short form.
10:21:57 [alexmog__]
alexmog__ has joined #css
10:22:34 [ChrisL]
example 4
10:22:35 [ChrisL]
div, p {
10:22:35 [ChrisL]
& .keyword, & .constant {color: red;}
10:22:35 [ChrisL]
10:22:47 [ChrisL]
is same as
10:22:48 [ChrisL]
div .keyword {color:red;}
10:22:48 [ChrisL]
div .constant {color:red;}
10:22:48 [ChrisL]
p .keyword {color:red;}
10:22:48 [ChrisL]
p .constant {color:red;}
10:22:57 [vhardy_]
daniel: In example 4, I would like a change. The parent rule has a group of selectors. The nested rule has a group of selector, if one of the selectors is invalid, the whole is invalid. So use groups in the expanded version of the example.
10:23:11 [vhardy_]
tab: changing the example right now.
10:23:19 [vhardy_]
daniel: I have a suggestion for editability.
10:27:01 [vhardy_]
... if you set the selector text, the implementation will need to match with as many parent selectors as possible to compute part of the selector only, and set that part of not. If it fails to compute the parent selector, it will throw an error. This is required, because the selector text is writable.
10:27:51 [vhardy_]
jdaggett: one way to implement it, then we could do it a parse time only thing.
10:28:05 [vhardy_]
(discussion about how this would be the same as the current server side solutions).
10:28:16 [vhardy_]
jdaggett: but it would make it easier to manipulate.
10:28:28 [vhardy_]
daniel: I do not think this is something we can _not_ do.
10:28:40 [vhardy_]
dbaron: I am not happy about the selector text expansion.
10:28:58 [vhardy_]
... it seems a bit lossy in that you might want the thing with the &, it will be hard to get that.
10:29:11 [vhardy_]
daniel: the part with the & is the selector text of the parent rule.
10:29:18 [vhardy_]
dbaron: no, the local part.
10:29:28 [vhardy_]
(all) we are introducing a way to get the local part.
10:29:50 [vhardy_]
dbaron: one advantage of making the new one expanded is that we can make it read-only.
10:30:07 [vhardy_]
daniel: I do not have a strong opinion, either way.
10:30:28 [vhardy_]
... I just need both for reading and oupting.
10:30:44 [vhardy_]
... to compute the style, I need both.
10:30:54 [vhardy_]
... for writing I only need the local part.
10:31:07 [vhardy_]
... with that, I think editors can work with such a specification, it is doable.
10:31:19 [vhardy_]
... this said, the question is, do we want to work on this?
10:31:31 [vhardy_]
... do we have CSS grammar in the charter for the next 3 years.
10:31:47 [vhardy_]
tab: we have other specs, that will modify the grammar or tweak it.
10:32:01 [vhardy_]
... CSS conditionals will do that for example.
10:32:17 [vhardy_]
daniel: section 2 of the charter says that CSS syntax is discontinued.
10:32:26 [vhardy_]
chris: this just means that draft is not further developed.
10:32:45 [vhardy_]
daniel: if we want to work on that, we have to find a landing spot in the existing charter deliverables or extand the charter.
10:32:55 [vhardy_]
chris: or we can fit in the existing charter.
10:33:10 [vhardy_]
... syntax is in the scope section, so we are fine.
10:33:17 [vhardy_]
daniel: I needed to check that.
10:33:29 [vhardy_]
jdagget: the bigger question is the priority.
10:33:43 [vhardy_]
... it is possibly disruptive. There are a lot of things to work out.
10:33:58 [vhardy_]
daniel: this is the kind of item that the author community is looking for.
10:34:14 [vhardy_]
tab: error recovery rules are working nicely here.
10:34:28 [vhardy_]
jdagget: this has a non trivial cost. We already have a lot that we need to get done.
10:34:37 [vhardy_]
chris: yes, we have a priority list already.
10:34:52 [vhardy_]
... the important question is the relative priority.
10:35:01 [vhardy_]
peter: is there interest from implementors to implement this.
10:35:14 [vhardy_]
... if there is only one implementor, then we will not get to REC.
10:35:58 [vhardy_]
florian: from an Opera point of view, I can easily see how people want that, but it is not at the top of our priority list.
10:36:29 [vhardy_]
vhardy: we think this is an important feature for web authors.
10:36:36 [vhardy_]
sylvain: no plans right now.
10:36:46 [vhardy_]
dbaron: there is a bunch of other things that are higher priorities.
10:37:12 [vhardy_]
sylvain: selector 4 is more important.
10:38:47 [vhardy_]
daniel: I think it is clear there will not be commitment from the wg members to work on this right now.
10:39:07 [vhardy_]
peter: do we want to keep this on the shelve as a proposal or do we take it as a WD?
10:39:27 [vhardy_]
jdagget: I think we should keep it as a proposal and ask Tab to mark it as a proposal.
10:39:52 [vhardy_]
vhardy: what are the more important things?
10:40:34 [vhardy_]
ACTION: Tab to mark the nested selector spec. as a proposal.
10:40:35 [trackbot]
Created ACTION-428 - Mark the nested selector spec. as a proposal. [on Tab Atkins Jr. - due 2012-02-14].
10:41:28 [tantek]
tantek has joined #css
10:41:48 [vhardy_]
vhardy: from the feedback we get, nested selectors, mixins and variables are really important.
10:45:10 [tantek_]
tantek_ has joined #css
10:46:43 [tantek_]
tantek_ has joined #css
10:47:01 [howcome]
howcome has joined #css
10:47:07 [fantasai]
10:53:31 [vhardy_]
Topic: Fullscreen
10:54:07 [dbaron]
10:54:39 [vhardy_]
daniel: Art is asking if we have comments / objections to Web apps working on this.
10:54:47 [vhardy_]
chris: I think it should be in web apps.
10:54:56 [vhardy_]
tantek: there are presentation aspects, right?
10:55:05 [vhardy_]
daniel: yes, there are presentation side effects.
10:55:12 [vhardy_]
... but it is mainly an API.
10:55:37 [vhardy_]
tantek: this is already in our charter. Art is asking to propose it for their Web apps charter. Why the extra work to put it in the web apps group.
10:55:51 [vhardy_]
chris: Anne is willing to do it in the web apps group and he is a member there.
10:56:11 [vhardy_]
daniel: there is, in our charter, to do full screen only for CSS, not in general.
10:56:17 [vhardy_]
... it is not limited to css.
10:56:30 [vhardy_]
fantasai: then it should be a joined effort.
10:56:39 [vhardy_]
daniel: yes, the css part we do, the api they do.
10:56:46 [fantasai]
10:57:08 [vhardy_]
chris: while we are talking about this type of cooperation, it strikes me that the CSS OM is that something that should be done as a joint effort between the two groups.
10:57:32 [CGI232]
CGI232 has joined #css
10:57:50 [vhardy_]
tantek: I think we have broader dissipation in this group from different companies. From an early exposure to commit patent ip, this group is better than the Web apps group, seeing what happened with touch events.
10:58:04 [vhardy_]
... css wg is better than web apps in that way.
10:58:14 [vhardy_]
... so the work should be done here.
10:58:47 [vhardy_]
tantek: the web apps wg does not have as many companies, so if the work is done in the CSS wg, we stand a better chance to get disclosures/exclusions sooner than later.
10:59:00 [vhardy_]
... touch events has been blocked by a patent from Apple.
10:59:12 [vhardy_]
... since they are not in the web apps working group, they could do that.
10:59:34 [vhardy_]
tantek: so it is better to do this work, from an IP point of view, in the CSSWG.
10:59:43 [vhardy_]
florian: what are the implications of joint work?
11:00:21 [vhardy_]
chris: the union of the membership of both groups has the same disclosure obligations over the entire spec.
11:00:34 [vhardy_]
tantek: I have not problem co-editing with Anne.
11:00:43 [vhardy_]
11:01:15 [vhardy_]
daniel: my next question: does the group feel taht the argument tantek give about size and IPr rule are the arguments I should present to Art?
11:01:27 [vhardy_]
florian: working jointly is the option we should present.
11:01:48 [vhardy_]
bert: the argument about members is not strong, because they have Apple and they have companies that we do not have.
11:03:05 [vhardy_]
tantek: for example, Flash has a fullscreen API and Adobe is not a member of the Web Apps wg.
11:03:30 [vhardy_]
peter: I agree with you, but if you are trying to bring everybody under the tent, then you may force someone out of the tent. This is a risk.
11:03:52 [vhardy_]
florian: however, full screen is already in the charter.
11:04:05 [vhardy_]
tantek: but hte disclosure requirements happen at FPWD time.
11:04:31 [vhardy_]
daniel: so we will propose for a joint effort?
11:05:02 [vhardy_]
ACTION: daniel to answer Art about joint work between CSS and Web Apps WG on fullscreen CSS and APIs.
11:05:02 [trackbot]
Sorry, amibiguous username (more than one match) - daniel
11:05:02 [trackbot]
Try using a different identifier, such as family name or username (eg. dglazman, dweck2)
11:05:55 [vhardy_]
Topic: Schedule for Snapshot 2012: end or start of the year?
11:06:25 [vhardy_]
peter: last time we discussed it, we said we would do a snapshot every year.
11:06:38 [vhardy_]
bert: is that what worked before 2012 or starting 2012?
11:07:05 [vhardy_]
chris: if you publish at the end of 2012, then people think they are dealing with an old spec.
11:07:31 [vhardy_]
fantasai: we can publish at any point, but the question, is, do we expect to add things to the snapshot (and have test suite).
11:07:42 [vhardy_]
.. I thinjk we are just going to republish with a new date.
11:07:50 [vhardy_]
11:07:59 [vhardy_]
dbaron: 2d transform could be there.
11:08:03 [vhardy_]
peter: media queries.
11:08:15 [vhardy_]
tab: images will have a test suite.
11:08:37 [vhardy_]
fantasai: we also need at least an implementation that passes most of the testsuite and failures understood.
11:08:49 [vhardy_]
chris: this is still a prediction: we expect things to get out of CR soon.
11:09:08 [vhardy_]
fantasai: yes, e.g., MQ made it because we understood the failures and there was a test suite and implementation.
11:09:30 [vhardy_]
chris: if the point is to publish one every year, then we would sometimes republish the same thing.
11:09:58 [vhardy_]
peter: we should publish at least once a year. We may publish several times a year.
11:10:17 [vhardy_]
... it is just a note about the current state of the world and we update as necessary but at least once a yaer.
11:10:42 [vhardy_]
steve: we need to indicate some level of stability, but publishing a new number if there is no changes is not useful.
11:10:56 [vhardy_]
peter: i think there is a benefit.
11:11:15 [vhardy_]
... if there isn't one that is current, which one do you look at?
11:11:20 [vhardy_]
steve: the most recent one.
11:11:54 [vhardy_]
peter: this is the problem with open type projects. If something is not updated, you do not know if this is because people did not publish the update or because nothing is happening. This has value.
11:12:01 [vhardy_]
steve: ok, understood.
11:12:26 [vhardy_]
peter: so I would like to publish snapshot 2012 asap and we will republish immediately if new things are eligible.
11:12:33 [vhardy_]
bert: I think that is too often.
11:12:45 [vhardy_]
... publishing often seems unstable.
11:13:01 [vhardy_]
chris: we need to communicate that the stability state has changed.
11:13:21 [vhardy_]
bert: ... people can wait 6 months.
11:13:39 [vhardy_]
chris: we give people a short spec. that says what is stable.
11:14:10 [vhardy_]
peter: the snapshot is a note, it is easy to publish. It is for communication.
11:14:33 [vhardy_]
tantek: I think we should update the snapshot everytime a spec. goes to CR.
11:14:53 [vhardy_]
several: that is not the criteria, the criteria is that the spec. is almost ready to exit CR.
11:15:01 [vhardy_]
steve: once a year is fine.
11:15:30 [vhardy_]
tantek: I propose to publish at the begining of the year.
11:15:32 [vhardy_]
several: yes.
11:16:54 [vhardy_]
RESOLUTION: the CSS snapshot will be published once a year, at the begining of the year, and every time a new specification meets the criteria for being listed in the snapshot note.
11:17:13 [vhardy_]
ACTION: Fantasai to publish snapshot 2012 ASAP>
11:17:13 [trackbot]
Created ACTION-429 - Publish snapshot 2012 ASAP> [on Elika Etemad - due 2012-02-14].
11:17:53 [vhardy_]
Topic: Media Queries REC
11:19:09 [vhardy_]
fantasai: we need an implementation report.
11:19:17 [vhardy_]
florian: what is the status of the test suite?
11:19:26 [vhardy_]
peter: it was being reworked.
11:19:33 [vhardy_]
fantasai: that does not make the tests invalid.
11:19:51 [vhardy_]
chris: this is a case of what you use for generating the report.
11:20:05 [vhardy_]
(history of the test suite and who contributed).
11:20:58 [vhardy_]
peter: the test suite has sufficient coverage of the spec?
11:21:35 [dbaron]
11:21:42 [ChrisL]
11:22:03 [vhardy_]
dbaron: I think we need to publish a new snapshot of the test suite.
11:22:20 [vhardy_]
ACTION: fantasai to publish a new snapshot of the MQ test suite.
11:22:21 [trackbot]
Created ACTION-430 - Publish a new snapshot of the MQ test suite. [on Elika Etemad - due 2012-02-14].
11:23:20 [plinss]
MQ test suite source:
11:23:49 [vhardy_]
daniel: implementation reports by?
11:23:57 [vhardy_]
Mozilla, Opera
11:24:57 [vhardy_]
ACTION: dbaron to provide an implementation report for the MQ test suite.
11:24:57 [trackbot]
Created ACTION-431 - Provide an implementation report for the MQ test suite. [on David Baron - due 2012-02-14].
11:25:13 [vhardy_]
ACTION: florian to provide an implementation report for the MQ test suite.
11:25:13 [trackbot]
Created ACTION-432 - Provide an implementation report for the MQ test suite. [on Florian Rivoal - due 2012-02-14].
11:26:24 [ChrisL]
testing Version
11:26:24 [ChrisL]
12.00 alpha
11:26:24 [ChrisL]
11:26:24 [ChrisL]
11:26:41 [ChrisL]
Passed: 254
11:26:41 [ChrisL]
Failed: 107
11:28:19 [vhardy_]
ACTION: smfr to provide an implementation report for the MQ test suite.
11:28:20 [trackbot]
Created ACTION-433 - Provide an implementation report for the MQ test suite. [on Simon Fraser - due 2012-02-14].
11:29:43 [vhardy_]
===== LUNCH BREAK ======
11:34:33 [Ms2ger]
Ms2ger has joined #css
11:35:36 [lhnz]
lhnz has joined #css
12:08:29 [Ms2ger]
Ms2ger has joined #css
12:16:38 [Ms2ger]
Ms2ger has joined #css
12:17:06 [Zakim]
Zakim has left #css
12:37:17 [jdaggett]
jdaggett has joined #css
13:03:53 [smfr]
smfr has joined #css
13:07:27 [tantek]
tantek has joined #css
13:09:42 [smfr]
13:09:48 [tantek_]
tantek_ has joined #css
13:09:49 [glazou]
glazou has joined #css
13:09:53 [dbaron]
dbaron has joined #css
13:10:03 [fantasai]
Scribe: fantasai
13:10:27 [fantasai]
Topic: WebKit Prefix Conversations
13:10:32 [fantasai]
plinss: Had various offline conversations.
13:10:47 [fantasai]
plinss: Tantek / roc talking about creating this list of properties they're considering for webkit prefixing
13:11:01 [fantasai]
plinss: Would like that list given to WG ASAP
13:11:07 [kojiishi]
kojiishi has joined #css
13:11:29 [fantasai]
plinss: Rather than vendors making blog posts saying "this is what we're going to do", would rather vendors brought these lists to us so we can reset our priorities
13:12:01 [fantasai]
plinss: There is market interest in these properties. They are ready to be implemented, or already implemented, interoperably by multiple vendors. Therefore they meet the criteria to be standardized
13:12:15 [fantasai]
plinss: No reason they shouldn't be standardized immediately.
13:12:39 [fantasai]
plinss: If vendors feel there is sufficient market pressure tha it's rucial to their business, that should be our highest priority.
13:12:49 [fantasai]
plinss: So I would like to get buy-in from the group that this is the right approach.
13:13:02 [fantasai]
plinss: Would like commitment from vendors considering this to talk to us, let us address this as quickly as possible.
13:13:21 [jet]
jet has joined #CSS
13:13:26 [fantasai]
Florian: I'm convinced this is a good idea. Concerned it's not sufficient, but regardless we need to do it.
13:13:54 [fantasai]
plinss: I accept it may not be sufficient. I hope it is. But we should as a WG do what we can to alleviate this market pressure.
13:14:24 [fantasai]
plinss: Asking for commitment to get this list from vendors asap, and bring it first to WG not to vendor blogs
13:14:54 [fantasai]
glazou: .... expand the evangelism commmunity.
13:15:02 [fantasai]
glazou: let's try everything before going to the last resort
13:15:11 [fantasai]
glazou: I have two options for the article. Can call community at large.
13:15:36 [fantasai]
Florian: Idea is a call to the community at large to be responsible for how they use prefixes.
13:15:46 [fantasai]
Florian: vendors have tried that on their own, he's suggesting to do it together.
13:16:27 [fantasai]
plinss: I think if we have 2-3 vendors effectively agree on an implementation, whether it's because they like it or they're locked into it, that's sufficient for us to declare that it's enough for us to drop prefixes.
13:16:35 [fantasai]
plinss: Then we can call on all sites to drop prefixes.
13:16:50 [fantasai]
glazou: Want to move from de facto to de jure standards.
13:17:01 [fantasai]
tantek: Daniel, such an article might help. Need to point out 2 things.
13:17:10 [fantasai]
tantek: First, point out that -webkit- is hurting the web.
13:17:21 [fantasai]
tantek: 2 problems. First is UA-sniffing, only providing modern web content to webkit
13:17:35 [fantasai]
tantek: 2nd problem is that there are numerous features that work effectively interoperably across browsers
13:17:51 [fantasai]
tantek: That if those sites put multiple prefixes today, without any change from this group, they would work.
13:18:10 [fantasai]
glazou: Even if we're not sure that it will work, I think it is worht trying. I don't want us to take last resort option without trying.
13:18:42 [fantasai]
tantek: We'd rather sites provided full content to Mozilla and have it break, than provide dumb content to us. I think we're fixing things fast enough that we can respond to that. But it's the webkit-only coding that is harmful.
13:19:07 [fantasai]
glazou: Let's suppose it works a bit, and you see a trend of websites adding properties and not sniffing. Will that be sufficient for you to decide to wait?
13:19:25 [fantasai]
tantek: Will look at data on a case-by-case basis. If data changes, conclusions may change.
13:19:32 [fantasai]
plinss: Need to tackle this on all fronts.
13:19:50 [fantasai]
plinss: Need to evaluate list of properties, resolve to drop prefixes for those that are ready.
13:20:17 [fantasai]
tantek: I don't want to provide a list of properties, because I don't want anything that developers can depend on.
13:20:50 [fantasai]
fantasai: What about providing a list to the CSSWG list?
13:20:55 [fantasai]
tantek: Might change over time.
13:21:05 [fantasai]
Florian: Peter asked for the list to set priorities.
13:21:22 [fantasai]
Alan: Should emphasize that can use all prefixed versions right now, and without any changes by us, will work today.
13:21:31 [fantasai]
Alan: And we should be trying to drop prefixes on the things that work in that way.
13:21:43 [fantasai]
Tantek: We already have that focus in the WG. But things that are outstanding measures in the WG.
13:22:00 [fantasai]
13:22:29 [fantasai]
plinss: The moment you have sufficient data about one property. If nothing else, send it to Daniel and I, so that we can make it #1 priority on the next telecon.
13:22:56 [fantasai]
plinss: My assertion is, just like we were driving 2.1 to REC, that was highest priority. I'm offering you and Opera and MS, that level of priority if you get to that point on any property.
13:23:08 [fantasai]
plinss: That will be the #1 focus of the group to drop that prefix.
13:23:36 [fantasai]
tantek: Ok. I'm willing to put that on css-wg list. Don't want to kick of some kind of flamewar on www-style. Minutes of discussion will of course be public.
13:23:51 [fantasai]
tantek: We may wind up posting list to wiki page, but we have better things to do than write blog posts aobut it.
13:24:11 [fantasai]
plinss: If we can help the situation by dropping the prefix, we will drop the prefix.
13:25:07 [ChrisL]
pointer to prefixing policy doc?
13:25:39 [TabAtkins_]
TabAtkins_ has joined #css
13:26:06 [smfr]
13:27:08 [fantasai]
fantasai: Note that we do have a loophole in the vendor-prefixing policy that the WG can declare an experimental property to be implemented prefixless *for legacy reasons*. This was originally for things like text-overflow, but existing webkit-only content on the web also qualifies as a legacy reason.
13:27:25 [fantasai]
fantasai: So if we have a spec that we cannot move fast enough to CR, we can use that loophole to drop prefixes immediately.
13:29:09 [fantasai]
fantasai: [says stuff]
13:29:14 [fantasai]
smfr: [1-3 months]
13:29:19 [fantasai]
fantasai: Will that happen?
13:30:09 [fantasai]
smfr: We can make that happen.
13:30:28 [fantasai]
Tantek: How about we go to CR with open issues?
13:30:49 [fantasai]
fantasai: What's the point of that? The CR transition requires no open issues. If your problem is you want to drop prefixes with open issues, then drop prefixes before CR.
13:30:55 [szilles]
szilles has joined #css
13:31:15 [fantasai]
jdaggett: You can defer issues, e.g. mark things undefined.
13:31:55 [fantasai]
13:32:42 [fantasai]
Tantek: You'll get issues faster than you can evaluate them, just like 2.1
13:33:04 [fantasai]
fantasai: We haven't had that problem to the extent we had it with 2.1 with our CSS3 modules
13:33:11 [fantasai]
fantasai: What do you want out of moving to CR?
13:33:15 [fantasai]
Tantek: Dropping prefixes
13:33:25 [fantasai]
fantasai: So let's drop prefixes and not change the definition of CR, what's the problem?
13:33:33 [fantasai]
Tantek: ...
13:34:07 [fantasai]
Tantek: I think it's more important to use CR as a marker for dropping prefixes than a marker for closing issues.
13:34:27 [fantasai]
Tantek: ...
13:34:59 [fantasai]
plinss: To make progress faster, as a group, we can drop prefixes before CR. And if there's a singificant portion that is stable and has no issues, is ready to go to CR, we split the spec.
13:35:18 [fantasai]
plinss: And we are also willing to run through issues and solve or defer them quickly.
13:35:28 [fantasai]
plinss: We have three different avenues and we're willing to use them all as needed.
13:35:32 [fantasai]
Tantek: Sounds good.
13:36:01 [fantasai]
Topic: Backgrounds and Borders
13:36:12 [TabAtkins_]
ScribeNick: TabAtkins_
13:36:15 [fantasai]
13:36:22 [TabAtkins_]
fantasai: Bert and I have been going through the B&B issues.
13:36:35 [TabAtkins_]
fantasai: There are a couple open ones, with proposed reoslutions, but we need the WG to evaluate them.
13:36:46 [TabAtkins_]
fantasai: First is bidi reordering and the application of box-decoration:break
13:36:53 [fantasai]
13:37:04 [vhardy_]
vhardy_ has joined #css
13:37:07 [TabAtkins_]
fantasai: After the discussion with dbaron, I edited in text that says UAs *may* apply box-decoration to control rendering at bidi-imposed breaks.
13:37:13 [fantasai]
"UAs may also apply ‘box-decoration-break’ to control rendering at bidi-imposed breaks, i.e. when bidi reordering causes an inline to split into non-contiguous fragments. Otherwise such breaks are always handled as ‘slice’. "
13:37:17 [TabAtkins_]
fantasai: Otherwise, such breaks are handled as slice.
13:37:21 [TabAtkins_]
fantasai: Are people happy with this?
13:37:44 [TabAtkins_]
TabAtkins_: Is there a particular reason to keep it optional right now?
13:37:44 [glenn]
glenn has joined #css
13:37:52 [TabAtkins_]
dbaron: We don't have a strict definition of where bidi breaks happen.
13:38:17 [TabAtkins_]
dbaron: And we probably, in reality, want to split breaks into two groups, one of which pays attention ot the property, and the other which always slices.
13:38:29 [TabAtkins_]
fantasai: This is a weird edge case, so this lets the UA do whatever makes sense right now.
13:39:28 [TabAtkins_]
fantasai: The default behavior is 'slice' (the easy case), so the suggested solution is to optionally apply 'break' when specified if the UA has a good way to do it.
13:39:39 [TabAtkins_]
dbaron: Is it conformant to do a split between the two?
13:39:54 [TabAtkins_]
fantasai: I don't think it's conformant with this wording.
13:40:13 [TabAtkins_]
dbaron: I think it's the most sensible behavior, at least given by the way we consider these breaks to exist.
13:40:26 [TabAtkins_]
fantasai: That's why we have the term "contiguous".
13:40:54 [TabAtkins_]
dbaron: I want tests in the test suite for this.
13:41:01 [TabAtkins_]
fantasai: Ok.
13:41:16 [TabAtkins_]
[no further objections]
13:41:30 [TabAtkins_]
fantasai: Next issue is the corner transitions in border-radius
13:41:32 [fantasai]
13:41:57 [TabAtkins_]
fantasai: The spec as I brought up before is *completely* wrong. But we don't have a good definition for the right behavior, so the idea right now is to make it officially undefined for now.
13:41:57 [fantasai]
Color and style transitions must be contained within the segment of the border that intersects the smallest rectangle that contains both border radii as well as the center of the inner curve (which may be a point representing the corner of the padding edge, if the border radii are smaller than the border-width).
13:42:02 [fantasai]
If one of these borders is zero-width, then the other border takes up the entire transitional area. Otherwise, the center of color and style transitions between adjoining borders must be proportional to the ratio of the border widths such that a function of its location is continuous with respect to this ratio. However it is not defined what these transitions look like or how “proportional” maps to a point on the curve.
13:42:17 [TabAtkins_]
fantasai: This way, the spec is at least not *wrong*, and we can figure out the correct behavior in level 4.
13:43:06 [TabAtkins_]
fantasai: [explains the above text]
13:43:57 [TabAtkins_]
plinss: Didn't we discuss this at TPAC?
13:44:10 [TabAtkins_]
fantasai: We did, and concluded we needed to investigate a lot more before we could correctly specify it.
13:44:21 [TabAtkins_]
fantasai: This way, we're defining the important bits that people rely on.
13:44:42 [TabAtkins_]
fantasai: Like that a zero-width border won't contribute any visible color.
13:45:45 [TabAtkins_]
fantasai: And that larger borders are proportional in some way.
13:45:54 [TabAtkins_]
sylvaing: What's the important bit, precisely, and who depends on it?
13:46:37 [TabAtkins_]
fantasai: One example is a box with only a border on top that curves around. The sides will usually just be currentColor, and authors don't expect that to show up.
13:47:29 [drublic]
drublic has joined #css
13:47:57 [TabAtkins_]
tantek_: I think we could instead hook that to border-style. If the side is border-style:none, don't show any of the dest color. But if it's solid, even if it's 0px, when you do a gradient it should fade to that.
13:48:07 [howcome]
howcome has joined #css
13:48:36 [Rossen]
Rossen has joined #css
13:48:47 [TabAtkins_]
Bert: I think that's what Konqueror does.
13:48:49 [fantasai]
fantasai: So you want to replace 'zero-width' with 'none or hidden'.
13:49:04 [TabAtkins_]
dbaron: I think that removes the continuity argument.
13:49:21 [TabAtkins_]
Bert: Not sure. We need more research, or to leave it open.
13:49:37 [TabAtkins_]
tantek_: I'm okay with leaving it open, I just wanted to present it as a use-case.
13:49:49 [TabAtkins_]
fantasai: So if you wanted to use a double or dashed border...
13:50:35 [TabAtkins_]
tantek_: Borders historically have been places where we allow impls to give better results, rather than locking them into an LCD.
13:51:08 [TabAtkins_]
fantasai: So we still want to define, at least in the 'none' case, that the entire visible border is the color of the non-'none' border.
13:51:25 [TabAtkins_]
fantasai: But that makes dbaron unhappy.
13:52:15 [TabAtkins_]
dbaron: I don't think the color at the corner is ever what's desirable.
13:52:33 [TabAtkins_]
fantasai: So how should we resolve this?
13:52:40 [TabAtkins_]
dbaron, smfr: I'm happy leaving it as it is.
13:53:37 [TabAtkins_]
plinss: Can we resolve to accept the text in the editor's draft?
13:53:43 [TabAtkins_]
[no objection]
13:53:50 [fantasai]
13:53:51 [TabAtkins_]
fantasai: Next issue, define the default shadow color.
13:54:08 [TabAtkins_]
RESOLVED: Accept the ED text for border-transitions.
13:54:43 [TabAtkins_]
RESOLVED: Accept the proposed resolution for bidi splits and box-break
13:55:15 [fantasai]
Options mentioned so far:
13:55:16 [fantasai]
- black
13:55:16 [fantasai]
- rgba(0,0,0,0.5)
13:55:16 [fantasai]
- currentColor
13:55:16 [fantasai]
- currentColor except it doesn't compute until after inheritance
13:55:18 [fantasai]
- make <color> required
13:55:27 [TabAtkins_]
fantasai: There's a bunch of options: 'black', 'rgba(0,0,0,.5)', 'currentColor', 'currentColor, but used-value time', or require it be defined.
13:55:59 [TabAtkins_]
dbaron: Are we discussing box-shadow, or text-shadow as well? And what do the specs currently say?
13:56:11 [TabAtkins_]
fantasai: Both, and they shoudl be consistent. They both say "UA defined" right now.
13:57:37 [TabAtkins_]
dbaron: Gecko seems to use currentColor for both shadows, almost.
13:58:03 [TabAtkins_]
dbaron: I think, though, that on text-shadow, if the text decorations are a different color form the text, the default shadow *on the decorations* will match the decoration color.
13:59:15 [fantasai]
fantasai: Ok, so 6 options (for text-shadow; doesn't make a difference for box-shadow)
13:59:24 [TabAtkins_]
plinss: Any opinions?
14:01:07 [dbaron]
data:text/html;charset=utf-8,<!DOCTYPE html><span style%3D"text-decoration%3A underline%3B color%3A blue"><span style%3D"text-decoration%3A overline%3B color%3A fuchsia%3B"><span style%3D"color%3A orange%3B text-shadow%3A 20px 20px">hello<%2Fspan><%2Fspan>
14:01:20 [TabAtkins_]
dbaron: Above data url confirms Gecko's text-shadow handling.
14:01:49 [TabAtkins_]
smfr: I think WebKit defaults to transparent.
14:03:53 [TabAtkins_]
fantasai: We could still make it required.
14:04:01 [TabAtkins_]
dbaron: I'm not comfortabl ewith a syntax change at this point.
14:04:08 [TabAtkins_]
dbaron: Opera doesn't shadow decorations at all.
14:04:34 [fantasai]
Tab: When we do equivalent of fill on text, filling text with images, what will text-shadow do then?
14:04:55 [fantasai]
Florian: Will it behave like stained glass or not?
14:05:23 [fantasai]
smfr: I think black as a default color would be easier to understand.
14:05:31 [fantasai]
Tab: Given we have random answers right now, we could pick anything.
14:05:52 [dbaron]
data:text/html;charset=utf-8,<!DOCTYPE html><span style%3D"text-decoration%3A underline%3B color%3A blue"><span style%3D"text-decoration%3A overline%3B color%3A fuchsia%3B"><span style%3D"text-decoration:line-through;color%3A orange%3B text-shadow%3A 20px 20px">hello<%2Fspan><%2Fspan>
14:07:05 [fantasai]
[people run tests on various UAs]
14:08:21 [TabAtkins_]
sylvaing: IE10 shadows text and decorations both with the currentColor.
14:10:54 [fantasai]
[discussing defaulting to black]
14:11:07 [fantasai]
Bert: we have an implementation: Konqueror defaults to black
14:11:31 [dbaron] says to use the current color
14:12:28 [TabAtkins_]
[everyone checks what the default for box-shadow is in UAs]
14:12:46 [dbaron]
data:text/html;charset=utf-8,<!DOCTYPE html><span style%3D"text-decoration%3A underline%3B color%3A blue"><span style%3D"text-decoration%3A overline%3B color%3A fuchsia%3B"><span style%3D"text-decoration:line-through;color%3A orange%3B text-shadow%3A 20px 20px;box-shadow: 40px 40px">hello<%2Fspan><%2Fspan>
14:15:31 [fantasai]
Proposed to make box-shadow default to the value of the 'color' property on the element being shadowed. computed value doesn't have a color if it's not specified.
14:16:04 [fantasai]
RESOLVED: box-shadow as above
14:16:34 [TabAtkins_]
fantasai: We fixed some definitions surrounding border-image and SVG. We need review to ensure they're correct.
14:17:01 [TabAtkins_]
fantasai: [explains the text in the spec]
14:17:06 [fantasai]
14:17:11 [fantasai]
If the image must be sized to determine the slices (for example, for SVG images with no intrinsic size), then it is sized as for an auto-sized background, using the border image area as the default object size in place of the background positioning area.
14:19:10 [TabAtkins_]
fantasai: If the image has an intrinsic size, you don't need to size it to cut it.
14:21:06 [TabAtkins_]
ChrisL: It won't tile in the sense tha tyou have only one copy of the image.
14:21:48 [karl]
RRSagent, pointer?
14:21:48 [RRSAgent]
14:21:56 [TabAtkins_]
dbaron: It seems there may be a solution wher eyou just end up with one copy of the imgae.
14:22:08 [TabAtkins_]
dbaron: Except you're doing sizing before doing slicing to fill the border.
14:22:16 [karl]
RRSAgent, make logs public
14:22:26 [karl]
RRSAgent, draft minutes
14:22:26 [RRSAgent]
I have made the request to generate karl
14:22:40 [TabAtkins_]
[some discussion]
14:22:44 [TabAtkins_]
dbaron: I guess it's fine.
14:22:58 [dbaron]
(I still don't really know what it means, but I don't think it matters.)
14:23:36 [glenn]
glenn has joined #css
14:24:02 [TabAtkins_]
RESOLVED: Accept the ED text for border-image-slice.
14:24:57 [TabAtkins_]
fantasai: next issue is animations.
14:25:00 [Bert]
14:25:00 [trackbot]
ISSUE-215 -- Animatability of box-shadow: none to box-shadow: <shadow> -- raised
14:25:00 [trackbot]
14:25:05 [TabAtkins_]
fantasai: We added the animatable field to the spec.
14:25:10 [TabAtkins_]
fantasai: It should match transitions in general.
14:25:20 [TabAtkins_]
fantasai: One different area is the box-shadow property.
14:25:37 [TabAtkins_]
fantasai: We currently say "animatable: yes, but not between inset and outset". We'll deal with that kind later.
14:26:03 [ChrisL]
specifying animatability on all properties is good
14:26:05 [TabAtkins_]
fantasai: And we say that transition to/from an absent shadow is between "0 0 transparent".
14:26:30 [TabAtkins_]
fantasai: So you can transition between box-shadow:none and box-shadow:<something>
14:26:45 [TabAtkins_]
tantek_: Is there a reference to what we mean by "animatable"?
14:26:53 [TabAtkins_]
fantasai: yeah, the transitions spec.
14:27:00 [TabAtkins_]
tantek_: So that's a normative dependency?
14:27:37 [TabAtkins_]
Bert: Not quite.
14:28:02 [TabAtkins_]
dbaron: The idea is that specs that happen before Transitions, Transitions defines how they work. Ones published afterwards, the spec defines how they work.
14:28:16 [TabAtkins_]
dbaron: We're maybe racing with Transitions with this spec, but it's not a big deal.
14:28:49 [TabAtkins_]
ChrisL: But every spec will end up with animation information?
14:28:53 [TabAtkins_]
dbaron: Yes, when they next update.
14:29:27 [ChrisL]
ok, good
14:29:34 [TabAtkins_]
tantek_: For specs that are ahead in progress of Transitions, we should have Transitions contain that information.
14:30:00 [TabAtkins_]
dbaron: I don't agree.
14:30:56 [TabAtkins_]
fantasai: Unless someone has a *really good reason* why this is a process problem, we shouldn't worry about it. It's better to be consistent and have all the specs work the same way.
14:31:15 [TabAtkins_]
plinss: At TPAC we discussed transitioning between inset/outset shadows.
14:31:21 [TabAtkins_]
TabAtkins_: I don't think we have a good answer for it yet.
14:31:28 [TabAtkins_]
fantasai: We'll address it in level 4.
14:31:32 [TabAtkins_]
plinss: Okay.
14:32:02 [TabAtkins_]
fantasai: That's all the issues, so Bert and I need to compile the list of changes.
14:32:51 [fantasai]
ACTION fantasai: if animating from none to inset shadow, need none to behave as '0 0 transparent inset'
14:32:51 [trackbot]
Created ACTION-434 - If animating from none to inset shadow, need none to behave as '0 0 transparent inset' [on Elika Etemad - due 2012-02-14].
14:33:16 [TabAtkins_]
smfr: Issue - If going from 'none' to an inset shadow, need to support the 'none' being treated as "0 0 transparent inset".
14:33:17 [dbaron]
(or for a list being shorter)
14:33:26 [dbaron]
(and none really gets treated as a 0-length list)
14:33:27 [TabAtkins_]
RESOLVED: Accept ED text for all animatable properties.
14:33:29 [glenn]
glenn has joined #css
14:33:53 [TabAtkins_]
fantasai: So Bert and I will make the edits and compile the list of changes, then present beofr eth enext telcon.
14:34:07 [TabAtkins_]
fantasai: So question, can we republish CR with the changes, or do we need to go back to LC.
14:35:14 [TabAtkins_]
szilles: Did you do anything that would invalidate an existing impl?
14:35:44 [TabAtkins_]
fantasai: Yes, we made the default shadow color more precise.
14:36:19 [TabAtkins_]
ChrisL: You can do the minimum 3-week LC, and say you're not accepting any new features, but are only looking for feedback on the list of recent changes.
14:37:30 [TabAtkins_]
tantek_: Can we just go to LC directly?
14:37:34 [TabAtkins_]
tantek_: Or CR directly?
14:37:43 [TabAtkins_]
[process discussion]
14:39:29 [TabAtkins_]
plinss: We could potentially do a testsuite and go from LC straight to PR.
14:39:40 [TabAtkins_]
fantasai: Last time we tried that with Selectors, it sat in LC for several years.
14:40:26 [TabAtkins_]
tantek_: I think that sending it back to LC ocmmunicates that it's unstable, which is wrong. That part of W3C process is broken.
14:41:36 [TabAtkins_]
fantasai: I agree with Tantek that the process is broken, and we need a way to errata a CR in-place.
14:42:01 [TabAtkins_]
fantasai: We have two options. Go through LC, make it quick, and get back to CR. Second is to make box-shadow default color undefined and stay in CR.
14:44:22 [glenn]
glenn has joined #css
14:44:43 [TabAtkins_]
[angry discussion about process]
14:46:48 [fantasai]
RESOLVED: Republish Backgrounds and Borders as LC in order to errata it as CR. Include an explanation of why we're publishing a LC -- that it's still a CR-level draft, we just need to make errata 'cuz the process doesn't allow for errata in CR.
14:47:59 [astearns]
the errata list should probably highlight the single issue that made LC required
14:48:08 [TabAtkins_]
Topic: Image Values
14:48:51 [TabAtkins_]
fantasai: If anyone has any issues about LC, please raise them.
14:49:04 [TabAtkins_]
sylvaing: I have a question about gradients. Does anyone know how long they'll keep their prefixes around?
14:49:16 [TabAtkins_]
sylvaing: It looks like FF has changed to accept the new grammar.
14:49:33 [TabAtkins_]
dbaron: We attempted to make an additive change so we would support more of th enew syntax values, but not remove support for anything yet.
14:49:49 [smfr]
smfr has joined #css
14:49:54 [miketaylr]
miketaylr has joined #css
14:50:00 [TabAtkins_]
dbaron: I don't plan to remove things fro mthe -moz-gradient; I plan to remove that stuff when we unprefix.
14:50:22 [TabAtkins_]
dbaron: We'll probably keep the prefix around for a bit, considering how used it is.
14:50:31 [TabAtkins_]
florian: We'll probably drop our prefix the moment we go to unprefixed.
14:50:46 [TabAtkins_]
smfr: We implemented gradients before the angle change, which means we can't update without breaking stuff.
14:50:53 [TabAtkins_]
smfr: So we probably won't be able to drop prefixes for a long time.
14:51:04 [TabAtkins_]
smfr: We can definitely do unprefixed correctly, though.
14:51:37 [fantasai]
Tab: smfr suggests moving element() to L4
14:51:50 [fantasai]
Tab: right now only Mozilla implements. If nobody else has plans, perhaps better to shift to L4?
14:52:25 [fantasai]
dbaron: How many implementations do we have of the other stuff?
14:52:43 [fantasai]
Tab: The other stuff is relatively simple
14:53:11 [TabAtkins_]
dbaron: Why are we removing the hard-but-popular instead of the simple-but-nobody-cares?
14:53:14 [fantasai]
fantasai: If the spec is stable, then we should take it to CR and mark it at-risk.
14:53:20 [fantasai]
fantasai: If the spec is unstable, then we should hold it back.
14:54:01 [TabAtkins_]
TabAtkins_: Simon, would you be okay if we kept element() as at-risk as we go into CR?
14:54:05 [TabAtkins_]
smfr: Yes.
14:54:14 [glenn]
glenn has joined #css
14:54:39 [TabAtkins_]
dbaron: Are enough things marked as at-risk?
14:55:00 [TabAtkins_]
dbaron: Do we have two impls of objec-tposition and image-resolution? And the rest of object-fit?
14:55:15 [TabAtkins_]
fantasai: We have two impls of image-resolution.
14:55:58 [TabAtkins_]
florian: We have some code for object-*, but I don't know the status.
14:56:03 [TabAtkins_]
plinss: What about a testsuite?
14:56:09 [TabAtkins_]
sylvaing: We have some gradients test. We'll contribute them.
14:56:16 [TabAtkins_]
TabAtkins_: I plan to make testsuite my next priority.
14:56:48 [TabAtkins_]
fantasai: There's an issue from the community about the gradient syntax.
14:58:59 [dbaron]
Florian: We've debated this to death already. What we have is a compromise, and it satisfies more people than any other compromise we've had.
14:59:08 [fantasai]
fantasai: It was a coin toss.
14:59:54 [TabAtkins_]
dbaron: I suggest we mark everything but gradients as at-risk. I don't want any of the other features to hold up gradients.
15:00:28 [TabAtkins_]
[several]: That's fine.
15:01:11 [TabAtkins_]
RESOLVED: Mark everything in Images 3 as at-risk except gradients.
15:01:25 [TabAtkins_]
RESOLVED: Move Images 3 to CR after the above change.
15:01:27 [fantasai]
fantasai^: and it made the updated syntax less compatible with what's out there already
15:04:48 [ksweeney]
ksweeney has joined #css
15:04:59 [arron]
arron has joined #css
15:05:07 [glenn]
glenn has joined #css
15:16:43 [arron]
arron has left #css
15:17:04 [arron]
arron has joined #css
15:20:23 [glenn]
glenn has joined #css
15:22:48 [TabAtkins_]
Topic: 2.1 errata
15:23:07 [TabAtkins_]
antonp: We've got about 88 issues on the bug tracker, with about 20 more I'm tracking and need to carry over.
15:23:19 [TabAtkins_]
antonp: The remaining will need a lot of work to decide what's even wrong.
15:23:29 [TabAtkins_]
antonp: The majority of the stuff on the list is not hard, and I think just needs to be approved.
15:23:34 [smfr]
15:23:45 [TabAtkins_]
antonp: So, we're not going to do 88 bugs in the next hour. What's our strategy, and our timeline?
15:24:07 [TabAtkins_]
antonp: There are a few that I think could benefit form a discussion now, 6 in particular.
15:24:14 [TabAtkins_]
antonp: Which we could do easiest first, or hardest first.
15:24:22 [glazou]
glazou has joined #css
15:24:28 [TabAtkins_]
antonp: So, first, general strategy to get them fixed, then we can discuss some specific ones.
15:24:51 [TabAtkins_]
fantasai: I think a good strategy would be to put a couple on each telcon, so we burn them down eventually, and for each, put a proposal on it.
15:25:06 [TabAtkins_]
fantasai: So each weak, we have one or two CSS 2.1 issues to look at that the WG can discuss.
15:25:19 [fantasai]
15:25:20 [TabAtkins_]
dbaron: I find it easier to think about a bunch at once, rather than switching regularly.
15:25:30 [TabAtkins_]
antonp: Is that because of topic? The topics divide up well.
15:25:46 [TabAtkins_]
antonp: And then there are many easy editorial-like ones that can push through fairly easily.
15:25:53 [TabAtkins_]
dbaron: Okay. And I think it's good to come up with a proposal.
15:26:05 [TabAtkins_]
fantasai: And if there isn't one, we should be discussing who's writing a proposal.
15:26:25 [TabAtkins_]
antonp: Another question, what's our timeline for all of this?
15:26:32 [TabAtkins_]
antonp: What are the reqs for an errata document?
15:26:46 [TabAtkins_]
fantasai: It's continuously maintained. As soon as we resolve, it goes on Bert's list to write the errata.
15:26:55 [TabAtkins_]
fantasai: We'd like to publish an updated 2.1 Rec sometime this year.
15:27:16 [TabAtkins_]
fantasai: Ideally around June, but we can push it to August or whatever if necessary, if we have a few more bugs to handle.
15:27:32 [TabAtkins_]
florian: I think most important is to resolve them faster than reported.
15:27:43 [TabAtkins_]
florian: i don't think it's quite necessary to have them all resolved at the same time.
15:27:52 [TabAtkins_]
antonp: Sounds reasonable.
15:28:15 [TabAtkins_]
antonp: Most of these are small, editorial tweaks. Only a small number require real thinking.
15:28:25 [TabAtkins_]
antonp: So, do we now want to actually look at some of these beasts?
15:29:06 [TabAtkins_]
antonp: We have two on margin-collapsing, one is kinda hard as it contradicts an old resolution.
15:31:07 [ksweeney]
ksweeney has left #css
15:31:15 [glenn]
glenn has joined #css
15:32:02 [dbaron]
15:32:57 [fantasai]
ScribeNick: fantasai
15:33:03 [fantasai]
Anton draws on the board
15:33:14 [fantasai]
Anton: Partial margin collapsing could have been the perfect solution, but also kindof hard.
15:33:20 [fantasai]
Anton: This is the rewrite of the old margin collapsing stuff
15:33:25 [fantasai]
(points to screen)
15:33:32 [tantek_]
note: for ASCII art, here is a handy web-based visual editor:
15:33:40 [fantasai]
Anton: I'm using this wording b/c far better than the old wording, and forpurposes I'm discussing is exactly the same.
15:34:07 [fantasai]
Anton: This is the situation wh have. We have a box with a min-height. And it has one child, and the child is self-collapsing.
15:34:29 [fantasai]
Anton: The result of collapsing the child is this here (points at dotted rectangle inside solid rectangle). It is about to collapse with the parent's top margin.
15:34:38 [fantasai]
Anton: Problem is it also wants to collapse with the bottom margin.
15:34:59 [fantasai]
Anton: Not defined what happens there. Does this collapsed margin collapse with the bottom or the top or what?
15:35:10 [fantasai]
Anton: There was a discussion of min-height and max-height and their effect on collapsing.
15:35:36 [fantasai]
dbaron: At one point a distinction between whether min-height prevented collapsing through or collapsing the last child's bottom margin with the parent's margin when the margin was not collapsed with the parent's top margin
15:35:47 [fantasai]
Steve: Sounds like you aid the case is already complete.
15:35:53 [fantasai]
dbaron: It's a hard compromise we ended up with
15:36:33 [fantasai]
Anton: There are one or two tiny things that need to be rethought, but not relevant to this case.
15:36:52 [fantasai]
dbaron: There was one issue I object to in the rewrite, because it made a case where the spec was self-contradictory be defined here.
15:36:58 [fantasai]
Anton: I believe it exists as a contradiction here.
15:37:02 [fantasai]
Anton: This is the contradiction.
15:37:09 [fantasai]
dbaron: I agree there's a contradiction in what to do here.
15:37:16 [fantasai]
dbaron: Last time we discussed it, didn't think about that.
15:37:24 [fantasai]
dbaorn: old spec contradicted itself with what collapsed with what.
15:37:46 [fantasai]
Anton: Think that transferred across. No difference, except this spec there's a slight.. it uses adjoining when it means collapsing and vice versa.
15:37:55 [arron]
do we have a test page that shows what anton drew on the board?
15:37:56 [fantasai]
Anton: Adjoining is now a non-transitive issue. Collapsing is a transitive issue.
15:38:13 [fantasai]
Anton: Collapsing is transitive because a collapsed margin ... Oh, hang on, maybe it's not an issue.
15:38:33 [fantasai]
dbaron: I thought we wanted adjoining to be transitive?
15:38:37 [fantasai]
fantasai: I tried. I couldn't do it.
15:38:57 [fantasai]
dbaron: The old contradiction was that there awas a statement that these 2 things collapse, and these two things don't.
15:39:07 [fantasai]
fantasai: I think most of the old text is in that note.
15:39:12 [alexmog_]
alexmog_ has joined #css
15:39:16 [fantasai]
Anton: To approach this problem, worth pointing out what discussions were had in the past.
15:39:31 [fantasai]
Anton: Was a very important case in the past where you've got your box here, you've actually got a genuine child non-collapsing child
15:39:52 [fantasai]
Anton: And the non-collapsing child has a margin which is really long... *draws margin that flows out of the box*
15:39:57 [fantasai]
Anton: and parent has a bottom margin.
15:40:14 [fantasai]
Anton: This child with the bottom margin, the height of that margin is bigger than the min-height of the box.
15:40:25 [fantasai]
Anton:What happens here? Does this force the parent to become bigger?
15:40:41 [fantasai]
Anton: Doing something differnet with min-height and max-height causes discontinuities.
15:41:03 [fantasai]
dbaron: They were dropped because something we really wanted to do and couldn't get two implementations passing the test suite, but what we decided to do didn't make sense.
15:41:30 [fantasai]
Alex: We have resisted conditional margin collapsing that depends on content actually hitting min-height or not. min-height has an effect or doesn't have an effect.
15:41:43 [fantasai]
Alex: All other aspects of margin collapsing can be calculated before layout starts.
15:41:46 [fantasai]
Alex: ....
15:41:53 [fantasai]
Anton: The reason then that we have ourselves in a weird situation because of that.
15:42:12 [fantasai]
Anton: Now, because there's no instructions about min-height in the spec anymore, we have a strange situation where this was a self-collapsing element *points at first drawing*
15:42:29 [fantasai]
Anton: Another interesting issue, now, *draws solid box inside bigger solid box*
15:42:55 [fantasai]
Anton: Spec says that the bottom margin of this small child collapses with the margin on the parent, even though the box is plenty big enough to contain the child and its margin
15:43:48 [fantasai]
Anton: From what I can tell from the minutes and resolutions, it was recognized that the resolution didn't solve all the problems, and it was recognized that it wasn't solved, would have to be solved later
15:44:01 [fantasai]
Anton: Seems to me fundamental problem, should this margin collapse with the one down there?
15:44:01 [alexmog_]
15:44:02 [alexmog_]
| |
15:44:02 [alexmog_]
+-|---------------|--+ +
15:44:02 [alexmog_]
| | | | |
15:44:02 [alexmog_]
| +---------------+ | |
15:44:02 [alexmog_]
| margin 1 | |
15:44:04 [alexmog_]
| | | min-height
15:44:04 [glenn_]
glenn_ has joined #css
15:44:05 [fantasai]
Anton: Here you can do something sensible.
15:44:06 [alexmog_]
| | |
15:44:08 [alexmog_]
| | |
15:44:10 [alexmog_]
| | |
15:44:12 [alexmog_]
| | |
15:44:14 [alexmog_]
+--------------------+ v
15:44:16 [alexmog_]
margin 2
15:44:27 [fantasai]
Anton: In the case where you've got a non-self-collapsing child, as the last child
15:44:38 [fantasai]
Anton: You can do something sensible to collapse its bottom margin with the paretn's bottom margin.
15:44:46 [fantasai]
Anton: You have to choose, but you can spec somehting sensible.
15:44:56 [fantasai]
Anton: But in the case wher eyou have self-collapsing margin, you can't
15:45:10 [fantasai]
Anton: How does this margin manifest itself? You have a positive-height box, but it's supposed to be self-collapsing.
15:45:16 [fantasai]
dbaron: See 2 posslbe changes to spec to fix this.
15:45:43 [fantasai]
dbaron: Minimal one is to change the third bullet under the third bullet in definition of adjoining.
15:45:58 [fantasai]
"bottom margin of a last in-flow child and bottom margin of its parent if the parent has 'auto' computed height"
15:46:28 [fantasai]
dbaron: To add the condition that either the parent has zero computed min-height, or the bottom margin of the last in-flow child does not collapse with the top margin of the parent.
15:46:36 [fantasai]
dbaron: Thought we had a condition like that in the spec.
15:47:17 [fantasai]
dbaron: And this condition with an either-or: either parent has zero computed-min-height, or, bottom margin of the last child doesn't collapse with the top margin of the parent.
15:47:57 [fantasai]
dbaron: What I'd really prefer is to reduce the condition by saying it's just "and the parent has a computed zero min-height"
15:48:09 [dbaron]
change from: "bottom margin of a last in-flow child and bottom margin of its parent if the parent has 'auto' computed height"
15:48:52 [dbaron]
change to option 1 (minimal): "bottom margin of a last in-flow child and bottom margin of its parent if the parent has 'auto' computed height and (the parent has a zero computed min-height or the bottom margin of the last in-flow child does not collapse with the top margin of the parent)"
15:49:14 [fantasai]
Alex: I think reason min-height is not mentioned there is that we don't want to prevent margin collapsing when min-height didn't take effect.
15:49:16 [dbaron]
change to option 1 (preferred, but I don't remember why we didn't do it before): "bottom margin of a last in-flow child and bottom margin of its parent if the parent has 'auto' computed height and the parent has a zero computed min-height"
15:49:26 [fantasai]
Alex: If you have min-height of 1px, min-height will not make a difference, but will prevent margin collapsing.
15:49:30 [fantasai]
Anton: exactly
15:49:49 [fantasai]
Anton: Seem to be definitely in past resolutions to not distinguish cases of whether min-height takes effect or not.
15:50:00 [fantasai]
Anton: But I think you can't have continuity if you think to that.
15:50:03 [fantasai]
dbaron: ...
15:50:19 [fantasai]
Alex: min-height has an effect, and bottom margin doesn't collapse with top margin, your position will change ....
15:50:39 [fantasai]
Anton: reoslution in the past ...
15:50:44 [fantasai]
Anton: we have to say that those can collapse
15:50:54 [fantasai]
Anton: Brings us back to this case (points at solid solid boxes)
15:51:16 [fantasai]
Alex: .. is pretty rare, and making that work, with all of the complications that we have
15:51:28 [fantasai]
Alex: If we make it work, will be pretty complicated, but we're not sure how much we really need it.
15:51:40 [fantasai]
Anton: Confirming that we don't exclude min-height in general that would be collapsing here.
15:51:50 [fantasai]
Alex: One case you've shown doesn't make any sense, but keep severything predictable
15:52:03 [fantasai]
Anton: Important to decide what we want in this case, b/c will help us understand the contradictory case.
15:52:16 [fantasai]
Anton: David your solution is then appropriate for this (middl picture of collapsed margin isnide min-height box)
15:52:31 [fantasai]
Anton: Self-collapsing sits at the top, doesn't make sens to collapse to the bottom.
15:52:39 [fantasai]
Anton: In this case you need to break collapsing with the bottom.
15:53:27 [fantasai]
fantasai: I think we discussed this situation wrt defining the position of the self-collapsed element, not here for how to collapse it.
15:53:40 [fantasai]
Anton: Yeah, the border position is well-defined. Just not defined how it collapses.
15:54:00 [fantasai]
Anton: The border position sets up a hypothetical situation where you don't have these collapsing.
15:54:25 [fantasai]
Anton: There is an issue where if you've got a min-height, you begin by doing the calculation based on the normal height, and you do the CH 10 calculations to determine your height.
15:54:39 [fantasai]
Anton: If that's less than the min-height, then you do your calculations again.
15:54:51 [fantasai]
Anton: assuming that the height is then set to the specifie dmin-height.
15:55:01 [fantasai]
Anton: In all of these cases, incidentally, height is assumed to be 'auto'.
15:55:22 [fantasai]
Anton: There's a note in Ch 10.7, that tries to explain something about margin collapsing. But I can't understand what that note is saying in relation to this.
15:55:42 [fantasai]
Anton: If you're recalculating b/c you're assuming auto height, then assuming ehgiht = min-height, you run into differnet rules in marign collapsing.
15:55:57 [fantasai]
Anton: Confusing note in 10.7, doj't know whether it's trying to address this situation or not.
15:56:12 [dbaron]
These steps do not affect the real computed values of the above properties. The change of used 'height' has no effect on margin collapsing except as specifically required by rules for 'min-height' or 'max-height' in "Collapsing margins" (8.3.1).
15:56:15 [dbaron]
(note in 10.7)
15:57:01 [fantasai]
dbaron: I think what the second sentence means is that the change of used height has no effect on margin collapsing, period. however min-height or max-height might have an effect as defined in 8.3.1
15:57:20 [fantasai]
Anton: So, you do all your calculations with height, but not big enough b/c have min-height, and have to redo the calculations
15:57:32 [fantasai]
dbaron: Note says that you don't recompute anything wrt margin collapsing. it stays the way it was.
15:57:50 [fantasai]
Anton: As in, all relationships of what collapses with what stays the same
15:57:51 [fantasai]
dbaron: yes
15:58:03 [fantasai]
Bert: Your rewrite of that sentence into the two parts is what I understand, yes.
15:58:06 [fantasai]
fantasai also agrees
15:58:24 [dbaron]
Possible rewrite of note: These steps do not affect the real computed values of the above properties. The change of used 'height' has no effect on margin collapsing. 'min-height' and 'max-height' only affect margin collapsing as specified by the rules in in "Collapsing margins" (8.3.1).
15:59:01 [fantasai]
Anton: Ok, with that interpretation of the note... I think that doesn't add anything new to this.
15:59:32 [fantasai]
Anton: Think suggestion of preventing margin-collapsing in this case is enough to solve the problem, and doesn't contradict what's intended by the other rules
16:00:05 [nimbu]
nimbu has joined #css
16:00:06 [fantasai]
Anton points at child inside larger box case
16:00:27 [fantasai]
Anton: I don't think there's anything that says if this margin collapses with the other margin, which border it sticks to.
16:00:53 [fantasai]
Anton: You'll get strange behavior either way, but not defined where the collapsed margin resides
16:01:16 [fantasai]
Florian: If you say they dont' collapse... but that brings up other problems.
16:01:29 [fantasai]
dbaron: Where do we define where the position of the next block is?
16:01:47 [fantasai]
Anton: There is a whole issue on where is actually the top content edge
16:02:00 [fantasai]
dbaron: We do actually define ... in [really convoluted case]
16:02:16 [fantasai]
Anton: You might be right, there might be a loophole in a special case. But in the general case not defined.
16:02:31 [fantasai]
16:02:49 [fantasai]
Anton: If we're going to collapse these two things, then it shoudl go to the parent. Otherwise it's really odd.
16:03:05 [fantasai]
dbaron: 9.4.1 says the vertical distance between 2 sibling blocks is determined by the margin properties
16:03:12 [fantasai]
Anton: With a big leap of faith you can make that work.
16:03:25 [fantasai]
Bert: I know I tried to rewrite that in the Box Module...
16:04:16 [fantasai]
fantasai: I think for things that are a bit handwavy and need a leap of faith.. well, it's an old spec. We need to rewrite all this, and shouldn't do that rewrite as 2.1
16:04:22 [fantasai]
fantasai: Should just fix errors in it.
16:04:45 [fantasai]
fantasai: So I believe there are two issues here.
16:05:24 [fantasai]
fantasai: One is that if you have a self-collapsing only child and a min-height, don't collapse the child with the bottom parent margin
16:05:47 [fantasai]
fantasai: Other one is, if a parent and child margins collapse, the collapsed margin is attached to the border edge of the parent.
16:06:06 [alexmog_]
alexmog_ has joined #css
16:06:12 [fantasai]
dbaron: I think we should say where the top of a block goes. Which right now we dont'
16:06:44 [fantasai]
Anton: So we note this down as something that needs to be turned into proposed text, discuss that text on the telecon.
16:07:16 [fantasai]
ACTION Anton: Record these two issues and the conclusion, point to these minutes, write a next-action to propose text.
16:07:16 [trackbot]
Created ACTION-435 - Record these two issues and the conclusion, point to these minutes, write a next-action to propose text. [on Anton Prowse - due 2012-02-14].
16:07:47 [fantasai]
Anton: Absolute positioning is defined in terms of the top margin edge of something.
16:07:58 [fantasai]
Anton points us to definition of static position
16:08:08 [fantasai]
dbaron: static position doesn't really matter, because UAs may approximate.
16:08:21 [fantasai]
dbaron: I'd try 10.1 or 10.6.4 (?)
16:08:27 [Rossen]
16:09:27 [fantasai]
dbaron quotes from the spec the part about "... would have been the first box of the element ... specified clear had been none ..."
16:09:36 [dbaron]
More precisely, the static position for 'top' is the distance from the top edge of the containing block to the top margin edge of a hypothetical box that would have been the first box of the element if its specified 'position' value had been 'static' and its specified 'float' had been 'none' and its specified 'clear' had been 'none'. (Note that due to the rules in section 9.7 this might require also assuming a different computed value for 'display'.)
16:09:39 [dbaron]
(from 10.6.4)
16:10:25 [fantasai]
Anton: Issue is that it says that the static position for top is from the top edge of the containing block.. to the top margin edge of the hypothetical position
16:10:40 [fantasai]
Anton: So you need to know the top margin edge, which is not well-defined in most cases.
16:10:46 [fantasai]
16:10:54 [fantasai]
Anton: If margins don't collapse, it's obvious where it is.
16:11:14 [fantasai]
Anton: But when you have margin collapsing in general... you have this blob in the middle. can you really say where the top margin edge is?
16:11:36 [fantasai]
Alex: top of the collapsed margin
16:11:55 [fantasai]
dbaron: Does anyone know why we say top margin edge of the first child box rather than top content edge of the box itself?
16:12:12 [fantasai]
dbaron: That might solve the problem. Or may be different and not what we mean.
16:12:43 [fantasai]
Bert: ...
16:12:46 [fantasai]
dbaron: nevermind that question
16:12:59 [fantasai]
Anton: Top margin edge is not a wel-defined concept, except in exceptional cases
16:13:16 [fantasai]
dbaron: I'm going to suggest this issue lead to someone writing test csaes to find out what implementations actually do
16:13:39 [fantasai]
Anton: I think this was discussed by Oyvind from Opera, who wrote testcases, found there isn't an issue in practice, but spec doesn't reflect the practice.
16:13:45 [fantasai]
Anton: Don't think we should define a top margin edge.
16:13:52 [fantasai]
Anton: Example is, in the bug tracker somehwere.
16:14:11 [fantasai]
Anton: There's very weird kind of things when you've got self-collapsing elements trapped in the middle of a collapsed margin
16:14:47 [fantasai]
anton: Where the self-collapsing element has a 20px top margin, but when you calculate it's border position doesn't allow for a top margin of 20px
16:14:54 [fantasai]
anton: There aren't enough pixels above the top border edge
16:15:03 [fantasai]
Anton: B/c of this don't think we should define where the top margin edge.
16:15:22 [fantasai]
Anton: Instead I think where it relies on the top marign edge, seems to be a consesnus that we should define it relation to the border edge, which is well-defined
16:15:40 [fantasai]
Anton: We define static position in terms of the border edge, and then add the top margin edge onto it
16:15:58 [fantasai]
Anton: as a correction
16:16:12 [fantasai]
Steve: That seems to have the effect that in the collapsed margin case, ...
16:17:01 [fantasai]
Anton: It would be this height above its border edge...
16:17:31 [fantasai]
Anton: defining the top margin edge to be up here *points above the collapsed margin* doesn't make sense to me, so would rather not do that
16:18:23 [fantasai]
Anton: [my suggestion] seems to match implementations
16:18:55 [fantasai]
Alex: Example of what's defined as margin edge?
16:19:14 [fantasai]
Anton: It's not defined. The text defines static position (10.6.4) in terms of the top margin edge, which is not defined.
16:19:26 [smfr]
16:20:16 [tantek]
(ASIDE: regarding using -webkit- prefix, clarification re: Lea Verou - she's advocated using *both* vendor prefixed properties (multiple vendors) and the unprefixed version after them. See her talk from Front-Trends 2010 for example. An actual example of -webkit- *only* prefix examples (thus implied advocacy) is Google's , e.g.
16:20:16 [tantek] has three -webkit- property declarations starting with -webkit-column-count )
16:20:18 [fantasai]
dbaron: So, I'm ok with whatever bzbarsky is ok with, because I defer everything about static position to him.
16:20:27 [fantasai]
dbaron: I also don't especially care. i think it's a horrible concept.
16:20:42 [Bert]
(Something like: "More precisely, the static position for 'top' is a length A - B, where A is the distance from the top edge of the containing block to the top border edge of a hypothetical box that would have been the first box of the element if its specified 'position' value had been 'static' and its specified 'float' had been 'none' and its specified 'clear' had been 'none'; and B is the top margin of the element.")
16:21:08 [fantasai]
Anton: b/c spec doesn't make sense as it is, important to make testcases, and check that proposed wording doesn't change the behavior of those test cases.
16:22:23 [fantasai]
[Alex and Anton discuss the issue]
16:24:23 [fantasai]
Alex: top: auto means it won't move in reasonable cases
16:24:35 [fantasai]
Anton: ...
16:24:52 [fantasai]
Alex: I'm not proposing recollapsing. Saying that for purposes of that position, margin is used [...]
16:26:42 [fantasai]
Anton: The way i understand there's inline and block. Inline, no margins. If you make inline abspos, it will be shifted down by its margin.
16:26:50 [fantasai]
fantasai disagrees
16:26:59 [fantasai]
fantasai: Inline has a margin, it just doesn't affect line height
16:27:12 [fantasai]
Alex: for block, we know very well ...
16:27:32 [fantasai]
Alex: It's top margin, which we don't have to collapse with anything b/c it's positioned.
16:27:40 [fantasai]
Alex: It's inline, it's out of flow.
16:27:54 [fantasai]
Alex: To determine the static, all you do is look at the bottom of this line, and it's ... in the current flow and that's it
16:28:02 [fantasai]
Alex: The top margin used for static calculation has now been collapsed
16:28:10 [fantasai]
Alex: It's not even a block for purposes of static layout
16:28:15 [fantasai]
Alex: it's a hypothetical situation
16:28:25 [fantasai]
Alex: For hypothetical situation, nothing to collapse
16:28:32 [fantasai]
Anton: Doesn't explain final result
16:28:39 [leaverou]
leaverou has joined #css
16:28:59 [fantasai]
Alex: Does. because abpsos elements are out-of-flow that have in-flow static position, determined by anonymous line
16:29:25 [fantasai]
Anton: You're saying that abspos elements leave an inline-level placeholder
16:29:32 [fantasai]
Anton: Even if they're blocks.
16:29:49 [fantasai]
Anton: The spec definitely doesn't say that at the moment.
16:29:55 [fantasai]
Anton: In tables it does.
16:30:10 [fantasai]
Alex: Having something abspolutely positioned... a line.
16:30:20 [fantasai]
Alex: element has no right ot colalpse with anything else because it has never been a block.
16:30:25 [fantasai]
Alex: only hypotehtical
16:30:37 [fantasai]
Alex: it's happening relative to that imaginary line, as if that was a line with some kind of content
16:30:45 [fantasai]
Alex: With that no collapsing would happen
16:30:50 [fantasai]
Anton: Where is the position of that line?
16:31:06 [fantasai]
Anton: I see, would be anonymous self-collapsing block.
16:31:22 [fantasai]
Anton: I'm fairly certain it doesn't leave behind a placeholder currently in the spec
16:31:25 [fantasai]
Alex: ...
16:31:48 [fantasai]
Alex: Abspos element is inline content
16:31:59 [fantasai]
Alex: That for all other purposes is empty, but it has very well defined position
16:32:11 [fantasai]
Anton: I understand the argument you're making, but I don't think the spec there.
16:32:40 [fantasai]
Anton: Spec says to treat it as non-abspos to find its position, and if it's a physical inline-level box. You're redoing layout with a different assumption.
16:32:53 [fantasai]
Anton: But your'e saying when i's abpsos, it leaves behind a placeholder that affects layout.
16:33:16 [fantasai]
Alex: ...
16:33:23 [fantasai]
Alex: That defines inline position of abspos
16:33:41 [fantasai]
Alex: our implementation also has a line which might be empty which has a.. ok Rossen disagrees.
16:34:12 [fantasai]
Anton: I honestly don't think that's what the spec says.
16:34:43 [lar_zzz]
lar_zzz has joined #css
16:34:43 [fantasai]
Alex: I think it's good idea to define hypothetical position precisely.
16:34:51 [fantasai]
Alex: Rossen do you disagree with anything I said?
16:35:04 [fantasai]
Rossen: abspos elements that are blocks, ... we do not collapse margins
16:35:14 [fantasai]
Rossen: So, we will not use the collapsed position for abspos elements.
16:35:19 [fantasai]
Rossen: This is what everyone currently does
16:35:28 [fantasai]
Rossen: I agree with Alex on something he said in the beginning.
16:35:37 [Ms2ger]
Ms2ger has joined #css
16:35:46 [fantasai]
Rossen: which is, if we insist to keep this top margin position, then we also need to specify it if the margin didn't collapse
16:36:12 [fantasai]
Rossen: When it said you must treat it as if it's positoin static, and float is what it was, et.c etc. You'd add another one that says "And margins of this element did not collapse"
16:36:18 [fantasai]
16:36:29 [fantasai]
Rossen: But that to me seems to open a can of worms.
16:36:50 [fantasai]
Anton: Your'e saying if it was a static block, imagine you had a static block, and its' float was not reset to none, and clear really ahd an effect, and imagine that it didn't collapse any margins...
16:36:59 [fantasai]
Anton: But you have to be more specific: not collapse which margins?
16:37:15 [fantasai]
Alex: ...
16:37:27 [fantasai]
Anton: Part of ccalculating stitc position is you ignore margins..?
16:37:45 [fantasai]
Anton: b/c what happens with its children and their marigns, which used to collapse/not collapse
16:37:51 [fantasai]
Anton; i think testcases are the way to go here.
16:37:55 [fantasai]
16:38:04 [fantasai]
Anton: Don't think it's as simple as saying "don't collapse margins"
16:38:17 [fantasai]
Anton: Of course won't collapse it's margins when its positioned anyway
16:38:27 [fantasai]
Anton: b/c won't collapse once it's been abspos
16:38:40 [fantasai]
Alex: ... a lot of simplifications to not overcomplicate the positioning
16:38:49 [fantasai]
Alex: A lot of ... are not going to happen the same way as in normal layout
16:39:02 [fantasai]
Anton: I don't have an opinion on this, just as the moment it's not currently well-defined.
16:39:18 [fantasai]
Anton: Need a way to define it. Which *might* be placeholders, or [...]
16:39:30 [fantasai]
Rossen: Asked for action item to have a section on that in css3-positioning
16:39:47 [fantasai]
Anton: We still need to do something for CSS2.1, because the text doesn't make sense atm because it relies on an undefined concept.
16:39:49 [smfr]
smfr has left #css
16:40:07 [fantasai]
Anton: The proposal on the list was to do it in terms of border position, then tweak it to account for the margin.
16:40:20 [fantasai]
Alex: UAs are free to make a guess, so that makes it completely free.
16:41:35 [smfr]
smfr has joined #css
16:42:11 [fantasai]
fantasai: So, we've been discussing this for awhile. How about you write proposed text in terms of the border edge, since it seems that's a good way to go. And if Alex wants to implement that in terms of a placeholder in a line box in a self-collapsing anonymous block, that's fine.
16:42:39 [fantasai]
fantasai: Just make sure there's testcases and the spec *results* match implementation *results*
16:42:48 [fantasai]
ACTION Anton: write proposed text and testcases
16:42:48 [trackbot]
Created ACTION-436 - Write proposed text and testcases [on Anton Prowse - due 2012-02-14].
16:43:14 [fantasai]
Anton: Does the root element establish a BFC root
16:43:15 [fantasai]
16:44:01 [arno]
arno has joined #css
16:44:01 [fantasai]
dbaron: I think it's established by the ICB, not the root element
16:44:49 [fantasai]
Rossen: If you want to model the browser window, how would you do it? you would create a <div> with fixed size, and make it overflow: auto so you get scrollbars. That's your viewport
16:45:07 [fantasai]
Rossen: This is what we do in IE.
16:45:17 [fantasai]
Rossen: ICB is not exception to anything
16:45:28 [fantasai]
Rossen: It's just an element, just not accessible to OM
16:45:41 [fantasai]
Rossen: If this is what you mean, then I agree it should be a BFC.
16:45:51 [fantasai]
Rossen: If you mean the root element, then should be driven by properties.
16:46:02 [fantasai]
Florian: I believe in Opera we treat the root element as an abspos.
16:47:18 [fantasai]
Rossen: Up to impleemnter, but if you model this as an element, but needs to have auto scrollbars, so needs to be a BFC.
16:47:23 [fantasai]
fantasai: Root element is not the ICB
16:47:40 [fantasai]
Anton: I'm talking about the document root element
16:48:45 [dbaron]
16:49:08 [dbaron]
16:50:14 [dbaron]
16:50:21 [fantasai]
dbaron suggests people to run this testcase
16:50:34 [fantasai]
dbaron: Question is, where is the orange bar?
16:50:47 [fantasai]
dbaron: chrome has changed to match Gecko since this was written
16:51:59 [fantasai]
deferred to tomorrow
16:52:13 [TabAtkins_]
16:52:32 [fantasai]
Topic: Spec Process
16:52:51 [fantasai]
Tantek: Started to try document our spec development process, and how we try to move faster within W3C process
16:52:57 [fantasai]
Tantek: Top is complaints we have
16:53:09 [fantasai]
Tantek: Trying to look at positive side here, how to improve in the future
16:53:16 [fantasai]
tantek: Have some principles
16:53:23 [fantasai]
Tantek: Publish early and often to show interest/activity
16:53:29 [fantasai]
Tantek: Transparently note objections/issues
16:53:41 [fantasai]
Tantek: Advance as rapidly impelmentations and tests show interop
16:53:54 [fantasai]
Tantek: Drop /postpone features lacking implementations rather than trying to keep things togethers.
16:54:00 [antonp]
antonp has joined #css
16:54:10 [fantasai]
Tantek: In short, I think any editor, anyone in CSSWG shoudl be able to check in editor's draft that agrees with the charter.
16:54:22 [fantasai]
Tantek: When objections are noted, editor's responsiblity to include in the draft.
16:54:37 [fantasai]
glazou: ... No, not possible. Would break discusison of [...]
16:54:54 [fantasai]
glazou: Any idea must be proposable to the WG, and our role afterwards to decide whther to inlcude charter
16:55:07 [fantasai]
plinss: Stike requirement that it be in the Chater
16:55:17 [fantasai]
ChrisL: That first point is about transition *to* editor's draft
16:55:32 [fantasai]
plinss: For example Tab's hierarchies thing. He's not creating an editor's draft, he's creating a proposal.
16:55:48 [fantasai]
plinss: From idea to proposal document, anyone can chekc anything in, doesn't have to match our charter
16:55:55 [fantasai]
plinss: To move from proposal to ED, need to have a charter discussion
16:56:22 [fantasai]
Tantek: Next one is important. Sometiems takes way too long for EDs to bpulsiehd as FPWD. We need to be much be more active about this.
16:56:33 [fantasai]
Tantek: Suggest that as soon as something is implemented, we push it to FPWD.
16:56:55 [fantasai]
ChrisL: Why wait that long? Does that mean without implementation, you can't publish FPWD?
16:57:07 [fantasai]
Tantek: No, this is saying to treat it as a forcing function.
16:58:05 [fantasai]
glazou: I have one big concern with this step. if the implementation impelments something that is not stabilized, and even under strong scrutiny and criticism, the implementation won't reflect the discussion and the fact that it's not stabilized
16:58:11 [fantasai]
16:58:24 [fantasai]
glazou: This is WHATWG approach that specs do not matter, only implementers do
16:58:27 [dbaron]
16:58:28 [fantasai]
zakim, q+
16:58:32 [Zakim]
Zakim has joined #css
16:58:35 [fantasai]
16:58:45 [fantasai]
ChrisL: earlier is better b/c of IP timer
16:59:02 [fantasai]
ChrisL: As soon as there's a list of features, even not clear what they are, that's when you want to push for FPWD
16:59:21 [glazou]
Zakim, ack dbaron
16:59:21 [Zakim]
I see fantasai on the speaker queue
16:59:23 [fantasai]
dbaron: So, what it looks to me,
16:59:43 [fantasai]
dbaron: If someone believes there is something in a draft they believe should not be in CSS, the first point to object is the PR boat.
16:59:52 [ChrisL]
because there is a 150 day exclusion period. and any feature not in that fpwd can still be excluded following last call
16:59:57 [fantasai]
Tantek: No, edit'rs draft. Has to be documented in the editor's draft.
17:00:09 [fantasai]
dbaron: But what does that note lead to? Does the note end up in a PR?
17:00:20 [fantasai]
Tantek: Point of note is to list it as there being contention.
17:00:43 [fantasai]
glazou: Note that editor's draft can be modified without WG approval.
17:00:53 [plinss]
ack fantasai
17:01:04 [dbaron]
fantasai: I think one of dbaron's points -- that the current policy of the WG that we go to FPWD when there's agreement that we want to work on it.
17:01:13 [dbaron]
fantasai: And if we don't get to that agreement we don't publish as FPWD.
17:01:28 [dbaron]
fantasai: We have to get consensus in the WG that we want to work on it before we go to FPWD, and that's not reflected here.
17:01:46 [dbaron]
Tantek: That's part of the goal is to prevent somebody to stop something from being published just by objecting.
17:01:47 [dbaron]
17:02:00 [dbaron]
plinss: She's talking about whether there's even consensus to work on the draft.
17:02:14 [dbaron]
sylvain: Take the hierarchies example earlier today.
17:02:18 [fantasai]
plinss: I don't think it makes sense to publish FPWD of something where there's no consensus to work on it.
17:02:48 [fantasai]
fantasai^: [something about ijppementation plus draft menas I have a standard to put on /tr as representing WG consensus\
17:02:51 [fantasai]
17:03:01 [fantasai]
Steve: But you don't get ED without a consensus
17:03:08 [fantasai]
Tantek: if you have a shipping implementation, you should get FPWD
17:03:13 [fantasai]
glazou: I strongly object to that.
17:03:21 [fantasai]
plinss: We have things we've publishe dand then lost interest in.
17:03:35 [fantasai]
plinss: Don't think we need a forcing function here.
17:03:52 [dbaron]
So I think a problem with this model is that these transitions lead to implementations as well.
17:04:37 [fantasai]
fantasai: Why are we distinguishing Proposal vs. Editor's Draft Without FPWD? If we have agrement to work on something, it should go to PFWD. Why not have it on /TR?
17:05:01 [fantasai]
dbaron: I think the underlying issue that this idea doesn't consider is that all of these transitions themselves cause implementations.
17:05:12 [fantasai]
dbaron: The act of putting something on increases the possibility of implementation.
17:05:18 [fantasai]
dbaron: Pushing to FPWD makes it more likely.
17:05:28 [fantasai]
dbaron: We have the power to influence what gets implemented. And we should consider how we use it.
17:05:53 [fantasai]
Tantek: Problem is we are being behind. Editor's drafts are being published an dimplemented. W3C Process is being circumvented, and nobody's talking about it.
17:05:58 [fantasai]
Tantek: Stuff is happening, let's move forward.
17:06:06 [fantasai]
glazou: An editor's draft can be modified without WG approval.
17:06:17 [dbaron]
s/to FPWD/to FPWD maybe/
17:06:25 [fantasai]
glazou: Which means a member of this WG can edit a draft, and the draft gos to FPWD without approval of the WG. I don't want that.
17:06:41 [leaverou]
leaverou has joined #css
17:06:51 [fantasai]
Florian: Your model assumes any proposal is a positive one.Which is not necessarily true.
17:06:52 [plinss]
ack dbaron
17:07:17 [fantasai]
Florian: I think if something ships and we don't have a WD, we should be considering it. But we shouldn't automatically go to draft. It should be a trigger to consider it.
17:07:27 [fantasai]
glazou: It should go on the radar of WG. But that's already the case.
17:07:38 [fantasai]
plinss: If these are phrased as these force us to discuss it, that's fine.
17:07:48 [fantasai]
glazou: A WD is published automatically? *shakes head*
17:07:57 [fantasai]
plinss: We can't publish a transition without a group resolution.
17:08:30 [fantasai]
Steve: I was just going to say, W3C took action to change submissions from TRs to put them in a different place b/c they found the system was being gamed by ppl writing things and submitting them and saying they're now a W3C spec, 'cuz now on the W3C site.
17:08:42 [fantasai]
Steve: So there is reason for what Florian and Daniel said. Need consideration to keep people gaming the system.
17:08:54 [fantasai]
Tantek: It's worse now. /TR doesn't matter anymore. Editor's drafts are being implemented.
17:09:06 [fantasai]
Steve: Saying that you're shipping a W3C standard...
17:09:16 [fantasai]
Tantek: They say they're implementing a W3C standard and link to editor's draft
17:09:22 [fantasai]
jdaggett: That's a little bit of a separate issue.
17:09:29 [fantasai]
Steve: I don't believe we're contributing to that piece of it.
17:09:44 [fantasai]
jdaggett: I think you're tyring to accelerate things base d on impelemtations bieng available.
17:09:58 [fantasai]
jdaggett: Problem is you start spitting out specs in chunks. deifnitely be more confusing.
17:10:08 [fantasai]
smfr: We just did that with css3-images
17:10:16 [fantasai]
Steve: We're collecting implementation reality. That's a good thing.
17:10:22 [fantasai]
plinss: As long as you have interoperable implementations, then ..
17:10:35 [fantasai]
jdaggett: You realize this means this is beginning of every spec is one property. Every property has one spec.
17:10:51 [fantasai]
Florian: Not necessarily. Did for gradients because there is urgency on gradients themselves.
17:11:12 [fantasai]
glazou: Don't make it one implementation. Make it two. Then you don't have a working draft, you have a CR. You can even ahve impleementation reports and move fast.
17:11:31 [fantasai]
glazou: Have browser vendors propose things that are more stable.
17:11:38 [fantasai]
Tantek: Let me finish summarizing.
17:11:55 [fantasai]
Tantek: From WD to LC, as soon as any feature has two itneroperable implementations, according to test suites etc,
17:12:13 [fantasai]
Tantek: The draft goes to Last Call. Any features that are not implemented at all get listed as at-risk.
17:12:17 [fantasai]
Tantke: Next step is CR.
17:12:25 [fantasai]
glazou: For step 2 have a problem.
17:12:45 [fantasai]
glazou: In history of WG, we have never made test suites before CR. Not sure that members have showed enough commitment to require test suites before CR.
17:12:48 [fantasai]
glazou: We've tried.
17:12:53 [fantasai]
glazou: Unless we move to CR, no point.
17:13:03 [fantasai]
ChrisL: But we can encourage that. And often people post samples.
17:13:11 [fantasai]
ChrisL: Just collect examples in your spec and you have some tests.
17:13:17 [fantasai]
glazou: I can live with it, we can try.
17:13:37 [fantasai]
plinss: Reality is as soon as someone writes impelmetnation, they are writing their own tests. They just need to write them in W3C format.
17:13:46 [fantasai]
Tantek: Anyone can show a test that disproves your interop.
17:13:50 [fantasai]
Tantek: During LC period.
17:13:58 [fantasai]
Tantek: That resets 6-week LC period.
17:14:16 [fantasai]
Tantek: At the end of that LC period, it goes to CR. Then everything with no implementations get dropped. Everything with only one implementation gets at-risk.
17:14:30 [fantasai]
Tantek: During CR period, eidtor can iterate based on implementation experience.
17:14:36 [fantasai]
glazou: I think this part of automati cprocess I agree more.
17:14:38 [dbaron]
I've sent the whiteboard photos from the 2.1 discussion to www-style, but they haven't gotten through yet.
17:14:43 [dbaron]
er, to www-archive
17:14:51 [fantasai]
glazou: At the end of LC review period, shift to CR *unless* LC period has shown blockers.
17:15:11 [fantasai]
glazou: Can have interoperably implemented with design issues that may harm the Web in the future
17:15:20 [fantasai]
Steve: non-internationalizable, etc.
17:15:23 [dbaron]
17:15:28 [dbaron]
17:15:32 [fantasai]
Florian: We can set these as expectations, but not automatic. Look at them one by one.
17:15:40 [dbaron]
with timestamps in CET
17:15:49 [dbaron]
(in the message body)
17:15:51 [fantasai]
Tantek: At the end of 6mo CR period
17:15:52 [arron]
dbaron, thanks for doing that I will hopefully be able to understand the 2.1 conversation better now.
17:15:55 [dbaron]
and metadata in UTC
17:16:07 [fantasai]
Tantek: Then it "automatically" goes to PR, and any feature not interop by test suite gets dropped.
17:16:22 [fantasai]
Tantek: When I say dropped, I mean postponed.
17:16:27 [fantasai]
Tantek: You just missed the train.
17:16:51 [dbaron]
fantasai: Maintaining multiple versions of the same draft is annoying; don't want to do that just so we can do CR->REC every 6 months.
17:17:21 [fantasai]
Tantek: Trying to provide path for editor's accelerating their wok.
17:17:23 [fantasai]
17:17:46 [fantasai]
Florian: As long as these are expectations, not automatic triggers, it's okay.
17:18:38 [fantasai]
Meeting closed.
17:21:14 [antonp]
antonp has left #css
17:21:47 [ksweeney]
ksweeney has joined #css
17:23:56 [glenn]
glenn has joined #css
17:43:10 [leaverou]
leaverou has joined #css
17:48:18 [lar_zzz]
lar_zzz has left #css
17:52:42 [leaverou]
leaverou has joined #css
18:06:08 [miketaylr]
miketaylr has joined #css
18:30:09 [arno]
arno has joined #css
19:00:06 [ksweeney]
ksweeney has left #css
19:28:44 [Zakim]
Zakim has left #css
19:31:35 [arronei]
arronei has joined #css
19:33:41 [glenn]
glenn has joined #css
20:10:34 [arno]
arno has joined #css
20:55:08 [Ms2ger]
vhardy, hope you don't mind the bugspam :)
20:58:00 [arno]
arno has joined #css
21:03:50 [lar_zzz]
lar_zzz has joined #css
21:03:59 [drublic]
drublic has joined #css
21:40:37 [jdaggett]
jdaggett has joined #css
22:02:00 [arno]
arno has joined #css
22:29:27 [TabAtkins_]
TabAtkins_ has joined #css
23:05:48 [karl]
karl has joined #CSS
23:06:12 [leaverou]
leaverou has joined #css
23:15:28 [ksweeney]
ksweeney has joined #css
23:16:13 [ksweeney]
ksweeney has joined #css
23:32:03 [arno]
arno has joined #css
23:37:25 [Rossen]
Rossen has joined #css