00:20:50 dbaron has joined #css 00:45:19 leaverou has joined #css 01:25:50 krit has joined #css 02:28:53 leaverou has joined #css 03:08:30 leaverou has joined #css 03:09:21 leaverou_ has joined #css 03:12:47 krit has joined #css 04:05:58 krit has joined #css 15:47:10 RRSAgent has joined #css 15:47:10 logging to http://www.w3.org/2012/08/13-css-irc 15:47:16 Zakim has joined #css 15:47:27 RRSAgent, make logs public 15:47:34 RRSAgent, span over midnight 15:47:34 I'm logging. I don't understand 'span over midnight', glazou. Try /msg RRSAgent help 15:49:14 rrsagent, this meeting spans midnight 16:01:52 TabAtkins_ has joined #css 16:12:45 arronei_ has joined #css 16:15:43 florian has joined #css 16:16:49 ScribeNick: TabAtkins_ 16:16:52 Rossen has joined #css 16:17:44 Present: Peter Linss, fantasai, Leif Arne Storset, Florian Rivoal, David Baron, Tab Atkins, Tantek Çelik, Ted O'Connor, Alan Stearns, Rossen Atanassov, Glenn Adams, John Daggett, Vincent Hardy, Steve Zilles, Bert Bos, Sylvain Galineau, Daniel Glazman 16:17:48 jdaggett has joined #css 16:17:58 [sorting through agenda items] 16:17:59 vhardy_ has joined #css 16:18:58 tantek has joined #css 16:20:03 vhardy_ has joined #css 16:24:34 krit: yes, once we finish making it 16:24:44 hober: great, thanks! 16:25:12 hober: W3C STYLE conference room for dialing in? 16:27:05 krit: i assume so 16:29:38 do we have a phone in this room? 16:33:41 does someone have a cell phone if not? :P 16:34:23 SteveZ has joined #css 16:34:28 ScribeNick: fantasai 16:34:31 Topic: @supports 16:34:37 dbaron: We've published one WD to /TR 16:34:41 dbaron: There's been some minor tweaks 16:34:48 dbaron: and the addition of a bunch of OM stuff to spec 16:34:49 http://dev.w3.org/csswg/css3-conditional/ 16:35:08 dbaron: Want to discuss mainly OM stuff today 16:35:29 dbaron: One piece is relatively straightforward, 8.1 is numbers, we used 12 and 13 16:35:35 dbaron: 8.2 is relatively straightforward 16:35:54 dbaron: in that we already have an interface for MediaRule that has all but the first attribute here 16:36:03 dbaron: instead of conditionText it has mediaText 16:36:11 dbaron: 1. Is conditionText right 16:36:24 dbaron: 2. Do we want a parent interface on which the bottom three are shared 16:36:58 glazou: We ask browser if it supports a property and a value 16:37:12 Tab: No, it's more than that -- it's conjunctions with and/or/not, not just a sigle property declarations 16:37:23 Tab: You could make a tree structure for it, but I don't know how valuable that is 16:37:30 dbaron: Doubles implementation work of @supports 16:37:41 Florian: Let's not do that until someone asks for it 16:37:53 dbaron: I named it conditionText to match a bunch of other things that end in Text in the OM 16:38:49 fantasai: Question, it's medaiText for MediaRule, why is it conditionText for SupportsRule? 16:39:08 Tab: you're thinking it should be supportsText? 16:39:43 Tantek: Seems confusing, asking if it "supports Text" 16:40:23 fantasai: But all these things are condition rules, why is only this one called conditionText 16:40:49 Florian: Would be nice if all three rules used conditionText 16:41:07 dbaron: I think mediaText is in the other chapter of DOM 2 Style... 16:41:43 Florian: So .media.mediaText could be equivalent to .conditionText 16:41:52 Florian: And have all of them have .conditionText 16:42:17 Daniel: So for @media, .media.mediaText and .conditionText would be equivalent? 16:42:25 dbaron: yes 16:42:37 glazou: for both getting and setting? 16:42:39 dbaron: yes 16:43:05 glazou: Wrt additional interface, would that get implemented? 16:43:13 (additional common interface) 16:43:34 dbaron: My inclination would be to put it in the spec and mark it at risk 16:43:52 (agreement) 16:44:31 Florian: Back on conditionText itself, need to define how serialization works 16:44:43 Florian: In your stylesheet, if you have not not not, do you collapse into one not? 16:44:51 Tab: Are you allowed to do logical simplifications 16:44:55 Florian: I'd like to simplify 16:44:59 Tab: I'm ok with that 16:45:31 Florian: also multiple nested parens that don't do anything, can you collapse that 16:45:43 dbaron: Don't want to require that ... 16:45:50 Florian: Want to have identical serializations across browsers 16:46:05 dbaron: We wanted to use a token string 16:46:17 Florian: We copy the string exactly from the style sheet 16:46:26 Florian: ... we simplify 16:46:34 dbaron: I don't think there's a need to simplify 16:46:39 dbaron: It's extra code on our end to simplify 16:46:49 Florian: In my case what I wrote was the easiest implementation 16:47:26 Glenn: Need to define this if you want to test it 16:47:44 fantasai: Authors will want to predict what they get back, and get consistent result,s if they want to tweak it and write it back 16:48:18 Florian talks about preserving invalid conditions 16:48:23 Present: Peter Linss, fantasai, Leif Arne Storset, Florian Rivoal, David Baron, Tab Atkins, Tantek Çelik, Ted O'Connor, Alan Stearns, Rossen Atanassov, Glenn Adams, John Daggett, Vincent Hardy, Steve Zilles, Koji Ishii, Bert Bos, Sylvain Galineau, Daniel Glazman 16:48:25 Glenn: What about white space and comments? 16:49:03 fantasai points to the current spec, which has a proposal 16:49:25 dbaron: I think in order to preserve semantics, you need to preserve where comments are, if not what's in them 16:49:36 Florian: Seems easier to just pass through the string 16:50:09 glazou: So you empty the comments, and report back an empty comment? 16:50:18 Florian: No, if we do this, we'd preserve the comment 16:50:53 dbaron: Sounds like we both implemented at a layer above the tokenizer, went back to stylesheet and pulled out the text 16:51:05 glazou: Still match curly braces etc? 16:51:26 dbaron: As we parsed, yes. We mark the start and end in the style sheet data, and pull that directly back out 16:52:04 glazou writes on the board: 16:52:20 @supports (foo: {;};); 16:52:57 dbaron: That's syntactically because of the second semicolon... and the third semicolon 16:53:03 glazou errases that and writes 16:53:13 @supports (foo: {;} blah) 16:53:18 glazou: Catch everything correctly? 16:53:20 dbaron: yeah 16:53:29 Florian writes 16:53:39 @supports (foo: {;} blah) and (bar:baz) 16:53:55 Florian: We preserve the contents of the parens, but we parse and normalize the structure around it 16:54:21 Florian adds more parens and double nots, points out that they get simplified out 16:54:36 dbaron: We don't preserve any structure 16:55:38 Florian discusses .condition, which would have a tree structure, and whether that should be simplified 16:55:45 plinss thinks it's better not to simplify 16:56:10 plinss: Reason not to simplify is that I'll want to mainpulate via script, plug things into levels, don't want those levels to disappear on me 16:56:25 glazou: I think I prefer dbaron's approach 16:56:56 glazou: Being able to read back the condition exactly as the author wrote it is good 16:57:11 Glenn: what about the case when you construct via script? 16:57:19 dbaron: It's the same 16:58:08 dbaron: I want to allow outputting a token stream rather than the text from the style sheet, so the implementation could replace \S+ with a space 16:58:17 dbaron: And would be allowed to drop contents of a comment, could do so 16:58:24 dbaron: They can't drop the comment 16:58:40 glazou: I would prefer if you don't do that 16:58:58 Tab: Would prefer to do that, because otherwise you have to go back to the source text 16:59:13 Tab: Once you have a parse tree, theoretically you should be able to kill the source text 16:59:36 Tab: The exact source text doesn't exist in the parse tree, because the parse tree is made of tokens 17:00:59 Tab: Implementations that don't preserve the source text should be able to implement this 17:01:45 dbaron: While what I'm proposing isn't 100% precisely defined, it's better than almost everything else in the CSSOM 17:01:45 TabAtkins_ has joined #css 17:01:54 ChrisL has joined #css 17:02:26 glazou: I want to read the proposal before accepting it 17:03:23 RESOLVED: Have intermediary condition rule interface 17:03:28 (name TBD) 17:03:51 Discussion of grouping rules (contain declarations) vs. others? 17:04:04 Tab: Need to look at @keyframes 17:04:14 plinss: @page 17:04:51 RESOLVED: .conditionText goes on that common interface 17:04:55 RESOLVED: conditionText on the common interface, for @media is equivalent to .media.mediaText 17:05:21 glazou: If it's conditionText, should be ConditionRule 17:05:27 glazou: to be consistent 17:05:51 RESOLVED: CSSConditionRule 17:05:52 (Tab suggests we have GroupRule and ConditionRule.) 17:06:30 RESOLVED: conditionText returns either the token stream or source text from the style rule, with no logical simplifications, just tokenization ones 17:06:47 (i.e., could optionally collapse whitespace or drop contents of comments) 17:07:21 jdaggett: What should we be doing for new @rules, are we defining a specific serialization? 17:07:25 Florian: This one is pretty specific 17:07:36 glazou: I suggest we take that question to the OM discussion 17:08:25 glazou: DocumentRule? 17:08:38 Florian: have to decide normalization of conditionRule for URLs 17:08:54 dbaron: normalization of urls is hard, might require us to drop @document from the spec atm 17:09:13 dbaron: 9.3 is OM interface to do @supports queries 17:09:35 dbaron: I feel strongl that this should not allow logical combinations, because JS can do that 17:10:17 glazou: We had the exact discussion with matchMedia, and came to the exact opposite conclusion 17:10:50 glazou: supportsCSS is good as it is, maybe we need another interface too 17:11:03 Tab: We did the entire media query for matchMedia so that you could attach a listener 17:11:17 glazou: I agree, but from an author's perspective 17:12:12 ... 17:12:25 sylvaing: People will want to pull from conditionText and put it into the matching function. 17:12:41 Tab: you can't interchange media queries and support queries 17:12:51 Tab: There are some that look identical 17:13:33 fantasai: So, the comment I have here is that supportsCSS seems very general, but this only takes a property-value pair 17:13:43 Tab wants the name to be short 17:14:06 sylvaing: Is there any objection to the functionality here? 17:14:17 glenn: Do you want to query a property with any value? 17:14:23 Tab: We are specifically *not* doing that. 17:15:02 glenn: I'm ok with the functionality, concerned about where it is atteched (window object) 17:15:35 glenn: Could attach to navigator 17:15:38 CSSStyleSheet 17:15:42 CSSDeclaration 17:15:51 Tab: I propose creating a new CSS object and attaching it to that 17:16:08 Tab: Right now the constructors for everything else have enormous names, e.g. CSSPixelValue 17:16:17 Tab: would be nice to be able to say CSS.px() 17:16:34 Florian: 3 acceptable proposals to me: window, navigator, or what Tab is saying 17:16:46 fantasai agrees with Florian 17:17:47 Glenn: Keep in mind that properties on window are shadowable 17:18:08 dbaron: That was true in ECMA262 Edition 5, which was regresion from Edition 3, and was fixed in 5.1 17:19:26 fantasai: [...] 17:19:39 dbaron: want to avoid supportsProperty because ECMA uses properties 17:20:06 dbaron: Could be ok with supportsCSSValue 17:20:13 Florian: CSS.supportsValue 17:20:17 Florian: Still reasonably short 17:20:37 fantasai^: Would expect CSS.supports() to be the function that takes the whole @supports condition string 17:20:38 +1 to supportsValue 17:21:57 some meta-discussion 17:22:28 Florian points out it is being implemented now 17:23:07 jdaggett is not buying this argument, we get a lot of this situation of implementing things in editor's drafts 17:24:16 fantasai proposes compiling list of proposals, posting to www-style, discussing over breaks, and revisiting later 17:24:39 Bert: Does window always exist? 17:24:50 Tab: A global object exists, and for compat reasons it's called window 17:25:35 0. window.supportsCSS() 17:25:40 1. CSS.supportsValue() 17:25:52 2. CSS.supports() 17:26:02 CSS.supportsPropertyValue() 17:26:08 no! 17:26:19 ACTION glazou: email www-style 17:26:19 Created ACTION-489 - Email www-style [on Daniel Glazman - due 2012-08-20]. 17:27:11 Florian: Issue -- you strip WS at the ends, do you also strip comments? 17:27:37 dbaron: You trim the property name, because it has to be a property name 17:28:01 Florian: So, around value, whatever, around property, nothing. Ok 17:28:49 dbaron: Expects property to be a property, and value to be anything that's allowed in the value, including white space and comments 17:29:02 Bert: Is the property normalized? 17:29:09 fantasai: What about escapes 17:29:26 dbaron: You're not parsing CSS, just taking a property name 17:29:39 Bert: Unicode normalization? 17:30:08 Tab: Not an issue, our properties are all ASCII 17:30:15 sylvaing: What if you pass in a variable name? 17:30:39 RESOLVED: property name must be the name, no escapes, no spaces, it's not parsed it's just a name. value can be anything taken as a value 17:30:49 glazou asks about tests 17:30:59 Opera has submitted theirs, Mozilla needs to submit theirs 17:31:11 O(100) tests 17:31:45 that's the same as O(1) 17:50:19 Koji has joined #css 17:51:20 my word-count/test ratio heuristic says that css3-conditional will need 334 tests 17:52:17 vhardy_ has joined #css 17:52:28 vhardy__ has joined #css 17:53:55 smfr has joined #css 17:56:59 Tab: So, fantasai Florian and I have a suggestion 17:57:18 Tab: We like CSS.supports(), but it implies very generic, so have that take the conditionText of a supports rule 17:57:56 Tab: Don't like how matchMedia requires parens around a single thing, so I like 2-argument form for readability for simple tests 17:58:25 fantasai: For two-value, was it CSS.supportsValue()? 17:58:51 Florian: No, CSS.supports() with two arguments it works as currently defined 17:58:59 Tab: So I'm suggesting CSS.supports() 1-argument form taking an @supports condition and a 2-argument form taking property and value 17:59:16 dbaron: I'm worried that creating this CSS object might be more controversial 17:59:21 dbaron: But I'm ok with giving it a try 17:59:37 hober: Concerned about compat with random websites that use CSS as a global 17:59:49 Tab: If CSS doesn't work, ok with reverting to window.suppportCSS 17:59:49 Glenn prefers CSSStyleRule.supports 18:00:18 Tab: We wouldn't look at that until testing support for @rules anyway 18:00:26 szilles: It isn't CSS supports, its UA supports 18:02:00 RESOLVED: CSS.supports() with one (conditionText-compatible) or two (property, value) arguments. Fall back to window.supportsCSS if not possible. 18:02:08 ACTION TabAtkins: ask WebApps about global CSS object 18:02:08 Sorry, couldn't find user - TabAtkins 18:02:09 dbaron: Don't have an extra feedback request to www-style right now (reduce bikeshedding); we'll get feedback on the minutes and on the draft. 18:02:48 ScribeNick: dbaron 18:02:51 Topic: Selectors4 18:03:58 -di-cold-glazou 18:04:32 http://dev.w3.org/csswg/selectors4/ 18:04:53 fantasai: some changes since we last discussed this 18:05:01 fantasai: scoped selectors (3.3): we defined 2 ways of scoping selectors 18:05:15 fantasai: these are the 2 ways available in HTML and the OM. We gave them names so those specs can refer here. 18:05:21 fantasai: Updated prose for :scope pseudo-class. 18:05:42 Tab: If someone can come up with better names than contained and constrained, that would be appreciated. Not different enough. 18:06:15 glazou: querySelector on an element? 18:06:23 fantasai: yeah, example 2 should refer to Element.querySelector() 18:06:41 fantasai: Other change to discuss is 8.4: :valid-drop-target 18:07:13 fantasai: We resolved to add this. 18:07:36 fantasai: But Sylvain pointed out that we should be limiting it to the one that you'd drop it on right now 18:07:47 glazou: :valid-drop-target:active ? 18:07:57 fantasai: It's not being activated right now. 18:08:12 glazou: Like when you click and haven't released the button yet 18:08:26 fantasai: I think it would be more confusing. 18:08:37 fantasai: I looked over other suggestions in the minutes, other suggestions were :active-drop-target 18:08:51 fantasai: We switched in order to distinguish between valid and invalid drop targets. 18:09:03 fantasai: But that seems a bit abstract. I think Sylvain's issue is more important. 18:09:27 fantasai: We could have three pseudo-classes (maybe not now, but in the future): we could have :valid-drop-target and :invalid-drop-target that indicate possible drop targets. 18:10:33 [discussion about invalid vs. not drop target] 18:10:55 fantasai: proposal is to rename to :active-drop-target, and if we want to distinguish :valid and :invalid later we can add them 18:11:28 glazou: Behavior you describe is not in conformance to mouse clicks 18:11:46 glazou: I think :valid-drop-target:active is better 18:11:50 glazou: Need :dropped 18:12:12 fantasai: Original request is what will recieve the drop if I let it go 18:12:24 fantasai: I don't want to have to combine pseudos for this 18:13:05 Tantek: other name suggestions from cursor:no-drop 18:13:19 cabanier has joined #css 18:13:48 fantasai: If we went with that, :active-drop, :drop, :no-drop 18:14:32 how about :drop-target and :no-drop-target 18:14:33 fantasai: :active-drop would be the thing about to receive the drop if dropped now, :drop is any valid drop target, and :no-drop is a drop target that's not valid 18:14:49 Tab: [speaking at >150wpm] 18:14:59 arronei, I like :active-drop and :drop, they're nice and short 18:15:08 arronei, the -target part doesn't seem necessary 18:15:14 Tab: The :invalid pseudo-classe doesn't apply to all the dom, only things with validity constraints. 18:15:57 just saying :drop isn't explicit enough in my opinion 18:16:31 does it mean I can drop something or I am dropping something? 18:17:00 Bert: difference between :active-drop and :drop:hover ? 18:17:14 fantasai: might not need to actually be inside the boundary 18:17:16 q+ 18:17:38 fantasai: Solitaire on windows actually has two options for this behavior: can go to the closest one 18:17:49 Bert: at least cover a part of it? 18:17:52 fantasai: not in all interfaces 18:18:11 Florian: [asked Q] 18:18:38 Florian: difference between :drop:hover and :active:drop -- in theory? in practice? 18:18:40 q+ 18:18:49 fantasai: [really fast] 18:19:16 ack dbaron 18:19:16 dbaron: You might not be triggering :hover at all with drag and drop 18:19:25 ack tantek 18:19:30 fantasai explaining that interfaces might trigger drops even if not hovering 18:19:35 e.g. solitaire on windows 18:19:37 Tantek: I think this use of :active is a different semantic from :active elsewher 18:19:58 Tantek: bad from teaching perspective. Closer to :hover than :active. 18:20:07 Florian: :current-drop ? 18:20:18 Tantek: with some drag&drop interfaces, button might not be down 18:20:35 Tab: I like :can-drop 18:20:41 Florian: That's :drop, not :active-drop 18:20:59 fantasai: :will-drop, :can-drop, :no-drop 18:21:11 fantasai: :current-drop, :can-drop, :no-drop 18:22:00 Tantek: :can-drop, :drop, :no-drop 18:22:29 Koji has joined #css 18:22:37 (these are in order of replacing :active-drop-target, :valid-drop-target, :invalid-drop-target) 18:22:55 fantasai: :drop, :can-drop, :no-drop 18:23:11 Florian: :current-drop, :valid-drop, :invalid-drop 18:23:37 Florian: I don't like :no-drop because it sounds like it includes things that aren't drop targets. 18:24:06 Peter: but value in being consistent with cursor 18:24:18 ?: no-drop cursor could be used where not a drop target 18:24:22 Tantek: That's not how it's used in UIs. 18:24:30 glazou: I'm not seeing this discussion going anywhere. 18:24:48 fantasai: I like these 2, these 2 ok, really don't like these 2. 18:25:22 now down to: 18:25:29 :active-drop, :drop, :no-drop 18:25:34 :drop, :can-drop, :no-drop 18:25:44 :current-drop, :valid-drop, :invalid-drop 18:26:05 Steve: I don't like :drop 18:26:27 ACTION fantasai to email www-style about the possiblities 18:26:27 Created ACTION-490 - Email www-style about the possiblities [on Elika Etemad - due 2012-08-20]. 18:26:37 Florian: I suggest putting all 3 in the spec 18:27:00 and put the later two at risk 18:27:02 fantasai: Next thing for discussion is :user-error (11.5) 18:27:08 drublic has joined #css 18:27:29 fantasai: We had proposal for :-moz-ui-invalid, :invalid limited to when user has already interacted with it. 18:27:41 fantasai: Mozilla has some heuristics for when :-moz-ui-invalid is triggered 18:27:54 fantasai: But the ideas it do it when you actually want to highlight things as invalid. 18:28:31 fantasai: Tab and I came up with the name :user-error, a control that is required but not yet filled in, but has invalid input 18:28:55 glazou: In case of elements implemented by UA, I understand. What about elements implemented by the Web author? 18:29:11 Tab: setCustomValidity can do that 18:29:33 dbaron: The problem we're dealign with here is that some elements are invalid when they haven't yet received input. 18:29:49 dbaron: If someone is doing a custom control, they need to call setCustomValidity in that state where they haven't yet received input. 18:29:59 dbaron: ...so the form cant' be submitted in that state. 18:30:10 dbaron: But you still need to know when the control has received input. 18:30:21 need an API for that 18:30:43 Tab: Not sure that's necessary here because if it's a custom control, you can put a class on it 18:31:29 fantasai: [reads definition of :user-error] 18:31:47 Tab's prose has :user-error :-) 18:33:12 dbaron: [explains rationale for :-moz-ui-invalid] 18:33:55 fantasai: In terms of custom controls, you want it to really be invalid whenever it's invalid. 18:34:15 Tantek: More background here: one of the reasons for :-moz-ui-invalid was a short-term fix to be able to build UI because :invalid wasn't reasonable for UI. 18:34:47 Tantek: But there was discussion of not trying to combine meanings in one pseudo-class -- there was discussion of having a pseudo-class for whether the user has interacted with the element at all. 18:35:10 Tantek: If we're actually trying to fix this properly, we might want to consider this orthogonal pseudo-class. 18:35:23 Tantek: That was the context of the discussions about how :-moz-ui-invalid came to be. 18:35:42 fantasai: I'm happy to spec whatever you want to implement. 18:35:48 Bert: Sounds like :fresh 18:35:51 Tantek: or the opposite 18:36:01 Tantek: :user-dirtied 18:36:05 fantasai: :user-interacted 18:36:25 Tantek: A little vaguely defined -- tabbing through, clicking and then clicking elsewhere 18:36:36 Tantek: Don't want prematurely precise specification. 18:37:35 Tantek: ... distinguish between user-interacted with form or interacted with element? 18:37:48 Peter: We can't know what all possible ways of interaction will be over next 10 years. 18:38:03 Tantek: specify a simpler thing that designers can combine to get effects 18:38:13 fantasai: I think we should spec :user-error 18:38:27 isherman has joined #css 18:38:38 fantasai: e.g., because we need things to be highlighted after user tries and fails to submit form 18:38:59 fantasai: I think we should spec this, and add that later when more concrete 18:39:06 leaverou_ has joined #css 18:39:12 Tantek: This is just as concrete -- just the same thing without the intersection with :invalid 18:40:50 Florian: How do you select thing when user pressed submit, failed, and the user never interacted with control? 18:42:06 [lots of fast talking] 18:42:34 fantasai: could split out :user-omitted and :user-invalid 18:42:54 Florian: I'd like to have :user-error and also have what Tantek suggested 18:42:58 Florian: ... 18:43:02 Tab: That's placeholder 18:43:30 Tantek and Tab argue about how form UIs are designed 18:43:40 fantasai: Any objections to adding :user-error as is? 18:43:51 Bert: Can we add something like what Tantek said? 18:44:00 Tantek: I'd like to also mention :user-interacted 18:44:07 fantasai: I think it's separate 18:44:16 Tantek: Potentially makes :user-error unnecessary. 18:44:43 RESOLVED: Have :user-error as-is, and have an issue about :user-interacted. 18:44:56 Tab: Next up is the minor changed to the reference combinator. 18:45:10 Tab: We changed this to allow host languages to... 18:45:19 Tab: Before, attribute had to be IDREF or ID selector. 18:45:30 Tab: Now, have use cases from Web Components that want more ways to match. 18:45:46 Tab: Host language can define alternate ways (e.g., full selectors). 18:45:56 glazou: reference combinator badly needed for epub 18:46:26 fantasai: Then the column combinator (14.1) 18:46:40 q+ 18:46:52 fantasai: this is a combinator, not a pseudo-class (as it was in previous draft) 18:47:07 fantasai: needs knowledge of the host language 18:47:33 fantasai: anything with a tabular structure and a row-major table 18:47:45 fantasai: In a column-major model, it's a row combinator. 18:47:53 glazou: The // are really too similar to a reference combinator. 18:48:02 glazou: why not || ? 18:48:08 Tab: Intended to look like a reference combinator 18:48:22 glazou: I don't want 2 things, one with keyword inside and the other without keyword inside. 18:48:28 fantasai: I'm happy with either option. 18:48:42 glazou: I'm happy with anything, but these really look too similar. 18:49:38 dbaron: I think I'm not happy with the change from pseudo class to combinator, but I don't remember why 18:50:24 fantasai: pseudo-class would create branching structure 18:50:28 ack dbaron 18:51:03 fantasai: Combinator intended to express relationship between elements, not pseudo-class. 18:51:49 glazou: Impossibility to use :nth-child() and friends to style rows and columns with spans. 18:51:59 dbaron: There's another selector here for that. 18:52:24 dbaron: concerned wrt perf for combinator rather than pseudo-class 18:52:30 q+ to ask if that would also work for 'dt#d1 // dd' for "any of the DDs that belong to the DT with ID=d1"? 18:52:46 dbaron: authors will tend to write the faster option with the pseudo-class, but the slower with the combinator 18:53:03 dbaron: Now that UAs have implemented filtering for descendant combinators 18:53:13 dbaron: maybe that's not a huge problem... 18:53:21 dbaron: Another perf problem I forget 18:53:44 glazou: Alan and I wrote a document for pseudo-elements. 18:54:13 glazou: at some point want to eliminate restriction on other selectors to the right of pseudo-element 18:54:34 glazou: and then we could have the column as a pseudo-element and have selectors inside the table 18:55:06 dbaron: I actually have a model for selectors to the right of a pseudo-element specified in the overflow draft right now, based on discussions from one of our meetings 18:55:55 ACTION fantasai: summarize all issues raised here into the draft 18:55:56 Created ACTION-491 - Summarize all issues raised here into the draft [on Elika Etemad - due 2012-08-20]. 18:56:11 Sylvain: This is dependent on document-language constructs? 18:56:12 fantasai: yes 18:56:28 fantasai: So wouldn't apply to grids, applies to table elements, not display:table. 18:56:35 fantasai: So, determining the subject of a selector 18:56:42 fantasai: Discussion on the list about syntax. 18:56:56 fantasai: Currently using an ! after the subject of the selector. 18:57:20 fantasai: Seemed better to append it because it splits the selector better when appended. 18:57:52 fantasai: We need to put something on the compound selector, and it either needs to be before or after. 18:58:17 glazou: Implemented this in STTS 14 years ago. 18:58:26 glazou: Want ! at beginning because it's visible; hard to see at end. 18:58:35 fantasai: ! at beginning also looks like "not" 18:58:56 drublic has joined #css 18:59:09 glazou: Everybody confused by !important, but everybody using it without a problem. 18:59:35 fantasai: We need something either before or after subject. 18:59:40 fantasai: How does this work with pseudo-elements? 18:59:59 glazou: Alan and I extracted pseudo-elements spec from selectors4. 19:00:25 glazou: I think we have two things related to pseudo-elements: syntax, and then various pseudo-elements and the behavior they express. 19:00:43 glazou: I think extraction of pseudo-elements makes sense. 19:01:09 glazou: Pseudo-elements spec has informative, brief description of syntax. 19:01:54 fantasai: I would like people to think about this and I'll try to make the edits to :user-error. My goal is to publish a WD on Thursday. 19:02:05 Sylvain: Did we talk about :lang updates 19:02:12 fantasai: I was goin to in Hamburg, but forgot 19:02:24 fantasai: :lang() now accepts comma-separated list, and wildcard matching for BCP47 19:03:03 Florian: This was valuable for Metro? 19:03:09 Sylvain: Yes, can make style sheets a lot shorter. 19:03:50 fantasai: Are people ok with this? 19:04:24 in scenarios where the content supports many languages - web apps/widgets, ebooks - this significantly shortens selectors 19:04:41 fantasai: Edits tonight, and maybe we can resolve to publish tomorrow? 19:06:06 Tantek: Maybe capture ! syntax as an issue and publish that way? 19:06:09 glazou: I'm not ok with that 19:06:19 fantasai: I'd like to resolve this issue or drop the feature. 19:06:44 glazou: I want it specified as prepend, though I'm ok with an issue noting that it's an issue. 19:06:56 Peter: Or we could do both. 19:07:03 Tab: Do we expect this to be implemented in normal CSS? 19:07:05 vhardy_ has joined #css 19:07:14 did peter mean "before or after" or "before and after"? 19:07:25 both 19:07:32 Tab: I'd like to move this to a profile for batch processors. 19:07:35 before and after 19:07:48 glazou: Top user feedback since 1998. 19:08:25 fantasai: Do we want profiles for dynamic and non-dynoamic? 19:08:36 glazou: we already have some profiles 19:09:01 fantasai: I'll create a profile that excludes it from dynamic 19:09:30 RESOLVED: ! before the selector (with issue about after) 19:09:38 Bert: Append with a space between? 19:10:21 €ul > li:only-child 19:10:56 Tab: Being able to style a column when you hover it isn't addressed by anything. 19:11:02 Tab: Because the column element isn't in :hover 19:11:34 glazou: stuff on the right of pseudo-element! 19:11:59 RESOLVED: publish new WD of selectors4 19:12:05
19:13:19 Koji_ has joined #css 19:31:51 jet has joined #CSS 19:45:48 Koji has joined #css 20:11:18 jet has joined #CSS 20:15:54 ScribeNick: fantasai 20:16:23 Tab: I was thinking about asking for FPWD, but think it's not quite ready yet 20:16:39 Tab: The purpose of bringing up here is to explain reasoning between having syntax draft 20:16:50 Tab: and get objections / feedback up front rather than later 20:17:10 Tab: CSS grammar is hard to work with a complicated grammar scheme, especially one that tries to be total -- to handle all possible byte streams 20:17:16 Tab: There are some things that are officially undefined 20:17:31 Tab: Even some cases defined, there are coner cases that are handled differently by different browsers 20:17:43 Tab: What I've done instead, instead of using a grammar, is to define in terms of a state machine parser 20:17:51 Tab: Broken up into 2 steps like HTML parsing algo 20:17:56 Tab: Fist step is tokenizer, other is parser 20:18:04 Tab: resulting in a CSS OM 20:18:12 Tab: Goal is to make everything extremely well-defined 20:18:17 Tab: Also make it easy to modify, 20:18:28 Tab: And easy to read and understand 20:18:39 Tab asks dbaron for feedback 20:18:58 dbaron: Some of it, I just don't quite understand what states your state machine goes through in the parser 20:19:02 dbaron: Not so worried about tokenizer side 20:19:28 Tab: There's a top-level state, and then 3 substates: at-rule, selector, .. 20:19:37 Tab: at-rule mode or selector mode, depending on what is seen 20:19:47 http://dev.w3.org/csswg/css3-syntax/#top-level-mode- 20:20:12 Tab: parser very easy to write, took me about a day. Tokenizer took about a week 20:20:25 dbaron: Part of what worries me is that 20:20:36 dbaron: defining correct error recovery with this parser spec 20:20:47 dbaron: we have a bunch of abstract error-recovery rules, we know exactly what they mean 20:20:59 dbaron: With this spec, seems easy to get the error-recovery rules wrong in the spec 20:21:09 Tab: Differing implementations of those rules 20:21:25 Rossen has joined #css 20:21:27 dbaron: Because easy to make mistakes in the implementation 20:21:47 dbaron: Also some rules are well-understood in CSSWG, but poorly explained in spec, so we have a clear definition, but others can't interpret one so easily 20:21:56 dbaron gives an example of matching curly braces 20:22:14 dbaron: If you describe that as an abstract rule, you describe it and you're done 20:22:30 dbaron: If you do it as a state machine, you need to fall into that out of many different states 20:22:43 Tab explains how he handles it 20:22:45 in the spec 20:23:02 Tab: I think I've handled that correctly 20:23:23 Florian: Even if you do it right now, wouldn't what dbaron says mean we might easily make mistakes in future extensions? 20:23:33 Tab: I think I've defined it in away that you get it for free 20:23:37 dbaron talks about a stack of stacks 20:23:50 dbaron: Stack defines recovery points 20:23:58 Tab: Initial concept is stacks, where you can enter an error 20:24:17 vhardy_ has joined #css 20:24:22 Tab: Once you enter an error state, it knows how to consume to where it needs to be. Consumes a block s part of that, no further error handling there 20:24:35 dbaron: We should probably sit down together some other time 20:24:53 Tab: There are some minor changes to the grammar, discussed by the group 20:25:06 Tab: Including the plus-or-minus sign direction in the definition of NUMBER token 20:25:43 Tab: Group resolved to include that already 20:26:01 Tab: A few other places with corner cases or inconsistencies. Need to list them 20:26:28 Florian: Didn't you discuss at some point not accepting comments between ! and important? 20:26:45 Tab: One issue that makes parser hard to handle right now... gives parser infinite lookahead 20:26:53 Tab: Appears we need to retain comments in token stream 20:27:06 Tab: Then you can have unlimited number of tokens between ! and important 20:27:23 Tab: !/*comment*/ /*... */ /*...*/important 20:27:39 Tab: ... 20:27:47 dbaron: I don't see what you mean here. 20:27:53 dbaron: why is this lookahead? 20:28:00 dbaron: You get a ! 20:28:06 dbaron: you go into "parsing !important" path 20:28:16 dbaron: Either you get identifier "important" 20:28:26 dbaron: Or you get something else, in which case you go into error condition 20:28:50 Tab: Issue is, it's not always an error 20:29:01 Tab: could have it in a variable 20:29:07 dbaron: Think we should change it so ! can't show up in a variable 20:29:24 Tab: ! would be counted as a delim, which is a valid part of a variable 20:29:47 ... 20:29:59 dbaron: Don't think saying you can't have a ! in variable prevents [that] 20:30:10 Tab: Then I'd have to be more explicit in the grammar 20:30:20 Tab: Before, just match value production, and everything worked 20:30:54 ... 20:31:08 Florian: Do people put comments between '!' and 'important'? 20:31:44 glazou: You should check 20:31:51 Bert: I don't think we need to check, there's no reason to change it 20:32:14 Tab: Plan to ask FPWD within next 2-3 weeks 20:32:19 Tab: Please bring up objectins on the list beforehand 20:32:32 Bert: Would like the grammar normative, not the state machine 20:32:38 Tab: I would like the opposite 20:33:35 Tab: If the grammar doesn't cover every possible input stream, then it's not well-defined error recovery 20:33:45 Bert: I don't care about those 20:33:49 jdaggett: Why not? 20:34:17 jdaggett: There are many features of CSS that are implemented only within more recent versions of a browser, they are handled as errors by older browsers 20:34:23 Bert: But all of those are within the core grammar 20:34:46 Bert: original model was only to define correct style sheets, slowly been adding more rules to handle errors 20:34:58 Tab: I care that we define all error-handling 20:35:05 Florian: And all interpret them the same way 20:35:26 Florian: For HTML parsing, having common CSS handling has been important to get interop 20:35:32 Florian: Think the situation is not as bad for CSS 20:35:46 Florian: I'm tempted to go this way, though I don't think we need it as badly as HTML 20:36:10 Tab: We have inconsistent/poorly-explained rules for handling e.g. braces. Want to make this obvious and clear. 20:36:26 s/braces/braces in unexpected places/ 20:36:38 Tab: Can implement as not a state machine 20:36:47 Tab: as long as results match 20:37:03 Bert: Can't, if it's a state machine have to parse in start-to-end order 20:37:20 Bert: Proving this one is the same as the CSS2.1 grammar is going to be hard 20:37:27 Tab: Plan to throw lots of tests at it 20:37:48 Bert: We need to prove the spec, not the implementations here 20:38:04 Bert: Looks like a big step backwards to replace one page of nice grammar with however many pages of text 20:38:19 Tab: The one page of nice grammar isn't interpretable by normal people without help from the CSSWG 20:38:49 sylvaing: Implementers prefer this (the state machine) 20:39:29 Bert: Context-free grammars were meant to replace this kind of thing 20:39:41 Tab: Context-free is great for things like properties, where once it's invalid, you're done 20:40:05 Tab: But doesn't work so well for general total parsing 20:40:27 Bert: When adding new features, need to know what is valid per grammar 20:40:50 Tab: Grammar's are great for higher-level things, not so great for parsing 20:42:16 ACTION TabAtkins: Fill out Changes from CSS 2.1 Core Grammar section, intro etc. 20:42:16 Sorry, couldn't find user - TabAtkins 20:42:56 Topic: Case-insensitive/sensitive identifiers 20:42:57 ACTION Tab: Fill out Changes from CSS 2.1 Core Grammar section, intro etc. 20:42:57 Created ACTION-492 - Fill out Changes from CSS 2.1 Core Grammar section, intro etc. [on Tab Atkins Jr. - due 2012-08-20]. 20:43:32 jdaggett: need to discuss case-insensitivity issue 20:43:38 fantasai: Don't think it's a parsing issue 20:44:26 jdaggett: I think some of the arguments made about case-sensitivity are wrong 20:44:37 ACTION: fantasai and jdaggett to discuss case-sensitivity at the break 20:44:37 Created ACTION-493 - And jdaggett to discuss case-sensitivity at the break [on Elika Etemad - due 2012-08-20]. 20:45:44 ScribeNick: TabAtkins_ 20:45:52 Topic: CSS Fragmentation 20:46:10 fantasai: There was a bunch of outstanding edits from Hamburg and in-between. 20:46:18 fantasai: One was adding recto/verso to the break properties. That's done. 20:46:33 fantasai: Another was the "Splitting Boxes at Breaks" section. 20:47:14 fantasai: We'd decided that if the box is block-level with a specified height.. 20:47:29 fantasai: I interpreted "specified height" in the resolution as "specified length or percentage". 20:47:36 fantasai: We didnt' discuss non-block elements. 20:47:52 fantasai: I put inline in the "doesn't stretch to the end of the fragment" category. 20:48:04 dbaron: Limiting the extra-space rule to length or percentage... 20:48:15 dbaron: If you have min-content, I think you want it there. 20:48:36 dbaron: You don't want a break to make height:min-content overflow. 20:49:23 fantasai: Different issue. height:min-content will *draw the background* in the rest of the fragment, but yeah, it won't consume any of the height, so it wont' overflow. 20:49:46 dbaron: That it doesn't consume any of the specified height should apply to all types of heights. 20:49:55 fantasai: The other case we didnt' discuss was table-cells, grid cells, and flex items. 20:50:10 fantasai: The reason we decided not to draw the bg was if you were lining up your background with the content. 20:50:31 fantasai: But in the other layout models, flex/grid/etc, you're putting things side-by-side. You want the boxes to end together. 20:50:46 fantasai: So I think it makes sense for those to draw to the bottom of the page. 20:51:06 szilles: I'm hearing use-cases for both solutions. 20:51:16 szilles: So you'll probably want a property for this later. 20:52:04 szilles: So it seems simpler to just pick a single answer for all of these for now, even if it's suboptimal for some, and address it later with an explicit property, rather than choosing different answers for lots of different things. 20:52:32 fantasai: I would almost rather have none of them gap, than all of them gap. 20:52:59 szilles: Yeah, sure. I just think people will be more confused by having to deal with an 'auto' value that chooses things "intelligently" than having a single answer that's not always correct by default. 20:53:47 fantasai: [shows some ascii diagrams of the behavior we ended up deciding on for slice/clone for blocks\ 20:54:17 fantasai: So, do we accept the edits? 20:55:38 fantasai: Basically what I have is that anything that's not a block *always* does the behavior where it extends to the bottom. 20:55:59 s/Stack defines recovery points/Outer stack for each error recovery point, inner stack for the ({[ that you have to match to get back to it/ 20:56:24 szilles: Right, I think everything should use the top or bottom behavior. 20:58:30 hasni-2pac has joined #css 20:58:48 fantasai: [explains the ascii examples more thoroughly] 20:59:06 RESOLVED: Accept fantasai's edits for the breaking/painting rules. 20:59:21 fantasai: Next is how to deal with the page-break-before/break-before aliasing. 20:59:40 fantasai: Florian's idea was to treat the page-break-before property as a shorthand for the break-before property. 21:00:19 fantasai: All the values map to themselves, except page-break-before:always maps to break-before:page. 21:01:20 jdaggett_ has joined #css 21:01:23 TabAtkins__ has joined #css 21:02:12 glazou_ has joined #css 21:02:18 vhardy_ has joined #css 21:02:28 tantek_ has joined #css 21:02:41 florian: The only issue is that the 'item()' function on CSSSTyleDeclaration, it expands shorthands and only has the longhands. So, you lose the 'page-break-*' versions here. But doing it any other way turns out to be a lot of work for very little gain. 21:02:51 vhardy__ has joined #css 21:03:10 florian: So I consider the suggestion the best possible rule. 21:03:56 dbaron has joined #css 21:04:38 TabAtkins_ has joined #css 21:04:43 glazou_ has joined #css 21:05:11 fantasai: [explains why page-break-before:avoid should map to break-before:avoid, rather than break-before:avoid-page] 21:05:39 vhardy__: Okay. It just seems like we're losing the kind of break. 21:05:53 jdaggett_ has joined #css 21:05:54 fantasai: Sure, but this is just a legacy thing. You can get all the breaks you want by using the correct property name. 21:06:17 lstorset has joined #css 21:06:23 http://lists.w3.org/Archives/Public/www-style/2012Aug/0351.html 21:06:43 vhardy_ has joined #css 21:06:48 Murakami-san explains why avoid should map avoid and not avoid-page 21:07:24 vhardy__ has joined #css 21:07:27 florian has joined #css 21:07:46 RESOLVED: Accept the spec's mapping of page-break-* to break-* as a shorthand. 21:08:42 fantasai: Alan brought up the issue that if I request a column break, but I'm not in a column context, but I *am* paginated, should I get a page break instead? 21:08:47 fantasai: That makes sense to me. 21:09:25 fantasai: The test says that when a forced break occurs, it finds the nearest fragmenter of the correct type, breaking through any intervening fragmenters. 21:09:38 fantasai: Going all the way to the root if necessary. 21:10:24 fantasai: The alternative would be to define column breaks to also act like page breaks otherwise. 21:10:34 fantasai: The difference is how the two interact with regions, and future fragmenters. 21:11:31 dbaron: So if there's no matching fragmenter context, it just breaks everything? 21:12:35 dbaron: My intuition would be that nothing breaks if there's no matching fragmentation context. 21:13:08 dbaron: The other option is that we have a ranked ordering of break types. 21:13:17 fantasai: Or setting an explicit equivalency. 21:13:47 szilles: I think the "find the nearest fragmenter" was a positive change. 21:15:11 TabAtkins_: fantasai, can you justify why you want a column break, if you request a page break and are not paginated? 21:15:34 fantasai: Because you want the broken thing to be at the top of *something*. If you can't be at the top of a page, being at the top of a column is the next-best thing. 21:16:09 plinss: Looking at OpenOffice (and maybe Word), column breaks dont' turn into page breaks in a single-col situation. 21:16:43 fantasai: I think the way to get the text you guys want is... 21:16:55 fantasai: If a column break is requested, it'll be satisfied by a page break, but not the other way around. 21:19:30 [some confusing discussion, conclusion was still the "find nearest matching fragmenter, if there isn't one then no-op"] 21:19:51 Rossen: Somewhat farfetched, but if you had nesting of different frag types, like columns inside of regions. 21:20:21 Rossen: And you have content that wants to break at some point inside the region... You can do this kind of handshake between stacks. 21:20:55 Rossen: And if there's nothing, it doesn't break. 21:21:02 fantasai: Okay, sounds like a clear resolution. 21:21:24 RESOLVED: Breaks seek the nearest matching fragmenter, and break everything between. If there is no match, no break occurs. 21:21:59 fantasai: Next, there are two interpretations of "always": break the nearest fragmenter, or break everything. 21:22:44 sylvaing: "all" for all of them? 21:22:53 Bert: Not sure if we need the "break everything" one. 21:23:03 s/"all"/"all-the-things"/ 21:24:07 dbaron: I like "any" and "all". 21:24:14 TabAtkins_: What does "always" do, then? 21:24:25 dbaron: I thought "always" was only for page-break-*. 21:24:38 dbaron: Do we need break-*:always? 21:25:01 fantasai: multicol has "always" in it. 21:26:49 TabAtkins_: So let's get some testing to see what impls actually do for "break-before: always", and if we can drop it. 21:27:30 RESOLVED: Add "any" and "all" to break-*, research what to do for "always". 21:29:19 plinss: any objections to publishing a new WD with these edits? 21:29:31 break: glass ! in case of emergency; 21:29:33 ACTION fantasai: define root fragmenting element 21:29:33 Created ACTION-494 - Define root fragmenting element [on Elika Etemad - due 2012-08-20]. 21:29:43 RESOLVED: Publish a new WD of Break, after the edits resolved on during this session. 21:31:51 fantasai: Whoops, remaining issue is about broken floats - should they stay next to each other or not if the second page is narrower than the first? 21:32:55 fantasai: Option A is to try and shrink the floats to keep them side-by-side. If they can't be shrunk enough, they just overflow. 21:33:22 fantasai: Option B is to use the normal float collision algorithm on the fragments, so that one may move below the other. 21:34:08 szilles: I prefer B for the simpler behavior - it's the same as normal float behavior. 21:34:17 dbaron: I don't understand hwo you get the option A behavior. 21:34:38 dbaron: auto-width floats depend on the width of their containing block and their contents, not surronding floats. 21:34:45 dbaron: So what makes floats get narrower in this case? 21:35:06 fantasai: This very overconstrained situation. 21:35:15 Rossen: But that changes the behavior of floats. 21:36:14 fantasai: So people seem to prefer B? 21:37:00 Rossen: [outlines why it makes sense to do option B for varying-width containers] 21:37:43 florian: I think you're saying that percentage-width floats change their size in the next page? 21:38:06 szilles: Yes, that's already in the spec. 21:38:36 dbaron: One thing the float placement rules say is that, if you wanna place a new float, you must ensure that its top is below the top of any other floats. 21:38:47 dbaron: So here you get into interesting issues where you have a bunch of existing floats... 21:39:08 dbaron: So if you're in the situation in the option B diagram... 21:40:42 dbaron: If a narrow float is anchored in the little bit of text above the right float piece, does it sit there? Can it push the right float down? 21:41:13 TabAtkins_: I think all the float pieces should be considered as originating at the start of the page, so any flaots anchored in the page normally are "after" them, and thus are subject to normal float placement rules. 21:41:24 dbaron: I think I agree. I'm curious if I implemented that. 21:42:13 dbaron: So I think we need to amend the float placement rules, either here or in the float spec, to make sure this is specified. 21:42:31 Rossen: I think this might already be included. We can refer to them and extend if there's something missing here. 21:42:50 Tab: In this case, on the second page here 21:43:01 Tab: You have a page-break-before the word float on the second line 21:43:10 Tab: And the next page is extra-wide, what happens there? 21:43:34 dbaron: More interesting question, what about a new float? 21:43:49 .... unplaced continuations 21:45:09 fantasai: And if you had a break in the left float, wouldnt' that make the left float go all the way to the bottom? 21:45:22 fantasai: Would this depend on the gap/no-gap behavrio difference? 21:45:26 We need to decide if the pushing down the unplaced float happens only for unplaced floats that can go on the current page, or for breaks that have been forced to the next page. 21:45:40 fantasai: I think we need it to continue to the bottom of the page by default, because of floats used for columns. 21:46:17 side discusion of whether forced breaks in floats should affet surrounding contents: no they should not 21:46:22 s/affet/affect/ 21:47:55 plinss: If I have an auto-width float, and it breaks across pages, will it have the same width across pages? 21:48:15 fantasai: depends on whether it landed on min-content/max-content or on fill-available in the shrink-to-fit expression 21:48:41 fantasai: if it lands on fill-available, it will vary 21:48:59 fantasai: But if it landed on min/max-content, then it sticks with that for all the fragments, and is constant. 21:49:40 dbaron: min-content and max-content should always measure across all the fragments 21:49:48 [that's not exactly true; depends on whether it recalculates to fill-available at some point. But min/max-content are not recalculated per fragment] 21:50:40 RESOLVED: Use Option B (float fragments are placed as if they're new independent floats). 21:51:01 dbaron: I think we need someone to propose an adjustment for the float placement rules. 21:51:50 dbaron: So that when you move from a wider to a narrower, you may not be able to place all of the fragments on the same line. 21:52:16 dbaron: You consider the top of the float fragment, not the float itself, when placing on the new page. But maybe you don't consider the top of the fragment when you place on a third page? 21:53:27 szilles: If there are floats continued from previous fragmentainers, process the floats in the order they were originally declared, then the content. 21:54:23 florian: Problem is if there's a small float in the content, does it get pushed to the next page as well if one of the fragments breaks again? 21:54:32 florian: I think we agreed to push it. 21:55:17 (fragmentainer?) 21:57:19 The principle that I was trying to propose was that layout of a fragmentainer is done using the normal layout rules (including the rules for float collision avoidance) on the content coming into that fragmentainer. 21:57:44 ACTION fantasai write a proposal for how to modify the float placement rules for the presence of fragmentation -- in particular, saying that the continued fragments of floats continued from the previous (or earlier) fragment are placed in the current fragment in the original order, and figuring out whether it's allowed to place the top of a float (a) when there's a continued float that could be placed in the current fragment but hasn't been placed yet [consens 21:57:44 Created ACTION-495 - Write a proposal for how to modify the float placement rules for the presence of fragmentation -- in particular, saying that the continued fragments of floats continued from the previous (or earlier) fragment are placed in the current fragment in the original order, and figuring out whether it's allowed to place the top of a float (a) when there's a continued float that could be placed in the current fragment but hasn't been placed yet [c 21:57:44 us leaning towards yes] and (b) when there's a continued float that needs to be placed in the next fragment (e.g., because of a forced break) [no consensus yet] 21:58:32 The content coming into the fragmentainer consists of the normal flow, the fragment of any floats that were fragmented in the order in which they were originally called out. 22:00:31 Then, the float fragments are placed first, using the normal float rules and then the normal content is placed and any floats called out in this normal content will be place after thatfloats carriend into this framentainer. 22:02:38
22:15:14 dholbert has joined #css 22:22:56 Topic: Pseudo-elements 22:23:00 http://adobe.github.com/css-pseudo-elements/docs/css4-pseudoelements.html 22:23:00 ScribeNick: fantasai 22:23:22 ScribeNick: Bert 22:23:22 molly has joined #css 22:23:40 Topic: pseudo-elements 22:24:29 vhardy_ has joined #css 22:24:38 topic::pseudo-elements is think is more correct. 22:24:52 Alan: [explains the idea: multiple pseudo-elements on same selector] 22:25:09 ... Not just for regions. 22:25:25 ... Generated content also. Presentational effects. 22:25:34 leaverou has joined #css 22:25:47 ... Multiple ::before's avoids having to add elements. 22:26:08 fantasai: Good to see somebody workin gon defining pseudo-elements, but 22:26:20 ... cascade doesn't work well like this. 22:26:56 ... Imagine somebody trying to override he style of a :before, but it is actually the 15th :before... 22:27:12 Alan: It has a :nth-pseudo shortcut. 22:27:27 ... That selects all pseudos at one. 22:27:33 ... But we can put in an issue. 22:28:22 glazou: Oridinals, if interleaved :after and :before. 22:28:52 dbaron: If content is not none on the 5th :before,the 5th before gets generated. 22:29:23 Alan: If there is nothing in the 1st four, than the 5th is actually the first. 22:29:42 peterl: it doesn't create, only select. 22:29:56 fantasai: What aother use cases? 22:30:20 alan: Example is if you have pseudo for a quote that matches [???] 22:30:39 ... If you have two :afters, you can have two styles for those two parts, 22:30:58 dbaron: That doens't sound a case that generated content is for. 22:31:11 [See Mark Twain example in spec] 22:31:41 dbaron: That is bad practice. Imagine you take the style sheet away... 22:31:51 dbaron: That's bad practice because if you take the style sheet away, the content disappears. I don't think we should encourage that, and I absolutely don't think we should have that example in the spec 22:31:59 glazou: But it is existing practice. 22:32:17 plinss: Difference between encouraging and allowing it. 22:32:28 dbaron: Don't think it should be allowed to drive the design of features. 22:32:44 TabAtkins_: Multiple cases where you run out of pseudo elements. 22:33:07 alan: Valid use case. Differentstyles for different added blocks. 22:33:35 plinss: It can come from attributes ort just four diffretn strings. 22:34:01 dbaron: This is way beyond what people shpould uss generated content for. 22:34:09 fantasai: Might also want to turn some of those into links. 22:34:12 Generated content's a serious issue for a11y as well - we're trying to discourage the issue dbaron describes - it's difficult. 22:34:22 q+ to suggest templates instead 22:34:55 TabAtkins_: You run out of elements to attach style to. 22:35:07 fantasai: image borders can do that example. 22:35:18 ... shouldn't need to know which pseudo style. 22:35:34 Tab: want to do speech bubble and quotation marks 22:35:41 TabAtkins_: There are well established patterns for useing pseduos for sttyleing. 22:35:47 dbaron: well, ignoring that the whole business of doing quotation marks with pseudo elements is a disaster... 22:36:14 fantasai: Everytime [scribe forot the rest] 22:36:38 tantek: We had :outside:inside at some point. 22:36:39 drublic has joined #css 22:36:49 fantasai: [missed] 22:36:53 ::outside and ::inside - but yeah 22:37:13 alan: multiple style sheets with their own pseidos that *don't* cascade is another use case. 22:37:35 ted: So yu have to know how many pseudos an element has? 22:37:50 florian: If you want two icons, e.g. 22:38:04 e.g. external link, or PDF link 22:38:06 or both 22:38:38 ted: nubering the pseufos is not so good for avoiding clashes between styles sheets. 22:39:10 tantek: There are use cases, but indexing mexhanism will lead to compatition (war) betwene designs. 22:39:44 Bert: Hixie came up with multiple pseudos a long time ago -- doesn't cascade. 22:40:10 Bert: That's the most important reason for template idea -- template doesn't have numbers, they have names. 22:40:16 ?: how are they ordered 22:40:28 Bert: visual layout 22:40:54 glazou: Writing ::before(n) is very easy for authors to write and modify 22:41:00 glazou: all solutions, incluing templates, is more difficult for authors than multiple :befores. 22:41:34 tab: Template cannot create something that allows line breaks between the pseudos. 22:41:55 Template forces us into, at best, something like inline-block. 22:42:07 http://css-tricks.com/use-cases-for-multiple-pseudo-elements/ 22:42:22 Having a link with an external and type badges afterwards, we'd be unable to have the link break across lines like a normal inline element. 22:42:36 glazou: This is sombody who is in favor 22:42:48 fantasai: It only works in simple cases. 22:42:51 fantasai: It works fine in simple cases where you don't have interactions among multiple sources of styles 22:43:19 glazou: How do you select a created box, or a collection of boxes. We can't currently. 22:44:06 s/can't/can/ 22:45:11 ... It is in the proposal: :nth-pseudo 22:45:23 ted: How about pseudos in other modules? 22:45:37 ... E.g., overflow regions, as psoposed by dbaron. 22:46:06 ... Don;t know how many regions, cannot selects the last-but-one. 22:46:33 Alan: You can selects from the end, :nth-last 22:46:59 TabAtkins_: Fine if there is a fixed number,not if the style can generate more. 22:47:41 alan: could even apply nth-pseudo to regions, to select the nth region, using 'region' as the type. 22:48:17 florian: allows nth line? 22:48:30 glazou: Probably left over from older verison of spec. Not supposed to work. 22:48:57 florian: different priperties apply to different [pseudos. Do also to nth-pseudo? 22:49:02 glazou: Absolutely, 22:49:37 florian: Sounds like nth-after and nth-before might be better, you'll know which properties apply. 22:50:11 glazou: we thought about extending later. We saw a few rtequests from users. 22:50:35 ... typically mutliple decorations, borders around an element. 22:50:50 ... Need multiple paddings betweme the multiple borders, e.g. 22:51:09 Bert: I think you should distinguish between what people are trying to do, and what they are requesting. 22:51:25 Bert: E.g. people want multiple borders, but they request multiple pseudos. 22:51:41 Rossen: Can you point us to actual examples of this? 22:52:50 alan: users asking for multiple generated content. Not sure if pseduos is always th ebest way for it. 22:53:04 alan: to draw pictures 22:53:16 TabAtkins_: Many things that are cool to have, later. 22:53:46 Rossen: As soon as you extend structure into this, it's trying to reinvent HTML in CSS 22:53:47 rossen: adding complxeity into th esolution, adding structure, sounds like implementing HTML inside CSS. 22:54:00 ... Why not use HTML? 22:54:22 fantasai: XBL was also suppsoed to solve this. 22:54:33 TabAtkins_: But nobody implemented that. 22:55:04 glazou: We have a way to present all attributes with the same style, but not with different styles. 22:55:13 fantasai: So that is a use case. 22:55:39 I think including :before and :after in CSS was a mistake. 22:55:45 ... But can also make it appear as an element, able to be styled. 22:56:05 ... We're also trying to olve the multiple border case, multiple icons case, etc. 22:56:20 ... We should try to solve these in a better way. 22:56:35 ... This proposal is awkward for all of them. 22:56:46 alan: I think it is the easiest possible solution., 22:56:59 glazou: Selecting columns, is other exmaple. 22:57:08 florian: There is a pseufo in GCPM for that. 22:57:28 ted: [missed] 22:57:43 vincent: Can already have collission with current single :before pseduo. 22:58:40 steve: The comments on columns are relevant: consider replacing style on a group or on individual parts of he group. 22:58:56 ted: Descendant of the :before? 22:59:12 steve: :before is then a shorthand for the whole collection. 22:59:14 Steve: ::before becomes a shorthand for the collection of all the ::before(n) 22:59:31 alan: Other issue in spec is object model for pseudos. 23:01:28 s/issue/section/ 23:01:39 sylvaing: drop zones, all things that a node can be, we're rewriting the DOM... pseuodes are likenode in all cases, except you cannot instantiate them. 23:01:54 ...from a static markup 23:02:18 glazou: You can access them, even if not instatiate. 23:02:37 sylvaing: No, yu cannot currently. How attach event handlers. 23:02:37 we should stop this pseudo madness ::before it gets out of hand. 23:03:16 glazou: The day we have stuff on the right hand side, don't you think people will want :hover there, too? 23:03:34 sylvaing: Not sure what problem we're solving anymore. 23:03:53 TabAtkins_: Problem is just with OM? 23:04:10 sylvaing: All the things we're adding make pseudos act like elements. 23:04:30 glazou: Yes, all specs do the same. 23:04:43 sylvaing: So we're creating elements, except there is no DOM for them. 23:05:01 dbaron: We're creating new structure, rather than slots into which to pour structure. 23:05:27 dbaron: Most other pseudos are about styling ranges of what already exists. 23:05:30 ... The other pseduos other than :before/after are about things that already exist (first-line, first -letter, column). 23:05:37 ... Before after make new content. 23:05:53 ... I think before/after were a mistake. 23:06:30 florian: Without the DOM, this solution feels incomplete. 23:07:02 TabAtkins_: People should not expect that a pseduo can be a drop zone. 23:07:23 glazou: We've been asked for this for 14 years. 23:07:33 ... Our customers ask for this. 23:07:52 ... They know what they need. 23:08:25 plinss: Wether to have pseudo-elements is no longer a question. 23:08:45 dbaron: But theis is a different question. What about accessibility, e.g, 23:09:21 plinss: We had pseudos for scrollbar parts, that's why we added double colon, to make it extensible. 23:09:35 ... We're already adding extra structure. 23:10:01 dbaron: Separating content and prsentation. Mostof the examples here are mixing them back up. 23:10:26 plinss: That is not black and white. Sometims tetx is presentational, somtimes images are content. 23:10:55 dbaron: There are guidelines from i18n, a11y, etc. 23:11:08 ... Text presented to user should not be in attribute, e.g. 23:11:30 glazou: Wikipedia has content in attrib. 23:11:42 ... They said it was too complex too fix. 23:12:18 dbaron: They used that solution because the tool was available. Now it is is too difficult to fix. It wans't when that started doing it. 23:12:32 glazou: EPUB is full of attributes with text. 23:12:50 ... YOu *have* to render those attributes. 23:13:11 fantasai: A simple transformation language will be a simpler way to solve this. 23:13:41 alan: The lst use case in the draft is not about generated content. 23:13:53 ... It creates regions by means of pseudos. 23:14:09 vincent: I'm sensitive to accessibility argument. 23:14:34 ... THis case doesn't have tetx in attributes. 23:14:50 dbaron: I think the example can, and ought, to be done in other ways. 23:15:07 ... Styleing exisitng content and making content is different. 23:15:20 ... Here ypu are stylong, but using a tool that is creating content. 23:15:21 glazou: a transformation language will NOT be dynamic ; if you want a batch one, I have built STTS 15 years ago and browsers did not adopt it 23:15:44 alan: This is about redirecting content that already exist, 23:16:28 ... Last region as aut height, so displays all content. But could use overflow regions as well. Or a diff. way to use ficed number of regions. 23:16:34 jet has joined #CSS 23:16:50 plinss: I have no objection to creating arbitrary regions. ot sure I like this proposal, though. 23:16:55 ... Seems hacky. 23:17:08 Alan: It is meant to avoid having empty elts in the mark-up. 23:17:25 plinss: Yes, agreed, but :before/after seems a hack for this. 23:17:47 TabAtkins_: Looks hacky, but can be written differently. 23:18:13 plinss: I think we like what it is trying to do, not how it does it. 23:18:37 vincent. OK, but how do we go from there? 23:19:19 plinss: I tried to write it up, never finished. I think I should go back to that and try to write it up. 23:19:35 glazou: Antohether type of pseudo? 23:20:07 ... We need multiple :before/after, But I udnerstand you don't want to use that for all use cases. 23:20:08 s/Antohether/Another 23:20:39 ... We decided to restrict ourselves to :before/after for immediate needs. 23:20:51 ... Web authors are expressing need for more. 23:21:01 plinss: I want to try and get something better, 23:21:35 glazou: Adobe's proptotype is real fun to play with. Can do things couldn;t do before. 23:21:52 ... It makes sense to sperate sleetcors and pseudos and extends pseudos. 23:22:03 plinss: OK to make a WD. 23:22:24 ... Not currently ready for FPWD though. 23:22:44 vincent: peter, want to be co-editor? 23:22:46 s/OK to make a WD/OK to make an ED/ 23:23:00 plinss: Want to be involved, will see about co-editor. 23:23:21 fantasai: Not OK with FPD, but defer to others for editor's draft, 23:23:41 florian: Even without multiple :befreo/afetr, the rest is still useful. 23:24:08 ... I want to work on it. 23:24:29 [discussion about people implementing too soon] 23:24:51 plinss: Fine as an editor's draft. 23:25:07 fantasai: We should point out to people that we have no consensus. 23:25:21 glazou: An editor's draft is a proposal. 23:25:33 tantek: List issues explicitly in the document. 23:25:37 glazou: Sure. 23:26:14 [discussing issues that say "we don't really want this"] 23:26:30 dbaron: Should mention a11y and i18n issues. 23:26:44 .. And ask whether this is more power than we want in CSS. 23:26:52 fantasai: and the cascade issues should be mentioned. 23:27:07 fantasai: And is should mention the trouble with cascading. 23:27:28 RESOLVED: make editor's draft with these isseus listed. 23:27:41 s/is should/it should/ 23:27:55 Topic: region overflow 23:28:57 http://lists.w3.org/Archives/Public/www-style/2012May/1197.html 23:29:03 http://lists.w3.org/Archives/Public/www-archive/2012Aug/att-0005/Overview.html 23:29:04 http://lists.w3.org/Archives/Public/www-archive/2012Aug/att-0005/Overview.html 23:29:48 dbaron: When an elt has overflow, 23:30:03 ... if it were paginated, it would break here, 23:30:17 ... we say we make another box as a sibliong of the first box. 23:30:36 ... That one may also be broken, until we have all content. 23:30:45 ... With auto height, it doens't do anything. 23:31:02 ... But if you set fixed height, you'l get multiple boxes. 23:31:14 ... Interesting question is to style the different boxes. 23:31:31 florian: Multicol has behavior to add columns to the side. 23:31:46 ... At least you can see them, not always the best way to style it. 23:32:02 ... Might instead want to add nother multicol box below it. 23:32:27 dbaron: [lookin at example 1] 23:32:46 ... In example 2, you can style the regions separately. 23:33:26 ... Let's look at the examples. Inherit style from regions into the content. 23:33:43 ... E.g.. a larger font for the first region. 23:34:37 ... Example 4 has different :visited styles in the diff. regions. 23:34:48 glazou: THis is uch better than @rules. 23:35:10 steve: Which @rules? 23:35:16 glazou: Like regions. 23:35:39 dbaron: Which props ypu can use in the regions is a bit complicated. 23:35:56 ... Example 5 is maybe more realistic use case. 23:36:04 ... I added a property 'max-lines' 23:36:17 ... You want pagination after a certain # of lines. 23:36:36 jdaggett: What if it has height:auto? 23:36:58 dbaron: Depends on whether height constrains more than max-lines. 23:37:28 glazou: You can make the same argument about cascading here as with multilple psuedos. 23:37:42 dbaron: But you can kill this with a sinlge 'overflow' property. 23:37:52 fantasai: Thge ability to reset the whole thing is important. 23:38:09 glazou: Both proposals have that. 23:38:30 dbaron: I'd like to use the same name in the overflow and in the name of the pseudo. 23:38:31 jdaggett: s/height:auto/height is set?/ 23:38:38 ... That's why i don't like "repeat". 23:38:51 ... I came up with "piece" and "part" 23:38:58 fantasai: How about "copy"? 23:39:05 glazou: They are not copies. 23:39:35 steve: The words don't ahave the same function in the two places. 23:39:59 fantasai: Fragment can be both a noun and a verb :-) 23:40:16 dbaron: Fine to use noun in both places 23:40:21 SteveZ: "Fragment" can, yes. 23:40:48 alan: We can put an issue that we don't know the name yet. 23:41:23 vincent: I think we change the name before we publicize it more, though. 23:41:52 dbaron: prefer part over fragment, but OK with fragment. 23:42:13 glazou: content property applies only if region exist? 23:42:24 dbaron: Probabl 'content' doesn't apply. 23:42:59 TabAtkins_: About stuff to the right of the pseudo-elt. 23:43:08 ... Make the '::' a combinator? 23:43:33 ... There are few current pseudos that you'd need to special case. 23:43:45 ... But they already have spacial case in that they allow a single ':' 23:44:38 fantasai: a ::before vs a::before 23:44:58 ... if '::' becomes a combinator, then they would be the same. 23:45:23 plinss: Or treat the whole pseudo-elt as a kind of combinator. 23:45:55 glazou: Yes, allowing the space needs a lot of chnages to the specs. 23:46:00 steve: rathole? 23:46:20 vincent: 'max-line' is like 'max-width'? 23:46:31 ... limiting the siz eand the overflow are different things. 23:46:54 florian: Yes, it is in this spec just becaue t needs a host. 23:47:17 dbaron: It is not processed the same way as hieht, it is processed when you detetmrine breaks. 23:47:48 steve: yes, cannot set a height of that kind today, but we could have a height value that could do that thing. 23:48:07 ted: 'min-lines'? 23:48:26 dbaron: Why would you want that? 23:49:16 steve: problem with givinbg height a value in lines maybe that it depends on layout? 23:49:34 dbaron: A little scaed, but it might work... 23:49:50 plinss: And 'max-width: 3lines'? 23:50:05 TabAtkins_: Would be meaningless in horizontal writing modes. 23:50:41 plinss: having a unit I like, but scary. 23:51:09 fantasai: Pseudo element is notmally a piece of an element, and properties on it win over the propertie son the elt itself. 23:51:53 ... 'foo#f1' is more specific than 'foo:nth-region' and so shouldn't it win? 23:52:11 steve: Did we have a similar issue with [??] 23:52:34 dbaron: I want some specificity for these, same as pseduo-class, maybe. 23:52:44 s/??/region styling 23:53:20 florian: Other issue is related to multicol, does this apply to columns? 23:53:34 dbaron: I think nth-region applies to columns. 23:53:47 ... It would apply anywhere where you do breaking. 23:54:22 ... No, actually, it would not be put on the multicol element itself 23:54:45 plinss: Doesn't matter why something breaks. 23:55:05 rossen: Any restriction son what it applies to? CAn break anything? 23:55:15 dbaron: table parts may be problemtatic. 23:55:41 rossen: Create extra table cells... create extra rows... awkward. 23:55:54 fantasai: "you get what you asked for"? :-) 23:56:10 Rossen: At least somethign to consider. 23:56:27 dbaron: People suggested this should become an overflow module. 23:56:42 ... overflow-x/y in this context also need to be specified. 23:57:08 florian: Yes, thet interact poorly currently, 23:57:27 fantasai: good reason to address them all together in the same place 23:57:37 alan: does 'break-before' apply? 23:58:07 steve: 'break: always (or 'all') would do it. 23:58:38 florian: Does 'break-*: region' apply? 23:59:00 ... I think I'm OK with using the same keyword. 23:59:16 steve: Example is multiple coliumns, which contain regions. 00:00:21 glazou: we have several proposals for nth-*. So I think nth-pseudo(type) is better. 00:00:41 dbaron: Do't think the word "pseudo" should be in the name. 00:01:00 glazou: We can glue all proposals together. 00:01:30 I agree with dbaron I don't think "pseudo" should be in the name either 00:01:35 fantasai: But what does it gain us? The name of the thing you take the nth off has to be there anyway. 00:02:12 dbaron: I'm remnded of first gradient proposal, with different arguments diepending on type argument. 00:02:56 [discussion confused about whether it is about the word "pseudo" or about the concept of "nth" with a param] 00:03:39 steve: it's the same thing every time: the nth of a type. 00:03:50 florian: Not exactly the same meaingin on all cases. 00:04:14 fantasai: but you can put the type after a dash, why put it in parenthees? 00:04:49 jet has joined #CSS 00:05:41 steve: gradients had differtnet params in different types. This is just one param. 00:06:09 Tab: YEs, but for future extensions safer to prevent psssibility of different params. 00:06:32 florian: nth-region is also shorter, that's enough of a reason. 00:07:23 plinss: *:before:nth(3) 00:07:47 ... ::before:hover 00:08:18 ... Why invent a mechanism. We already have pseudo-classes. 00:09:37 glazou: ::first-letter is ::letter:nth(1) ? 00:09:50 steve: Cannot necessarily apply it to everything. 00:10:08 plinss: :first-line would just be an alias. 00:10:41 dbaron: Boustrophedon: ::lines(2n+1) 00:10:59 s/dbaron: Boustrophedon: ::lines(2n+1)// 00:11:22 actually that should be ::line:nth(2n+1) 00:12:34 florian: You cannot apply 'overflow' to the pseudo, dbaron said, but I think it u=is useful to apply it to the last region. 00:12:42 dbaron: Can set height: auto. 00:12:50 florian: Not quite he same thing. 00:13:05 dbaron: My worry is about the first fragment. 00:13:20 ... You only use the fragment styles *if* the elt id fragmented. 00:13:43 ... If you turn off overflow on the first fragment, suddently you don't have overflow anymore... 00:14:08 TabAtkins_: Or don't start counting until the second fragment. 00:14:34 dbaron: Doubles the cost of selector matching. 00:15:01 ... So either don't matche sleectors unless you have the special overflow value, or 00:15:16 ... don't apply frgament styles until ypu reach the second. 00:15:59 plinss: 'overflow: fragment' and it doesn't create fragments, do the properties apply? 00:16:28 ... As soon as you set 'overflow: fragment' all styles apply, whether or not you have more than one fragment. 00:17:04 ... All of the boxes of an elt are considered fragments, if it fragments for any reason. 00:17:23 dbaron: That was not how is speced it. 00:17:44 ... Mine was only if you also specify 'overflow: fragment' 00:18:03 fantasai: Say you want a fragment of a given height. 00:18:17 ... [draws on white board] 00:18:56 ... and now imagine I wan borders on all fragments. 00:19:22 dbaron: I had to write extra style rules for paginated mode. 00:19:48 s/extra style rules/fancier selectors, like :nth-region(n+2)/ 00:20:17 fantasai: A fragment that is itself broken over two pages do not increase the number of fragments as seen by the pseudo-elt selector. 00:20:52 plinss: Same issue in multicol. 00:22:27 steve: If a multicol element overflows in a paged environment, where does the next column go? 00:23:06 fantasai: If you have fied height on the multicol elt, the overflow will be on the side and will just be cut off if you print the page. 00:23:12 s/fiex/fixed/ 00:23:25 steve: Now I set 'overflow: fragment' 00:23:38 florian: It should act the same. 00:24:17 ... Current wordking in multicol and in this proposal doesn't do that, but it should. 00:26:36 ... Current does work if 00:26:57 vhardy__ has joined #css 00:26:58 ... elt has 'columns' and 'overflow fragment' 00:27:40 ... I think the 'overflow-style: paged-*' should be pulled into this spec, too. 00:28:26 ... you can style the pages, but more limited; cannot position them, e.g. 00:28:52 dbaron: Some thing you might want to apply to paginated overflow do not make sense here. 00:29:07 ... E.g., scroll two pages at once. 00:29:33 plinss: When you print, does it degrade well? 00:29:46 fantasai: Stack of pages? 00:30:11 dbaron: 'overflow:scroll' not defined for print either. 00:30:23 plinss: Dynamic presentation vs static presentation. 00:30:37 ... Define how it degrades. Common model. 00:31:14 fantasai: One example of overflow 'paged' when printed [draws picture], 00:31:32 ... inside page and outside page. 00:31:54 SteveZ: Better done with media queries? 00:32:06 dbaron: *If* the author provides media queries, yes. 00:32:30 dbaron (before SteveZ): but what if the inside page is bigger than the outside page? and how to tell which content gets repeated around the inside pages and which goes on outside pages before/after them? 00:32:37 plinss: If you haven't anticipated a certain environment, it shoudl still behave reasonably. 00:33:07 ... browsers should do something rational even if autghor didn't provide media query. 00:33:23 steve: This is auto-generation for a single stream. 00:33:34 ... Doens't handle merging two streams. 00:33:41 ... Page templates are about that. 00:33:52 ... They do this, but do other things as well. 00:34:22 ... They allow to select the next contained based on what content to position. 00:34:34 ... So this doesn't replace page templates. 00:34:47 florian: I think alan convinced me of that. 00:35:25 alan: region chain, with different sizes: probably need to replicate quite a bit of the behavior of that from the regions spec to here. 00:35:35 dbaron: I thought fragmentation spec would do that. 00:35:38 fantasai: doesn 00:35:52 ..' t cover everythinh. 00:36:24 fantasai: Fragmentation covers how you break the flow across fragmentainers. Doesn't say how you size them. 00:36:41 alan: e.g., two regions in the same row, and one region has a forced break. 00:37:34 vincent: first pass to figure out what goes into the bxoes. Maybe smaller font size in one region means more content goes into that. Need to work out recursive dependencies. 00:37:48 ... Either dependencies or allow gaps. 00:38:34 ... No need to resolve all that now. Just keep it in mind. 00:39:45 Rossen: Dbaron, are certain properties going to be restricted to regions? Passing styles down from region to content is tricky. Restricting the set of properties makes it easier. 00:40:18 dbaron: The set of properties is restricted. More restricted in what applies to content than what applies to the region itself. 00:41:08 florian: Say we have a flexbox for first few elements and than the overflow is displayed differently. 00:41:23 s/elements/fragments/ 00:41:48 fantasai^: Maybe want to change display-outside, but don't think so for display-inside 00:42:27 vincent: difficult to implement when size depends on content, e.g., when diff. font size in diff. regions. Need 2nd pass. 00:42:56 ... I don't remember all the cases, but there were interferences. 00:43:11 ... It seems the same applies to 'overflow: fragment' 00:43:51 florian: Can we discuss 'overflow-x/y' and why it is a problem in combination with this? 00:44:43 vhardy_ has joined #css 00:44:54 ... We implemented to ignore overflow-x if o- says 'paged-*' and vice-versa. 00:45:22 Bert: I tried to overflow-x/y up and never managed to, for much the same reasons. 00:45:33 dbaron: We had a discussion maybe 8 or 9 years ago. 00:45:51 ... We concluded that all combinations mixed, except 'visible' 00:46:33 rossen: I think we had it speced, and IE9 implemented taht, I think. 00:47:22 florian: overflow is a shothand, one question is what the longhand is for some of the values. 00:48:44 ... I may want to overflow pages only in vertical direction. 00:49:37 Rossen: I remember lookkng at some code for marquee with that question. 00:49:37 florian: I think we should make overflow-x/overflow-y be logical so -y is always in block direction and fragment etc. only apply in y direction 00:49:49 fantasai: Should we make background-repeat: repeat-x/y match that, then? 00:50:03 molly has joined #css 00:50:26 florian: And then add writing modes... it just doesn't make sense. 00:50:43 ... I think there is a link saying all that somwhere. 00:50:45 florian^: overflow-x/y is really messed up 00:50:58 http://lists.w3.org/Archives/Public/www-style/2012May/1197.html 00:51:44 florian: When we have reworked overflow, we don't actually need 'overflow-style' anymore. 00:52:25 tantek: We worked it all out and the result made less sense with logical directions, at least in UIs. 00:52:44 florian: Some edge cases are not elegant. 00:53:02 tantek: Edge cases are often not elegant. 00:53:50 florian: We had to do strange things with overflow-x/y outsidee the cascade. 00:54:02 .. So I'd like to see if we can't make something better. 00:54:11 s/.. /... / 00:55:00 tantek: The simpel answer is if you set 'paged' on one, then the other is lso paged. 00:55:09 florian: If you put overflow-x: paged; overflow-y: fragment; what happens? 00:55:36 Rossen: We did what most other did. Visible trumped all. 00:55:43 no, that's wrong 00:55:43 dbaron: We do 'hidden' 00:55:57 Rossen: Have to figure out which one wins. 00:55:58 Rosen: if either was not-visible, visible became set to 'auto' 00:56:31 ... With fragmentation added, specs needs to call it out. 00:56:32 dbaron: we turn some values into hidden, and others into auto 00:56:36 Zakim has left #css 00:56:45 dbaron: We turn some into hidden and some into auto. 00:57:09 rossen: We did some analysis and most implementations were similar. 00:57:44 ... It makes sense to have 'visible' in one direction and hidden in the other and that shouldn't turn into auto. 00:57:57 really we're just turning visible into auto 00:58:06 we're turning the pre-2004 overflow:hidden into hidden 00:58:09 dbaron: Essentially wer are turning 'visible' into 'auto'. 00:58:56 florian: The (prefixed) marquee in webkit doesn't use overflow-style, but overflow. 00:59:56 ... if that is the only implementation, as it seems to be, maybe we can forget what the marquee spec said and redefine overflow. 01:00:43 fantasai: Maybe the value in the block direction should always win? 01:01:06 dbaron: That's reasonable, but we do something different for 'visible' currently. 01:01:44 florian: It is not exactly that. Example: [draws] 01:02:42 Vincent asks about what we do with dbaron's draft 01:02:42 vincent: did we agree to publish dbaron's draft? 01:03:02 dbaron: Yes,as editor's draft. I want to name it css3-overflow. 01:03:12 florian: [drawing] 01:03:56 ... last line on page has an image sticking out below. In paged mode, that overflow is just hidden. 01:04:18 fantasai: We add pages for abs pos elements. 01:04:29 fantasai: you have to; some websites abspos the entire thing 01:04:33 s/thing/page 01:04:36 Rossen: The exception in our implementation is with mixed directions. 01:05:00 ... Fragment in orthogonal diretcion, to not lose any content. 01:05:18 fantasai, does the fragmentation spec say how to place absolutely positioned elements (esp. those that use static-position or those that are relative-to-bottom)? 01:06:20 fantasai: [draws page with long text sticking out on the left] 01:06:38
01:06:40 ... We automatically trigger multicol to display that overflowng text. 01:08:32 [end of meeting] 01:47:27 vhardy_ has joined #css 02:03:53 cabanier has joined #css 02:10:07 Liam has joined #css 02:12:59 cabanier1 has joined #css 02:37:58 arronei_ has joined #css 02:45:11 isherman has joined #css 03:20:33 tantek has joined #css 03:58:21 krit has joined #css 04:14:03 shepazu has joined #css 05:25:22 tantek has joined #css 05:27:47 tantek has joined #css 05:55:14 glazou has joined #css 06:07:30 Koji has joined #css 06:12:16 florian has joined #css 06:23:00 drublic has joined #css 06:42:05 tantek has joined #css 06:46:55 arronei_ has joined #css 06:52:01 cabanier has joined #css 07:08:24 Ms2ger has joined #css 08:41:05 drublic has joined #css 08:43:28 SimonSapin has joined #css 08:59:52 drublic_ has joined #css 09:02:28 drublic has joined #css 09:49:27 drublic has joined #css 11:24:26 decadance has joined #css 11:31:31 jet has joined #CSS 12:02:48 jet has joined #CSS 12:27:10 jet has joined #CSS 12:46:37 myakura has joined #css 12:52:45 jet has joined #CSS 12:54:34 drublic_ has joined #css 12:54:50 leaverou has joined #css 13:03:21 drublic has joined #css 13:20:53 leaverou has joined #css 13:42:52 jet has joined #CSS 13:57:48 leaverou has joined #css 14:00:45 jet has joined #CSS 14:05:12 jet has joined #CSS 14:06:25 ksweeney has joined #css 14:06:54 ksweeney has left #css 14:08:19 shepazu has joined #css 14:26:17 leaverou has joined #css 14:55:25 jet has joined #CSS 15:23:47 arronei_ has joined #css 15:35:44 tantek has joined #css 15:44:57 glenn has joined #css 15:47:21 glazou has joined #css 15:47:57 rrsagent, this meeting spans midnight 15:48:37 Rossen has joined #css 15:50:08 dbaron has joined #css 15:50:17 florian has joined #css 15:51:30 lstorset has joined #css 15:59:55 TabAtkins_ has joined #css 16:00:22 Molly has joined #css 16:03:36 Rossen has joined #css 16:04:28 SteveZ has joined #css 16:04:47 cabanier has joined #css 16:07:18 ScribeNick: TabAtkins_ 16:07:27 Topic: Future meetings 16:07:42 dbaron: TPAc is this year, but I think that's all sorted out. 16:07:57 szilles: Money commitments are there, room hasn't been arranged yet. 16:08:05 szilles: This is August, it's France, need I say more? 16:08:31 dbaron: We've agreed on months and locations for the next two meetings, but not dates yet, and we dont' ahve a location for the third meeting. 16:09:18 Molly: Since you decided Feb for the first meeting, Tucson has some big meetings in the middle of Feb which will cause hotel problems. 16:09:28 Molly: How flexible are you about the date? 16:09:55 Molly: I'll figure out in the next week what the best dates will be, and give you a few choices. 16:10:36 sylvaing: Early March is fine, but late March is SXSW. 16:10:40 glazou: I cant' do early march. 16:10:52 szilles: Mar 16-23 is no good for me. 16:11:18 florian: end of feb or early march is the best for me. 16:11:34 Molly: I feel that the early Feb is probably the danger zone. 16:11:59 Molly: I'm going to look at the week starting Feb 4 or 6. 16:12:11 szilles: The Gem Show is the 14-17. 16:12:19 Molly: The week before is when the wholesalers are around. 16:14:01 Molly: People are possibly okay with Sundays, yes? 16:14:09 [several]: Yeah, that's fine. 16:14:09 SxSW is 3/8-3/17 so Interactive should be 3/8-3/11 16:14:17 dbaron: So, we said we'd meet in Japan in May. 16:14:28 dbaron: Since then, the AC meeting was announced as June 9-11 in Japan. 16:14:36 tantek has joined #css 16:14:46 dbaron: So, for the three or four of us going to that, it would be awfully convenient to make just one trip there. 16:15:04 dbaron: The previous week works fine for me. 16:16:23 jdaggett: The SVGWG said they wanted to colocate in Japan, so if that happens, we may need to use the Google office, because the Moz office won't take that many people. 16:17:24 Koji has joined #css 16:17:34 florian: For the third meeting, perhaps Europe. 16:17:56 florian: I can't speak for Opera at that point, but we can see. 16:18:16 TabAtkins_: I can see what G might be able to do in Europe, too. 16:18:45 dbaron: We may be able to do London or Paris, as well. Depends on when the construction is done. 16:19:31 jdaggett: I think we should wait to do dates for when Hakon is here, as he often has fall commitments. 16:20:08 [discussion about being too close to TPAC, maybe hit late August or early Sep] 16:21:07 glazou: I have a conflict in all of August. 16:23:35 Topic: CSSOM 16:24:01 glenn: Update on editting work... 16:24:14 glenn: I transitioned the format to a preprocessor which I use to generate the docs from IDL. 16:24:27 glenn: So I'm starting to work through the buglist and some of the new items appearnign on the mailing list. 16:24:47 glenn: My current goal is to process all the bugs and get the material in place that would allow us to go to a new WD by the end of this month. 16:24:56 glenn: For the items that people asked to discuss here... 16:25:23 glenn: There was a questioan bout what cssText should return for various rules, such as the contents of a @media rule. 16:25:30 glenn: Should it be pretty-printed or not? 16:25:49 florian: Right now, all impls break lines and indent things inside of @media. 16:25:54 http://hg.csswg.org/test/file/tip/contributors/gadams/incoming/cssom 16:26:05 glenn: One thing I'm doing is a link of incoming tests. 16:26:24 glenn: There are about 130 tests right nwo, and I'm actively expanding those to cover all the interfaces. 16:26:38 glenn: I'll put one in to test the media behavior you're describing. 16:27:09 florian: Though, now that we're getting nested @media, the indentation is not interop. 16:27:51 florian: Opera does proper increasing indentation, but Firefox doesn't - they're all 2-space in. 16:28:08 florian: Unfortunately, authors depend on silly details of the serialization, so interop is often important here. 16:28:28 jdaggett: I'm going on the assumption that I can collapse all whitespace, and things should serialize the same way (in @font-face). 16:28:58 jdaggett: So I'm not sure one particular type of whitespace is better than another. 16:29:19 florian: I don't care much about *what* type of formatting is used, I just care about something being in the spec so we can do it all the same. 16:30:16 glenn: Will we have exceptions for certain rules, or will this be a generic rule for all the parts of CSS? 16:30:23 florian: Not sure. It seems easy enough to be consistent, though. 16:30:47 glenn: Yesterday we were takling about preserving whtiespace and comments in @supports. 16:31:09 glenn: in the case of an inline style, should we preserve what they do in that case, and pretty-print other places? 16:31:24 miketaylr has joined #css 16:31:38 florian: I think we should only do exact preservation in @supports condition, and just reserialize otherwise. 16:31:44 jdaggett has joined #css 16:32:00 q+ 16:32:03 florian: One nuance - when you serialize a single rule, some end it with a semicolon, while others end with a semicolon-space. 16:33:00 jdaggett: If you have a font-family name that's unquote and has an escape in the second part of the name, webkit returns a quoted version. It's not identical, but it round-trips. 16:33:38 Zakim has joined #css 16:33:52 florian: It'll take time to nail down the exact details, but I think we can put together good general rules for all of these. 16:34:47 jdaggett: For testing, I want the opposite - I want to test "does this parse?" and I get that by looking at the string. 16:35:12 glazou: Testing is not a target for CSS. 16:35:47 Molly: If there are differences, it makes it hard for developers to deal with it, because they have more to learn and memorize. Better to have things be consistent. 16:37:05 florian: Opera also does the indentation on @keyframes. 16:37:50 florian: When you nest things, Opera right now does correct pretty-printing. I'd like to either agree on that or not do it at all, so we're all together. 16:38:25 florian: Our policy seems to be that at-rules that contain rules are indented, while ones that contain descriptors are not. 16:39:10 glazou: What about groups of selectors? Many authors put newlines after commas in selectors. 16:39:20 florian: No one does anything like that for now - selectors are just on one page. 16:39:32 vhardy_ has joined #css 16:39:41 http://clhs.lisp.se/Body/v_pr_rda.htm 16:40:06 vhardy__ has joined #css 16:41:02 glazou: Is it naive to ask for a pretty-printer built in natively? 16:41:08 [some discussion about it] 16:41:42 florian: We could just let libraries deal with that for now, and always add it in natively if it seems necessary later. 16:41:58 dbaron: I don't think it's really necessary at all. This is not something that's commonly used. 16:42:21 glazou: Would you be okay with me and Florian investigating how to serialize rules across CSS? 16:42:43 dbaron: I'm okay with that, with the caveat that the harder part is serializing CSS values, which is a separate topic. 16:44:16 glenn: I hope to finish the value stuff this week. 16:44:33 glazou: One thing I noticed that is missing a cssText is the Stylesheet object. We should fix that. 16:44:53 dbaron: One thing I noticed is that some things are noted as not readonly in the OM, but they're readonly in practice. 16:45:14 s/some things/some cssText attributes/ 16:45:40 dbaron: Every once in a while, someone will submit a webkit patch making one of their setters work. 16:46:17 florian: Do you know why they might have been made readonly? 16:46:46 dbaron: A combination of just not bothering to do it, or assuming that the spec meant to make things readonly. 16:48:00 glenn: Do you have any places where you think it should be readonly? 16:48:26 dbaron: For example, on @media - do authors really want to do this? 16:49:53 TabAtkins_: I think that it's about as useful as innerHTML, which is allowed everywhere. 16:50:18 dbaron: Looks like Firefox only makes it mutable in *one* instance - on CSSStyleDeclaration that doesn't come from getComputedStyle. 16:50:40 dbaron: what happens when you set mediaRule.cssText = "@keyframes foo { ... }" ??? 16:51:03 dbaron: The spec needs more than the lack of the word "readonly" for this to be implementable. 16:51:36 glenn: So I don't think I have any other open issues. If I have any questions, I'll bring them up to the group. 16:53:55 Topic: global CSS object 16:54:00 glazou: Any issues with that? 16:54:52 TabAtkins_: The last day of discussion in webapps hasn't brought up any problems, and people seem positive. Sounds good - we can deal with any changes that prove necessary if problems come up later. 16:55:10 Topic: @font-face OM definition 16:56:09 glenn: Since John is doing @font-face in Fonts, should I remove those definitions from CSSOM? 16:56:41 jdaggett: I didn't redefined @font-face, I just added @font-features 16:57:09 glenn: Okay, my mistake. So should I add some guidance about defining new at-rules in OM? 16:57:14 [several]: YES 16:58:16 glenn: What about coordinating the constants for new rule types? 16:58:47 TabAtkins_: There's a wiki page about that on the csswg wiki, under Planning. 16:58:57 glenn: Would you mind an informative note pointing to that page? 16:59:00 TabAtkins_: No, that's great. 16:59:03 Topic: Regions. 16:59:13 stearns: We've been going through feedback on Regions. 16:59:26 stearns: The feedback on the OM has been very useful. The ED has gone through a lot of revisions. 16:59:38 stearns: So I'd like to publish a new WD to reflect those updates. 16:59:50 RESOLVED: Publish a new WD of Regions. 17:00:34 florian: One thing about regions... 17:01:14 florian: We did @region because we didn't want to put things after the pseudo-element. Should we change this now, given that we're changing on that aspect? 17:01:21 jdaggett: Perhaps an issue in the spec about it. 17:01:45 stearns: We have somep atches in WebKit already about region styling. 17:01:59 stearns: If we get to the point where we're able to chain pseudo-element syntax, we're willing to change that. 17:02:22 stearns: But I'd like to have that shake out before I make changes to the spec. 17:02:33 stearns: But I'll add an issue on the @region syntax if there isn't already one. 17:03:09 Topic: Exclusions 17:03:23 Rossen: We've made a lot of editorial changes to the spec, such as updating a lot of images. 17:03:34 https://www.w3.org/Bugs/Public/show_bug.cgi?id=15183 17:03:40 Rossen: One discussion we tried to revive was "Issue 1" in the spec, which was put in by dbaron. 17:03:48 Rossen: [reads the issue] 17:05:52 Rossen: The processing model of exclusions - nowhere do we actually insist on building the positioning scheme of exclusions on top of abspos, but we don't forbid it either. 17:06:01 Rossen: So if you want to do abspos exclusions, you're allowed to. 17:06:20 Rossen: I don't see any reason to make an exception here and disallow one type of positioning. 17:06:49 Rossen: I'd like to show a demo of exclusions used in grid, with no abspos. 17:08:19 Rossen: [shows demo] 17:10:20 krit has joined #css 17:12:05 arronei_ has joined #css 17:13:48 florian, don't play your Håkon :-) http://images.canberratimes.com.au/2012/02/15/3039529/aw-Hakon-20Wium-20Lie-20_20120215121710238149-420x0.jpg 17:14:00 dbaron: I'd like to explain why this demo doesnt' work well. 17:14:17 dbaron: First, unless you explicitly handle paging, you'll have to scroll up and down for these multicol things. 17:15:46 dbaron: Now, if you produce more content, how is this exclusion paginated? 17:16:01 TabAtkins_: I'ts just put in a cell in the grid, so that depends on how grids are paginated. 17:16:24 stearns: If it's in a "page grid", it might be on every page. If it's on an element grid, it's wherever it appears in the paginated content. 17:17:07 Rossen: These questions seem to be about page templates in general, not about exclusions at all. 17:17:32 q+ 17:17:42 florian has left #css 17:17:45 florian has joined #css 17:17:49 q+ 17:19:14 Rossen: The placement of exclusions is driven by the templating system. 17:19:32 Rossen: Like a bunch of grids that are placed one after the other for content that flows through them. 17:20:28 Rossen: It could be determined by the author or the app - the author coul dhave pull quotes that want to be displayed as exclusions, or the host could insert an ad as an exlucions. 17:20:37 szilles: I don't see a connection between what's being said here. 17:20:51 szilles: David is seeing a document with a bunch of static declarations putting things in various places. 17:20:55 q+ 17:21:12 szilles: He's wondering where these should go as pages vary or disappear entirely. 17:21:35 szilles: But you seem to have a different model - an app, possibly with JS, which takes the ocntent and builds the pages on the fly to build the environment they go into. 17:21:59 szilles: So I can say "this figure goes with this text", and the app will see this and can make choices about where to put things in the template. 17:22:05 Zakim, ack florian 17:22:05 I see stearns on the speaker queue 17:22:10 florian: Yes, this seems to be the difference in approach. 17:22:18 florian: We want to allow JS, but not rely on it. 17:22:21 florian: So if that's th emodel, that's a problem. 17:22:39 florian: However, I think we can easily agree that exclusions as we currently have them (simple floats) are limited and we'd like to do more with them. 17:22:53 florian: For floats as we have them so far, there's a collision system built into the model. 17:23:11 florian: So you can't make an exclusions model that doesn't have a collision system. 17:23:26 florian: Your model is more expressive - you can do *lots* of different things with it. 17:23:42 florian: But by not combining it with a collision model, you lose the safety of floats. 17:24:00 florian: You're saying that people will deal with it by using something else. But they might not do that. 17:24:18 smfr has joined #css 17:24:36 florian: Whether you have to activate the collision stuff by doing soemthing else in CSS, or by using JS, either way it's suboptimal, because authors will forget to use it. 17:24:39 Zakim, ack stearns 17:24:39 I see no one on the speaker queue 17:24:46 stearns: Two points - text wrapping is meant for occasions when things collide. 17:24:59 stearns: Floats are allowed to collide witht he inline content, but text wraps around them. 17:25:21 stearns: Exclusions should be orthogonal to collision handling. You're *trying* to create a collision. 17:26:00 TabAtkins_: He's talking about multiple exclusions sitting on the same point and colliding with each other. 17:26:07 stearns: I think that's sometimes desirable. 17:26:33 stearns: Back to the beginnign example, if you have two fo these exclusions on a page and that was unintended, 17:26:38 stearns: If they're floats, you get float stacking behavior. 17:26:52 stearns: In most layout modes I've had experience with, float stacking is an error. Nobody wants that to occur. 17:26:56 q+ 17:27:01 stearns: What you get out of float stacking is not anything a designer would actually want. 17:27:19 stearns: So I think we need some additional controls for handling how things get arranged when a collision occurs. 17:27:40 dbaron: I think one of the ways we can solve that is by adding additional collision handling models for floats, so that stacking isn't the only model. 17:27:47 dbaron: Like "if I don't ahve space, go to the next page". 17:28:09 stearns: That would be great. But I think it should be orthogonal to exclusions. 17:28:28 florian: One thing that worries me is that if you're designing a webpage without exclusions in a GUI environment, you won't use abspos much. 17:28:56 florian: But if you do have exclusions, it's extremely natural to put a box in a place and say "wrap around me", and you'll start using exclusions in places where floats were just fine. 17:29:22 florian: You might have some logic in the GUI that creates floats instead of exclusions sometimes, but I think that naively it won't happen. 17:29:52 stearns: I think that 99% of the time, you'll have a single exclusion, so conflicts won't happen. 17:30:39 vhardy_ has joined #css 17:30:41 florian: I'm worried that it's just too easy to do this kind of thing with bad-behaving abspos. 17:31:15 szilles: I think that Grid will often be the easiest thing. People will want columns, etc. Very natural to do it in a grid, and no abspos is involved. 17:31:44 [argument about usefulness of abspos] 17:32:23 s/99/90/ 17:32:50 Rossen: One point I keep wanting to make is that the exclusions spec is trying to describe a general model for propagating exclusion areas through structures of content - any structure. 17:33:24 Rossen: Floats are an extremely document-centric tool that's intended to work in a single flat flow of textual content. 17:33:57 Rossen: This is meant to provide a base level of exclusion handling on the base level of floats, so when you have a higher-level layout system, once they're positioned there, everything that needs to be excluded is excluded. 17:35:27 [argument about running into things by default, or avoiding by default] 17:36:00 florian: *Because* this doesn't talk about positioning, it's possible, even easy, to let things run into each other by accident. 17:37:25 glazou: I feel that you're afraid of people abusing or just inexpertly using features. 17:37:29 [chaos] 17:37:42 glazou: Whatever we do, users will find ways to use it badly and good. 17:38:13 florian: We shouldn't try to prevent bad behavior - that's impossible. We should make good behavior the default, though. 17:38:27 it's entirely possible that there is no 'ideal' default here 17:38:58 Tab: Vincent, their point is that it doesn't talk about positioning -- that's *why* it gets bad behavior by default. 17:39:59 florian: You're seeing the complete independence of layout modes as a feature, I'm seeing this as a bug. 17:40:25 Tab: The goal isn't preventing bad behavior -- the goal is making good behavior the default. Taking the simplest route possible shouldn't lead to bad behavior. 17:40:55 stearns: The simplest case possible is a single exclusion. 17:41:45 stearns: would like to discuss on mailing list 17:41:51 szilles: I think they want graceful degradation under normal circumstances on the web. 17:42:39 [more chaos] 17:42:40 Sylvain: We've had this discussion in 3 cities now. 17:42:57 dbaron: What's new this time? 17:43:58 Florian: Extend floats to cover more use cases, rather than ... 17:44:07 glazou: This is not being minuted. 17:44:16 Tab: This same discussion has been minuted twice already. 17:44:20 glazou: This discussion has to be minuted. 17:44:22 q+ 17:44:29 ack dbaron 17:44:30 twice is an understatement, I'm pretty sure it's more than that... 17:45:01 Florian: I think a number of people would be more comfortable with extending existing float mechanism to cover more cases that it currently doesn't cover 17:45:20 Florian: Rather than the model being proposed here, which solves a bunch of things, and introduces a whole bunch of issues that we don't currently have a solution for. 17:45:27 Steve: It's not proven to me that it introduces the problem. 17:45:32 ack vhardy_ 17:45:58 vincent: the discussion we haven't been able to resolve is that ... exclusions & absolute positioning 17:46:02 Florian: doesn't say that 17:46:18 vincent: here exclusions has a model such that you can use it with other positioning schemes 17:46:31 vincent: The other option is to say that exclusions don't work with that positioning scheme. 17:46:48 vincent: Specification takes care to make a generic model. The repeated thing that says it's bad 17:46:58 vincent: The issue is an incorrect characterization of the problem. 17:47:06 vincent: I'd be ok with a specific technical issue the spec has 17:47:09 q+ 17:47:34 vincent: ... not with generic issues that the spec 17:48:10 not with generic issues about the spec relying on abspos because that's not true 17:48:12 vincent: but not with saying the spec relies on abspos because it's not the case 17:48:37 q+ 17:48:55 dbaron: The fundamental issue is that a whole bunch of us are saying that we don't think you should have an exclusions model without a collision model. 17:49:07 stearns: Can we put that in the issue? 17:49:43 Rossen: So if a collision model is expected at the same time as the exclusions, that's an issue we can address. 17:50:13 stearns: There's a discussion on the mailing list where florian said something like this. 17:50:32 stearns: I said that I'd be fine with exchanging the current issue text with what florian provided. 17:50:54 stearns: If dbaron could respond and say that's okay, we'd be great. 17:51:23 szilles: I can add a property that says "avoid collisions", and define what it does. 17:51:36 q+ 17:51:37 dbaron: It's really not that simple. 17:51:43 szilles: That's what XSL did. 17:51:50 ack TabAtkins_ 17:52:41 TabAtkins__ has joined #css 17:53:13 Florian: 2 ways forward: either the exclusion model as it is gets extended to deal with the bad cases or the model is dropped and instead we try to extend the float model to cover more of the use cases 17:53:30 Florian: Personally I don't know how to extend floats so I tried to propose an extra property for dealing with collisions 17:53:37 Florian: Even though I proposed that I'm not sure it's enough. 17:53:43 tantek: +1 17:53:50 Florian: ... go in the direction of making the current exclusion model less bad. 17:54:07 Florian: If we can add sufficient ..., then I think the exclusion model could survive. 17:54:16 Florian: If it turns out we can't enough, then we may have to look at another approach. 17:56:40 jet has joined #CSS 18:05:12 krit, around 1:15pm local time 18:05:23 glazou: great thanks! 18:10:11 drublic has joined #css 18:18:20 ScribeNick: tantek 18:18:22 Zakim, I am the scribe 18:18:22 I don't understand 'I am the scribe', tantek 18:18:41 Molly has joined #css 18:18:50 rossen: it would be great if we can reword the current issue to state the technical problem 18:19:09 rossen: exclusions as defined do not provide mechanism for avoiding exclusion to exclusion collisions if/when they are abs pos'd 18:19:22 florian: that is narrower than what I meant to say 18:19:41 florian: we need to prove that a collision handling system compatible with exclusions is possible 18:19:48 florian: the best way to do that is to design one 18:19:56 drublic has joined #css 18:19:58 florian: whether it should be optional is a different question 18:20:22 florian: missing bits: collision handling, preventing things from disappearing off the page 18:20:28 rossen: so changing how abs pos works? 18:20:32 vhardy_ has joined #css 18:20:52 florian: what the objectors want to see, is the addition of extra mechanisms to handle those missing bits 18:21:03 … that apply to all layout schemes 18:21:19 … that can be used to workaround the collisions and graceful degradation issues 18:21:24 rossen: could you summarize as an issue? 18:22:07 ACTION Florian: summarize the issue of missing mechanism(s) to handle collision handling, preventing things from disappearing off the page 18:22:07 Created ACTION-496 - Summarize the issue of missing mechanism(s) to handle collision handling, preventing things from disappearing off the page [on Florian Rivoal - due 2012-08-21]. 18:22:25 vincent: would like illustrations of things that have been characterized as bad things 18:22:42 florian: I will give some examples 18:23:05 florian: exclusions will make people use positioning schemes that have problems that they wouldn't use in this way if exclusions weren't there. 18:23:46 ACTION Florian: come up with examples illustrating the issues on exclusions as noted in previous action 496 18:23:46 Created ACTION-497 - Come up with examples illustrating the issues on exclusions as noted in previous action 496 [on Florian Rivoal - due 2012-08-21]. 18:24:07 Florian: to move forward I have a modest proposal for collision handling 18:24:34 florian: I'm not claiming this is a sufficient answer to all problems for exclusions, but it is a step in the right direction 18:24:49 florian: proposing new property, let's call it 'collision' 18:24:52 florian: … auto | allow | avoid 18:25:03 … auto computes to allow to preserve existing behavior 18:25:24 … avoid: if two things which both have collision property of avoid end up overlapping each other, the 2nd one in document order is moved out of the way 18:25:31 … how it is moved out of the way - up to discussion 18:25:41 … e.g. if there is room to the right, move it to the right, otherwise move it down 18:25:56 … could also have another property 'collision-mode' 18:26:05 … to switch between different kinds of clearance systems 18:26:20 … for now just need a way to say let things collide, or avoid the collision 18:26:27 lstorset has joined #css 18:26:43 vincent: do you foresee this for all positioning schemes? 18:26:48 florian: yes 18:27:02 vincent: e.g. also for grid? 18:27:11 vincent: a 2x3 grid 18:27:15 florian: in general yes 18:27:22 … property should be available to all layout modes 18:27:38 … if there are layout modes where we don't understand what 'avoid' means, we can make it compute to 'allow' 18:27:43 … for example for floats 18:27:48 … auto would compute to 'avoid' 18:27:53 … if you turn it to allow 18:28:03 … then you could have something like this (goes to whiteboard) 18:30:05 vincent: this may introduce behaviors in all other schemes 18:30:17 florian: I'm going to have auto compute to whatever existing schemes do for each 18:30:29 … e.g. on floats to 'avoid', on abs pos to 'allow' 18:30:45 … on top of that I would add 18:30:50 … because we are introducing exclusions now 18:30:58 … because they are likely to increase use of abs pos 18:31:02 … we have a chance of fixing it there 18:31:10 … on abs pos to which exclusions is applied 18:31:16 … auto should compute to 'avoid' 18:31:31 vincent: why are exclusions encouraging use of abs pos? 18:31:48 florian: i can answer, but it has been answered already 18:31:51 … a bunch of times 18:32:20 vincent: it's a different question 18:32:27 florian: it's the same, we've answered it a bunch of times 18:32:33 … it's maybe not answered well 18:32:40 fantasai: we keep having this same question/discussion 18:33:10 vincent: why do you think exclusions are encouraging the use of abs pos? 18:33:22 florian: i've answered this, but i would like to time answer it better. 18:33:30 zilles: vincent, why is the answer important? 18:33:45 peter: given exclusions, people will use abs pos more. i see that as a good thing. 18:33:57 peter: i have a question for you (vincent) 18:34:03 correction for florian 18:34:08 vincent, http://lists.w3.org/Archives/Public/www-style/2012May/0531.html 18:34:24 vincent, search for "But exclusions make abspos more attractive by avoiding" 18:34:54 peter: when you turn on exclusions for abs pos, you're defining how it should behave when it collides, he's asserting that the default behavior is that it shouldn't collide, and that doesn't make sense to me. 18:35:10 florian: this is a small but significant misunderstanding 18:35:27 … when the collision property computes to 'avoid', it avoids other things that have 'avoid' 18:35:37 e.g. if you have 2 abs pos *both* with 'avoid' they will avoid each other 18:35:40 … but not others 18:35:45 drublic has joined #css 18:35:53 rossen: if they're on top of another exclusion? 18:36:01 florian: if you want a collision... 18:36:09 rossen: how do you avoid one but not the other 18:36:17 … you are giving me only a binary choice 18:36:22 … I want to avoid some but not others 18:36:34 tabatkins: what's the use case for it? 18:36:43 rossen: 15 or so examples in the wiki 18:36:52 stearns: www-style list post from apple 18:37:10 florian: you have several examples where exclusions are supposed to be on top of each other, but avoid some other 18:37:15 So far, I don't like this 'collision' proposal all that much, but I'd like to think about it more. 18:37:30 florian: i don't think you have such things in the examples 18:37:44 zilles: you have a notion of grouping which acts as an entity and an exclusion goes into the group 18:37:53 … that would allow you to define an appropriate method of the exclusion process 18:38:10 florian: if it's really important we can do it, but i don't think it is necessary 18:38:49 florian: this is most useful on abs pos which have exclusions turned on 18:38:55 (in response to a q from vincent) 18:39:03 florian: the whole point I designed this 18:39:07 … is to try to save exclusions 18:39:13 … from the folks that say it won't work 18:39:39 vincent: are you proposing to work on the exclusions spec? 18:39:56 florian: I'm interested in working on everything, not sure I can commit the time. 18:40:04 … I am putting this out there, hoping folks find it interesting 18:40:11 … not promising I can carry it forward (time) 18:40:24 zilles: this is a proposal that you believe might lead to a suitable graceful degradation 18:40:42 florian: this is one piece of a solution to make exclusions acceptable, not sure it is sufficient 18:41:17 … this is useful, otherwise half the group will object to exclusions 18:41:34 molly: i can see this being very logical from the author perspective, useful in the scenario you described 18:41:57 … would be useful on a global thing 18:42:04 … any time you might have a collision 18:42:07 … to have that choice 18:42:11 … what would be the default be? 18:42:19 florian: for abs pos, allow, for floats, avoid 18:42:25 … just have to work out the layout modes one by one 18:42:48 … it may be tricky where collisions seem impossible 18:42:51 … e.g. in flexbox 18:43:09 … so what should we do? 18:43:17 q+ to suggest using grid templates (of course :-) ), i.e., replacing abspos instead of trying to enhance it... 18:43:20 … I think we can work it out for layout modes where collisions are *possible* 18:43:31 … and we can use 'auto' to preserve the existing behavior 18:43:35 Molly: would be useful 18:43:44 Peter: this is scary when layout modes intersect 18:44:00 … flex box, abs pos on top of it with avoid, what moves? 18:44:13 florian: with abs pos and float, we can move floats out of the way 18:44:20 … with flexbox there might not be an answer 18:44:32 … we may have to just say that with flexbox it computes to 'allow' 18:44:53 peter: if i have a flexbox with multiple items with collision values, and then a grid item with collision item with avoid, then ... 18:45:00 florian: respect document order, don't move the first one. 18:45:09 … the 2nd one moves out of the way 18:45:19 … if we don't find an avoidance behavior for flexbox they'll avoid 18:45:30 CORRECTION: they'll overlap 18:45:39 … if we do find an avoidance behavior, they'll avoid 18:45:47 zilles: at the risk of complicating things 18:45:52 … in grid, the default is that they overlay 18:45:57 … e.g. two things in one grid cell 18:46:05 … Bert's templates had the items stacking 18:46:17 … there's at least one option of saying avoid on things in a grid cell 18:46:20 … we could make them avoid 18:46:30 bert: that's a way to define exclusion, and then that's the grid 18:46:51 … either use grid-column and grid-row to put it there, it will overlap 18:47:00 … or the flow property and it will not overlap 18:47:35 (references previous a grid diagram on the whiteboard a a a … b … c c … ) 18:47:43 but it's not an extension of abs pos 18:47:50 … it's an alternative way of doing the same thing. 18:48:23 q? 18:48:28 florian repeats statement about defining for all modes. 18:48:36 q- 18:49:13 molly: I think you're solving what will become a design problem for designers 18:49:15 … no comment on syntax 18:49:16 q- 18:49:21 … but makes sense and would be teachable 18:49:45 Florian: do the people who object to exclusions feel better if something like this is in place? 18:49:51 Florian: just Tab? 18:49:59 Florian: I will try to write something up 18:50:46 florian: where should it go? 18:50:58 rossen: would prefer in positioning 18:51:02 … CSS3 Positioning 18:51:27 It works for me in CSS Positioning. 18:51:38 rossen: to me this makes sense to go with positioning. 18:51:45 Rossen you and I can put all this in there 18:51:52 molly: I also see this as a relevant approach to add control 18:52:00 rossen: even if they're not exclusions 18:52:02 molly: yeah 18:52:10 florian: I want to make it work universally 18:52:47 Florian's diagram from that he drew on the whiteboard: http://instagr.am/p/OUbY-Fg9c3/ 18:53:36 florian: you can give me an action item 18:53:53 ACTION Florian: write a draft proposal for the 'collision' property with values: auto | avoid | allow 18:53:54 Created ACTION-498 - Write a draft proposal for the 'collision' property with values: auto | avoid | allow [on Florian Rivoal - due 2012-08-21]. 18:54:19 CHANGE TOPIC 18:54:54 IMAGE VALUES 18:55:10 section 4.3 18:55:18 vhardy__ has joined #css 18:55:25 of css4 image values and replace content module 18:55:31 image-set 18:55:37 regarding responsive images 18:56:07 shows example 10 18:56:27 TabAtkins: describes the example 18:56:39 … 1x, 2x, 600dpi 18:57:01 daniel: why not use media queries? 18:57:20 TabAtkins__: defining connection speed, and when you want to download something is VERY difficult 18:57:31 .. even just doing 2 modes low/high is difficult. 18:57:40 Florian: allows the browser to only download one 18:57:51 TabAtkins__: can also result in perverse behavior 18:58:24 … if you have a highspeed connection, downloading big image, then go into a tunnel, and mq would switch to low-res even though you already have the highres big image 18:58:33 hober: mqs are about the display 18:58:47 florian: if we're dealing with bandwidth, there's no way to do with mqs 18:59:04 … OTOH dealing with bandwidth is so hard, that not convinced browser may be able to do it anyway 18:59:12 TabAtkins__: quality of implementation 18:59:20 … browser can do better 18:59:31 florian: if no one does better then this was pointless 18:59:43 … would be nice if browsers did something with bandwidth though 18:59:50 vincent: src-set? 18:59:54 See also "Why a scale factor and not a full-blown media query" in http://lists.w3.org/Archives/Public/www-style/2012Feb/1103.html 18:59:55 TabAtkins__: this is the css version of src-set 19:00:02 TabAtkins__: 3 issues 19:00:17 … 1. inconsistency with src-set 19:00:22 … suggestion: be consistent 19:00:37 hober: agreed 19:00:48 TabAtkins__: I do have one bit I'd like to keep 19:00:55 … you can specify a fallback color at end 19:01:02 … useful if browser can't download any image 19:01:12 … or on such a bad connection, browser decides to not download 19:01:16 … and just use color 19:01:21 … but we should drop other fallbacks. 19:01:30 hober: this is nice 19:01:43 vincent: i have a question 19:01:53 … user agent is presented with list of possible things, hints about resolution 19:01:58 … what if i have vector image for fallback 19:02:01 … but doesn't have hinting 19:02:08 … sometimes for icons you want hinting 19:02:19 … in cases like that am I still allowed to make those trade-offs? 19:02:27 … vector is high resolution but has benefit of being tiny 19:02:32 … would that be possible? 19:02:44 TabAtkins__: so on a highres device use SVG, on lowres use icon? 19:02:50 florian: and .... 19:02:55 TabAtkins__: I think you can do that 19:03:06 … with 2 diff resolution descriptors 19:03:18 … one very high resolution, and one very low bandwidth 19:03:32 florian: syntax is not ideal, but it is possible 19:03:56 fantasai: vincent's point/scenario above is a good one to note 19:04:08 TabAtkins__: don't adjust the resolution if you choose the image 19:04:18 … this is for a high res device, but nothing special has to be done to it. 19:04:51 Action TabAtkins: to address issue of where to put an SVG image for high resolution and low bandwidth in image-set. 19:04:51 Sorry, couldn't find user - TabAtkins 19:05:03 Action Tab: address issue of where to put an SVG image for high resolution and low bandwidth in image-set. 19:05:03 Created ACTION-499 - Address issue of where to put an SVG image for high resolution and low bandwidth in image-set. [on Tab Atkins Jr. - due 2012-08-21]. 19:05:25 vincent: in the version of image-set and src-set, there was more than just resolution, e.g. width/height 19:05:42 TabAtkins__: the reason is that src-set in HTML also allows width/height 19:05:48 … that doesn't show up in image-set 19:05:52 … because they are just MQs 19:05:59 … you can do those easily in CSS 19:06:07 … but you can't in HTML, that's why they're in src-set 19:06:20 Florian: the question is whether you can use full MQ syntax in HTML 19:06:40 … some don't want to, hence those features in the HTML version separate from MQs. 19:06:50 vincent: another issue was co-location of rules in style sheets 19:06:57 … e.g. your image resource in one place 19:07:02 … various conditions under which it would be used 19:07:07 … are you considering that now? 19:07:14 TabAtkins__: I remember seeing that suggestion 19:07:20 … this is not the right place to address that 19:07:29 … if we want to address MQs move conditions too far 19:07:35 … away from properties 19:07:43 … then we should address that by allowing nesting MQs 19:07:50 … not just for image functionality. 19:08:16 Peter: I like aligning with src-set, but I see the fallback behavior as useful. 19:08:27 Hober: purpose of the image function to do the decode fall back thing 19:08:31 … they're composable. 19:08:36 Peter: combining them will get ugly 19:08:45 Hober: combining them is not a common use-case 19:08:55 vhardy_ has joined #css 19:09:01 Peter: what will happen is someone point to one version then a high resolution 19:09:10 … and print version will get lost / 404 19:09:28 TabAtkins__: my use-case for this is being able to send down just one image 19:09:35 … rather than having to download multiple versions 19:09:45 … extra latency can be very harmful to page behavior 19:10:06 Peter: the fallback behavior is, pick the right one, try to download it, only if that fails, then you try the next one. 19:10:14 TabAtkins__: but that causes the bad behavior 19:10:24 florian: you're choosing between slow display and no display 19:10:37 dbaron: the other question is when do authors see that things are broken? 19:10:49 … e.g. if it goes and downloads a different one, then authors won't notice first problem. 19:11:05 Peter: then it gets back to philosophy debate of how things should fail gracefully or not 19:11:13 … whether you should have a fail-early mode for authors to check their pages 19:11:23 … in general browsers tend to do the right thing for users 19:11:39 Florian: how about we keep the fallback behavior and ask src-set to add it 19:11:49 florian: there is no downside for them here that's not here for us 19:12:11 florian: the one case it is actually worse, long list of many image, you try all of them, they all fail, and you're on a slow connection 19:12:30 hober: having a combination allows the author to explicitly choose what they want to do in those scenarios. 19:12:36 fantasai: then you have to repeat. e.g. 19:12:51 … combinatorial explosion of image sets within image sets 19:13:32 florian: if you put image-set in image then you can't know which part of the image will fail to load, you can't tell the browser which one to load, the answer is to next them the other way around. 19:13:41 fantasai: you have to repeat the entire list 19:13:53 TabAtkins__: the alternate way is, here is a fallback image if you can't use the one in the image-set 19:14:03 florian: unless the fallback is the one that failed to load 19:14:11 … then you need a fallback for the fallback 19:14:19 peter: the other problem is different fallback behaviors 19:14:31 … e.g. if browser picks medium one, and it fails, which one should it fallback to? 19:14:35 hober: the author should choose 19:14:52 peter: doesn't know what the browser is seeing 19:14:54 florian: add MQs on top of that then 19:14:59 … this is going to be a mess 19:15:09 hober: does anyone want to implement the crazy fallback situation in this case/ 19:15:10 ? 19:15:26 fantasai: it's just like having image but browser gets to pick the order 19:15:47 florian: we can try to align, and then make src-set align, and then if they refuse we can revisit 19:15:55 florian: it doesn't slow down the main use case 19:16:12 TabAtkins__: it doesn't slow down the everything works case, we care about the recovery behavior 19:16:22 … whether to do more connections automatically 19:16:31 … or have the author make that choice explicitly 19:16:45 TabAtkins__: most people on mobile connections don't want to download more connections 19:16:54 Hober: point is to avoid extra connections 19:17:00 Peter: no, point is to pick the right image 19:17:12 florian: downloading both to figure out which one to use is a waste of time 19:17:19 … either you look like crap or you dont' 19:17:25 q+ to say that SMIL, SVG, HTML and probably others all have solved or are trying to solve this same pb. Maybe it is time for a language-independent solution? Or we could just use SVG, which CSS already imports anyway. 19:17:36 peter: on a retina display, if high res version fails 19:17:43 … then I'm going to fallback with lower res version 19:17:48 … going to wind up with smaller data usage 19:18:17 florian: I think we should ask src-set to get the fallback behavior as well 19:18:20 TabAtkins__: I'm fine with that 19:18:38 … asking HTML about that 19:18:59 Bert: I'm wondering given all the other things we have to talk about 19:19:04 … should we really be discussing this? 19:19:08 … we can just use SVG 19:19:20 TabAtkins__: it has nothing to do with resolution negotiation 19:19:27 Bert: SVG uses SMIL 19:19:32 … switch statement 19:19:41 Florian: does not take bandwidth into account 19:19:48 Bert: lots of work on this 19:19:56 … why are we doing it at all? 19:20:05 florian: HTML is solving it for content, we need it for css 19:20:14 bert: should it be solved independent? 19:20:22 NEXT ISSUE 19:20:24 2 of 3 19:20:30 TabAtkins__: the ex unit 19:20:38 … it is a synonym for dppx unit 19:20:44 … should it use resolution unit 19:20:46 … or ... 19:21:07 TabAtkins__: (summarizes issue) 19:21:17 Peter: I don't think we should have the 'x' unit 19:21:21 s/ex/x above 19:21:35 Peter: I don't want a synonym 19:21:44 Hober: x just describes a scale factor 19:21:51 florian: HTML has the x unit 19:22:01 … we have the resolution thing already and not care about the x 19:22:11 hober: the resolution units are terrible and we shouldn't propagate them further 19:22:47 TabAtkins__ and hober argue about dpi vs dppx 19:22:47 (Re bandwidth: the SWITCH element does take bandwidth into account, via the systemBitrate attribute.) 19:23:54 florian: I think using resolution here is fine, I don't think we need 'x' 19:24:06 TabAtkins__: dppx is the worst name for a unit 19:24:30 … ddpx is an easy typo to make 19:24:33 … it's done a lot 19:24:50 fantasai: is it too late to change now? we have a CR 19:24:52 … we have implementations 19:24:58 TabAtkins__: dpi or dpcm? 19:25:06 zilles: it's not going to please half of the people 19:25:24 TabAtkins__: we are in a worse situation if we leave it to we already invented a crappy unit, and we don't want a better unit 19:25:31 jet has joined #CSS 19:25:36 Vincent: question - one is resolution vs length? 19:25:45 TabAtkins__: no, dppx is dots per pixel. not a length. 19:26:01 I actually think x as a synonym for dppx is pretty reasonable. 19:26:02 florian: just use resolution here, in addition if you want 'x' to be a synonym, let's discuss elsewhere 19:26:13 … if we introduce 'x' i want it everywhere 19:26:17 TabAtkins__: that's the proposal 19:26:19 NEXT ISSUE 19:26:21 3 of 3 19:26:41 actually "ISSUE 1" in current draft of spec (URL?) 19:26:53 TabAtkins__: image-set inside itself is an issue 19:26:57 … nesting 19:27:11 … we can either disallow it 19:27:19 image-set(image-set(foo 1x, bar 2x) 2x, baz 1x) 19:27:23 (and you choose foo) 19:27:26 Tabatkins: but then you have to search arbitrarily deep 19:27:51 fantasai: i suggest disallowing that example 19:27:57 hober: am ok with disallowing 19:28:03 … but still doable 19:28:07 TabAtkins__: am fine with disallowing 19:28:27 molly: when we start looking at syntax of this nature, designers will freak out 19:28:37 … I can see it turning into a horrible problem 19:28:47 florian: someone writes a blog post … gets copy pasted everywhere 19:28:58 Molly: i'm concerned with the syntax 19:29:25 … I just want to advocate always keeping syntax in CSS as human as possible 19:29:33 … the nesting starts to look confusing 19:29:44 TabAtkins__: agreed in general, nesting functions is usually confusing 19:29:52 LUNCH 19:48:12 drublic has joined #css 19:51:04 Koji has joined #css 19:56:34 vhardy_ has joined #css 19:58:39 mmielke has joined #css 19:59:39 drublic has joined #css 20:06:21 drublic has joined #css 20:27:46 pcupp has joined #css 20:27:51 myakura has joined #css 20:30:09 vhardy_ has joined #css 20:33:33 vhardy_ has joined #css 20:36:10 ksweeney1 has joined #css 20:36:32 ksweeney1 has left #css 20:41:26 pcupp: still gathering people from the lunch break afaict 20:41:34 pcupp: will let you know once we restart 20:41:54 krit has joined #css 20:46:03 fantasai: could you send us the phone number to join the discussion? 20:46:36 TabAtkins_ has joined #css 20:48:22 pcupp - do you have skype? 20:48:45 pcupp, yes we'll use Skype 20:48:57 (it's a Microsoft product now - allegedly) 20:49:54 ScribeNick: fantasai 20:49:54 scribenick fantasai 20:50:38 fantasai: Should do Grid Layout, b/c pcupp is waiting 20:51:31 TabAtkins__ has joined #css 20:51:59 sylvaing is setting up Skype 20:52:29 pcupp, call w3c-csswg 20:52:31 discussing element() while waiting for technical stuff 20:52:50 still in css4-images 20:52:55 section 4.4 20:53:02 Tab: Right now syntax is limited to ID selector 20:53:32 Tab: Bit limiting -- means you have to attach an ID to the element 20:53:40 Tab: Some thoughts on how to extend this 20:54:04 Tab: firstly, arbitrary selectors. Represent first such element in the document 20:54:15 dbaron: Seems potentially expensive 20:54:25 for dynamic updates 20:54:59 fantasai: I don't see very strong reasons to have that vs. ID selectors, there are no implementations, would prefer to defer this to another level 20:55:14 sylvaing, not a skype user... will get it setup and then call... give us a sec (is there not just a phone number?) 20:55:27 Tab: ok, I'm ok with that 20:55:35 Tab: Secondary one, should be able to point to SVG paint servers 20:55:36 pcupp, no no phone. and skype sound will be way better (yes, really) 20:56:00 Tab: Problem is you have to literally embed SVG into the HTML 20:56:06 at next ftf, we will discuss speedos instead of pseudos 20:56:11 Tab: If you want to use across style shets, have to duplicate the SVG in every document 20:56:19 Tab: would be nice to point at an externa SVG document 20:56:36 dbaron: Does that do anything that an SVG rect with fill property wouldn't do? 20:56:40 A use case I would like to see addressed is to be able to select a page as generated by overflow:paged as the source of element(), so that a visual index of pages can be created and used to navigate through a interactive paginated document. 20:57:14 Molly has joined #css 20:57:42 Tab: I guess not.. 20:57:54 fantaai: Would that work for all fills, including patterns etc. 20:57:59 dbaron: Think so 20:58:27 fantasai: So why do we want to point to paint servers if we can just point to SVG? 20:59:05 fantasai: I think we do want to make sure we can pull SVG gradients/pattersn/etc out of an SVG document *somehow* 20:59:31 dbaron: Not sure it adds any complexity to what we're doing in any case 20:59:48 Tab: How do we point to something not in the document? 20:59:58 Tab: Use case of creating a canvas element in script, using it in various other places 21:00:08 Tab: Right now have to put the canvas in the document with display: none 21:00:12 Tab: Ideally can use it via script 21:00:19 Tab: Mozilla can do that currently, not sure it's ideal 21:00:33 Tab: It aliases an ID to point to a particular image element (which may or may not be in a document) 21:00:51 Tab: In a previous draft I had this take either ident or ID selector 21:00:57 Tab: But that conflicted with wanting an arbitrary selector 21:01:09 Tab: If we don't end up wanting arbitrary selectors... 21:01:22 Florian: Haven't found another way to select arbitrary pages etc. 21:01:28 Tab: If we don't need URLs, we can just use the string for that 21:01:43 dbaron: could also just have two function names 21:01:53 Tab: Seems a little bit messy, but not opposed 21:02:36 fantasai: Also have element() name conflict with gcpm 21:02:38 as an issue 21:02:50 Tab: issue on how to make an element not in the document to be available 21:02:54 Tab: FF does a name-mapping 21:03:04 Tab: Another option is to just have a map, hanging off of the document 21:03:15 Tab: document.CSSElementMap() to make a map 21:03:29 Tab: don't know if any real benefit to one or another 21:04:09 webkit already has a kind of map for -webkit-canvas 21:04:13 side discussion on selector matching of multiple elements with same ID 21:04:17 document.getCanvasContext() or something 21:04:50 fantasai: one of the main use cases for this originally was reflections. How does this solve reflections? 21:05:20 Tab: You would give the element an ID, and then create a rule for that element 21:05:40 fantasai: But I can't say "I want these 5 icons to do reflections" 21:05:47 Tab: Yeah, you'd have to handle each one individually 21:06:00 dbaron: There've been lots of interesting demos of this functionality, but don't remember how reflections were handled 21:06:40 maybe you need a special selector for "the element the style is applied to" 21:06:54 Wouldn't that be :scope? 21:07:00 or :context, whatever it's called 21:07:06 glazou: The idea is to use an IDREF 21:07:55 glazou: selector:after { content: element(attr(id)); } or somesuch 21:08:31 Molly: I look at syntax like this and I just want us to be aware that we might be crossing the understandability line. 21:08:39 sucks to have to add IDs to everything that needs to be reflected 21:08:48 Molly: The more it looks like programming, the harder it is for visual designers to follow 21:09:24 fantasai: I think we need to start threads on www-style for all of these 21:09:42 Tab: It appears from mailing list conversation that element is rendered as a stacking context 21:09:53 fantasai: real or pseudo? 21:09:55 Tab: real 21:10:28 Tab: Do we require that thing is already a stacking context? Draw it as a real stacking context as we draw element()? Or figure out how to work around the issues somehow 21:10:39 Tab: Need ppl working on rendering engines to comment 21:10:45 Tab: people like smfr 21:10:49 smfr, skype w3c-csswg? 21:11:07 ACTION: TabAtkins start threads for each issue and track them all 21:11:07 Sorry, couldn't find user - TabAtkins 21:11:08 don't have skype set up 21:11:14 http://wiki.csswg.org/spec/css3-grid-layout#issues-for-san-diego-2012-f2f-meeting 21:11:36 Topic: Grid Layout 21:12:58 oh, right, ick, you'd have to avoid infinite reflections….. 21:13:17 Tab requests fpwd of css4-images 21:13:31 szilles: Having a trouble figuring out FPWD criteria here 21:14:04 szilles: We're not terribly consistent about that. 21:14:30 To the referencing of paint servers. The SVG WG is looking into it as well. And we want to point to paint servers in general, also external resources 21:15:00 fantasai: Think it's that the WG agrees to work on this thing, roughly in the form it's in although there may be many open issues. No objections to the conceptual design 21:15:01 Therefore element() should support any IRI like SVG does with fill and stroke already 21:15:20 szilles: So it has sufficient content that the scope is reasonably clear 21:15:36 Florian: And the draft is understandable to people outside the WG 21:16:20 Florian: 1. Scope needs to be clear. 2. We agree on the approach take to solve the problem. 3. Understandable by 3rd parties. 21:16:43 jdaggett: I would add 4. It's enough of a priority that we should be doing it now. 21:16:51 jdaggett: Think we should be waiting on things that are lower priority. 21:17:39 (To be clear, this is a discussion about our general requirements for FPWD.) 21:18:02 RESOLVED: Publish css4-images FPWD 21:18:13 RESOLVED: Principles 1-3 for publishing FWPD. No consensus on 4. 21:19:20 Bert: It's hard to stop people from working on things if that's what they want to do. Can only stop them from publishing. So I like #4, but not sure it makes a difference in practice. 21:19:35 arronei_ has joined #css 21:19:57 glazou: Nobody cares about FWPD vs. ED. If we block FPWD, that doesn't have any effect, people will implement ED without FPWD. 21:20:17 dbaron (before Bert): People criticize us for not getting things done; yet we spend time on whatever anyone brings up. 21:20:33 plinss: If you feel that group is not managing priorities well, that's a separate discussion. 21:21:02 Topic: Grid Layout 21:21:50 fantasai: Let's all thank Phil for being very patient with us for starting late, for discussing other things, and for not having a phone connection. 21:22:00 can you hear us? 21:22:16 pcupp: If everyon e looking at wiki link 21:22:25 pcupp: First topic is [dropped connection] 21:22:47 pcupp: In hamburg we didn't really talk about why dropping named lines 21:22:55 pcupp: just said general consensus among editors 21:23:01 pcupp: Wrote out rationale here 21:23:22 plinss: Named lines are powerful and useful 21:23:26 plinss: would object to dropping them 21:24:12 plinss: Think named lines are very important to grids 21:24:16 .... . .-.. .-.. --- 21:24:27 plinss: look at historical usage, have classes of lines, types of lines, naming them is quite important 21:24:38 plinss: if you want layouts that can adapt quickly without redefining everything from scratch 21:24:49 plinss: with named lines can just move the lines around and everything just works 21:24:53 fantasai: We have that with templates. 21:25:08 Molly: Has everyone read Mark Boulton's blog post on grid issues? 21:25:13 several: yes 21:25:23 Molly: Would like to keep language similar to what language designers use 21:25:34 Molly: discuss takeaways 21:25:34 Koji has joined #css 21:25:40 pcupp: Two comments 21:26:06 pcupp: Wrt plinss, agree with fantasai that points made about named lines aliasing capabilities are handled by template 21:26:17 URL for article: http://www.markboulton.co.uk/journal/comments/open-letter-to-w3c-css-working-group-re-css-grids 21:26:23 pcupp: Template syntax is preferred by editors, including Bert and fantasai 21:26:41 pcupp: 2nd point from Mark Boulton's post, Bert has a good response to that 21:26:54 pcupp: In his model, grid sizes are fixed, and content adapts on top of that 21:27:05 pcupp: But in our grid, the rows and columns can adapt to their contents 21:27:27 pcupp: Similar to tables, but with more predictable sizing and better placement capabilities 21:27:43 pcupp: Having read through Mark Boulton's blog post, it doesn't solve the same set of scenarios because using fixed grid 21:28:06 pcupp: Nomenclature of past grids, originate in print media where don't have fluid layouts: no resizing of the page or dynamic content 21:28:20 pcupp: Grid that we have addresses more scenarios and I think the template syntax is sufficient aliasing mechanism for that grid 21:28:25 Molly: I was just concerned with the nomenclature 21:28:34 Molly: more we have of that, better it is for authors 21:28:42 pcupp: Wrt nomenclature, we have a bugzilla issue on that 21:28:55 pcupp: e.g. we have column-gap and column-rule for gutters 21:29:00 pcupp: There would be a discrepency there 21:29:13 pcupp: Is it more important to call them gutters, or snap to what's already used in multi-column? 21:30:05 fantasai: From reading the blog post, the only thing I noticed where we could change things, where the concepts matched and we weren't constrained by existing (e.g. column-gap vs. column-gutter), 21:30:13 fantasai: was to change "grid area" to "grid field" 21:30:33 szilles: There are a number of variable-size designs in print design as well, printing onto different pages/cards/etc. 21:30:51 plinss: There's a long history of grids in print publishing, don't think we should lose that. 21:31:01 pcupp: I'm not proposing that there isn't such a thing as a grid line 21:31:08 pcupp: I'm saying that we don't need to give those things names 21:31:18 pcupp: Because as an aliasing syntax, I think it's poorer than the template syntax 21:31:28 plinss: You currently specify that you can only have one name existing once 21:31:38 plinss: Think we should be able to reuse same name over and over across the grid 21:31:58 plinss: e.g. class lines into "left line" and "right line", and have multiple of these 21:32:09 plinss: If something gets bumped out of the way, snaps to next line of same class 21:32:15 plinss: Especially vertically, that's done quite commonly 21:32:26 plinss: Can avoid collisions and have things snap to lines 21:32:34 plinss: e.g. snap headlines to a headline line 21:32:39 plinss: you can't do that without giving an identifier 21:32:53 jdaggett: Are you saying that you want that feature specced out in this module? 21:32:58 we just dropped 21:33:00 plinss: I want that capability in this spec 21:33:02 hang on 21:33:05 reconnecting 21:33:59 fantasai: I think what plinss is asking for is very useful, but it's not what this module is currently about 21:34:13 fantasai: named lines as they are right now aren't about a snap-to-grid modle 21:34:21 fantasai: The current model is about positioning into specific slots into the grid 21:34:30 fantasai: and named lines are a really awkward way to do that. 21:34:44 pcupp: ... 21:34:53 pcupp: Not clear why current grid would preclude a snapping feature 21:35:54 fantasai: I agree we should have snap-to-grid, but that's not what this module is about 21:36:12 fantasai: Could add it as a different module, one that interacts with this one or reuses some of its syntax, but it would be a different hing 21:36:18 plinss: I don't what to have two different kinds of grids 21:36:33 plinss: My proposal is that this grid system do what grids historically have done 21:36:38 plinss: and think named lines is an important feature 21:36:51 plinss: think snapping-to-grid feature should be an easy extension of this grid 21:37:04 Bert: There are different traditions 21:37:12 Bert: I've seen grids, but not named lines 21:37:48 plinss: It's not named explicitly, but if the designer draws out the grid the lines are drawn out differently and different things align to different types of lines 21:38:00 plinss: They're not named because the designer is laying things out manually 21:38:18 we dropped again 21:38:23 Tab: How is this different from template positioning? 21:38:26 plinss: Can't have repetition 21:38:39 plinss: say I have text flow through multiple boxes 21:38:57 plinss: want image to snap to nearest available image line, which is different than text-snapping lines 21:38:57 reconnected 21:39:10 plinss: This is how grids have historically been used 21:39:21 szilles: Peter's model doesn't have cells, it has lines. 21:39:26 plinss: I want a model that doesn't have cells. 21:39:47 pcupp: Can you have lines that are positioned by content in your model? 21:39:57 plinss: Historically they have not been used that way. 21:40:09 plinss: But could. 21:40:16 plinss: Algorithm is complex, but not that complex. 21:40:25 pcupp: In algorithm right now, size influences other elements 21:40:42 pcupp: When you introduce snapping-to-grid feature, then depending on where the item is position it may span more lines 21:40:49 pcupp: but the lines depend on the sizes of contents inside 21:40:52 pcupp: so get a cycle 21:41:01 pcupp: If you have a fixed grid, can have content stretch over it 21:41:08 pcupp: But doesn't create relationships among contents 21:41:24 pcupp: e.g. item in here is as wide as all other items in the column 21:41:32 pcupp: Right now grid track sizes can be driven by content 21:41:45 pcupp: So grid flexes to fit the content, rather than items flexing to fit the grid 21:41:50 pcupp: I don't think you can combine these two models. 21:41:59 plinss: I don't have a mathematical proof of the opposite either 21:42:25 Florian: Can't you get the model you want by chaining cells using regions, and then pouring content into the regions rather than the cells? 21:42:30 szilles: no, they're not cells 21:42:37 szilles: ... offest it to the next line 21:42:46 szilles: Straight line in sequence of cells 21:42:54 plinss: Have cells that are overlapping 21:43:04 plinss: Because going to arbitrary lines for different things 21:43:14 dropped again 21:43:17 Zakim has left #css 21:43:19 reconnecting 21:44:07 fantasai: So... afaict nobody wants the named lines as they are in the spec now. 21:44:13 fantasai: We have a desire for a snap-to-grid model. 21:44:17 plinss: disagree with that 21:44:25 plinss: I like the named lines as they are in the spec. 21:44:30 fantasai and Tab think they're horrible 21:44:46 pcupp: Let's walk thorugh current named lines 21:45:22 link again, in case anyone needs it: http://wiki.csswg.org/spec/css3-grid-layout#issues-for-san-diego-2012-f2f-meeting 21:49:48 pcupp: First thing that's a little unnatural is template syntax using idents 21:49:57 pcupp: whereas named lines use strings 21:50:05 pcupp: This is due to syntactic collisions 21:50:08 szilles: asks about collisions 21:50:08 fantasai explains there are two points of collision for named lines: 21:50:08 with template slots, and within the grid track syntax with size keywords 21:50:08 pcupp: named lines is 4x as long as the alternative syntax we proposed, 21:50:08 pcupp: because you need 4 lines, but only one area 21:50:15 does anyone have a cell phone that we could call? 21:50:21 zakim, room for 3? 21:50:48 we dropped again 21:51:09 Zakim has joined #css 21:51:09 we're attempting to get you back online somehow :) 21:51:16 zakim, room for 3? 21:51:18 ok, plinss; conference Team_(css)21:51Z scheduled with code 26632 (CONF2) for 60 minutes until 2251Z 21:52:28 Team_(css)21:51Z has now started 21:52:34 +??P8 21:52:48 pcupp: is that problem clear? 21:54:04 szilles: I just want to move the lines 21:54:24 plinss: I'm going to move all the lines, and keep things stuck to the lines 21:54:41 pcupp: did you see in the sample, that by naming lines, we just created a box. Might as well have used a name 21:54:44 d slot 21:54:57 szilles: You're focused on creating cells, that's not what plinss is asking for 21:55:05 pcupp: I just want to put an item into the grid 21:55:31 discussion of whether overlap is desired 21:55:45 szilles: You want your figures to bleed into the gutters, but not the text 21:55:52 pcupp: The grid definitely allows overlapping 21:56:01 pcupp: The template syntax doesn't allowed named areas to overlap one another 21:56:09 plinss: You lose that by losing named lines 21:56:18 pcupp: Seems pretty specialized 21:56:20 use case 21:56:26 Bert: I've never seen that 21:56:34 plinss: I'm talking about boxes wrapping around each other 21:56:37 Bert: yes, exclusions 21:56:44 Bert: They don't overlap, they wrap around 21:56:51 Molly: Wouldn't that be deconstructing the grid? 21:57:12 Molly: Maybe this is part of the problem. They're thinking about cells too. 21:57:22 Molly: It's part also of the table legacy 21:57:36 szilles shows a picture of a grid layout 21:58:00 one tall box along the left side, intersecting a long horizontal box in the bottom third of the page 21:58:16 Bert: That's not named lines. That's a specific layout for a particular poster. 21:58:25 Bert: You're not aligning images to one line and text to another 21:58:37 Bert: You can do that with the grid, too, but not necessarily the default. 21:58:55 szilles: We're not saying that you can't use what's in the module right now, but that there are other uses 21:59:09 plinss: You get the other cases by naming the lines, and thinking of it in terms of lines rather than cells. 21:59:14 plinss: It's an entirely different mental model. 21:59:42 plinss: We have a whole bunch of different layout systems that use boxes 21:59:48 plinss: flexbox, tables, floats 21:59:56 fantasai: But none of those do 2D alignment. Grid does 22:00:00 plinss: 2D flexbox 22:00:05 fantasai: That's what Grid Layout is. 22:00:46 plinss: Haven't we all used vector drawing program? 22:00:58 plinss: First thing you do is drag out guide lines, and start laying things out to those lines. 22:01:08 Tab: Alternative is that main thing grid layout tries to do 22:01:19 Tab: is take the table-based layout concepts and make them not shitty 22:01:23 Tab: These are two different use cases 22:01:33 Tab: You can't just say "put named lines into grid" 22:02:05 Tab: question is whether named lines should be in this grid module 22:02:11 Tab: The way they are defined now, no. 22:02:50 Tab: As they are written right now, as the spec is designed right now -- and I think the model in the spec is a good one -- 22:02:57 Tab: named lines doesn't if it 22:03:02 s/if it/fit in/ 22:03:14 Tab: we should go and see if we can add a snap-to-grid model 22:03:48 Tab: Make grid layout work nicely with snap-to-grid 22:04:08 Florian: Do we need to rename what is currently called grid to something else? 22:04:13 sylvaing: No, we do that at Last Call. 22:04:18 krit has joined #css 22:04:30 jdaggett: The spec right now is called Grid Layout, we had another one called Grid. 22:04:40 jdaggett: That was more of a graphic designers view of grid layout 22:05:20 fantasai: That model was abspos with grid coordinates, had all the collision problems of abspos, didn't have snap-to-grid 22:05:50 plinss: You need exclusions and you need collison model. 22:05:57 pcupp: So, where are we now? 22:06:20 szilles: I'd summarize, we've establishe dclearly that the set of things that szilles and plinss want to do is different from the set of things you want to do 22:06:26 szilles: Certainly common overlap between the two 22:06:37 szilles: Haven't established whether it's impossible to do them all in the same model 22:06:50 plinss: I think we can do this in one model 22:07:09 jdaggett: We need a concrete action item on someone to write up the functionality that you think is required. 22:07:18 jdaggett: Having this discussion over again is counter-productive. 22:07:21 pcupp: Agre 22:07:22 e 22:07:34 jdaggett: I'm not objecting to what you're proposing, but we need a proposal that's in more concrete form 22:08:30 sylvaing: Can we pull what's in the spec out? 22:08:38 sylvaing: and put an issue to design something new? 22:08:58 plinss: Been asking for grid people to understand the model I want 22:09:07 plinss: If we pull the named lines then it'll go the wrong way 22:09:19 Tab: I don't think you want to patch what you want onto the current named lines 22:09:30 plinss: I think what we want is going to be different than what we have 22:09:35 plinss: Otherwise we'll fork the spec 22:09:59 Tab: What currently exists is not what anybody wants. So we shouldn't have it in the spec. Kill it and go ahead, develop something better that we can put back into the spec 22:10:18 Tab: Nobody's helped by the thing that's in the spe cright now. 22:10:30 szilles: as long as I can only define cells between adjacent lines 22:10:48 szilles: If I can define cells that can span lines, then I can get what I want 22:10:54 several: You can already do that. 22:11:38 pcupp: wrt maintainability, it's easier to renumber than to come up with four names per box 22:12:12 plinss: Problem with current system is that if I make a new grid with different number of lines, because different sized page, I have to go and redefine where everything lands in that grid 22:12:33 q+ 22:12:36 Tab: But you don't. You use a template together. Don't even have to use the template slots, but can use the names created by there to position grid items 22:13:21 Tab explains how grid template slot names can be used as coordinates 22:14:10 plinss: If we want to add what plinss wants, it's something completely different from this 22:14:41 Molly: The problem here is a lot bigger than maybe we even imagine 22:14:54 Molly: CSS Layout is a bear. Now the concerns I want you to come back to is to ask ourselves who is the customer, who is to user 22:15:40 Molly: The author is the user. Based on that, the integrity of grids and the long history that designers have, should be maintained by calling it grid. Simultaneously a template is a grid, but more like table model. Grid system is a line system. We have to do this correctly or we end up harming authors more than helping them. 22:15:41 q+ to say that most lines in a grid have multiple functions: the same vertical line delimits text in the first row and images in the second. Finding a name for that line is going to be difficult. 22:15:45 Tab: So you're saying we shoudl rename the spec 22:17:03 sylvaing: The grid model here is familiar to anyone who understand tables. Don't understand why that's bad 22:17:08 jdaggett: model is not as familiar as you think 22:17:26 jdaggett: This is an *application developer's* model of a grid. It's not a graphic designer's concept of a grid. 22:18:33 jdaggett: What I do think needs to happen is that Peter and Steve need to iron out a concrete proposal of how to change what's there into what you want. 22:18:43 sylvaing: Different designers are comfortable with different models 22:18:46 sylvaing: We need both 22:19:02 plinss: I believe we can have a unified grid model. 22:19:19 plinss: That has the functionality page designers want, but allows you to address things the way the spec defines it. 22:19:31 plinss: I want this unified grid model. I don't want Yet Another layout system 22:19:34 Florian: How to get there? 22:19:55 Florian: Should we yank the bit that's currently in the spec, or leave what's there until we either find a replacement or an addition that makes it better? 22:20:04 plinss: If we yank it now, we've gone down the path of the application grid 22:20:26 Florian: Maybe the solution you want will replace what's there, maybe add to it 22:20:40 jdaggett: Let's mark the spec with a big red issue, mark it as under discussion 22:21:31 Florian: Add an issue next to the bits proposed to be yanked, saying these bits are trying to accomplish [insert description of what plinss] wants. We are still looking for a way to address that problem well. 22:21:51 Tab: I would not tell our implementers to implement grid lines as they are in the spec 22:22:11 Tab: Leaving it in leave the spec in a weird state that we have something we *know* we don't want 22:22:42 jdaggett: I think Tab's arguing that we shouldn't put things in our specs that we know are complete rubbish. 22:23:42 Tab: I doubt the correct solution is an evolution of the current spec 22:24:27 Florian^: Should leave work in progress in the spec so people can build on it 22:24:52 fantasai: What Tab is saying is that anone working on this problem would be better served by a blank slate than starting with what's there. 22:25:45 plinss: Tab made a point that named lines complicates the model. It doesn't, it only complicates the syntax of addressing the model. 22:26:04 jdaggett: Can we wrap this up with an action item? 22:26:20 jdaggett: I'd like an action on Peter and Steve to come up with a concrete proposal. 22:27:02 ACTION szilles and plinss to describe a line-based layout grid unified model of everything 22:27:02 Sorry, couldn't find user - szilles 22:27:12 ACTION pcupp Add note Florian proposes to the spec 22:27:13 Created ACTION-500 - Add note Florian proposes to the spec [on Phil Cupp - due 2012-08-21]. 22:27:45 pcupp: we tried to bring this into the model and failed. we need you to show us the way 22:28:13 ACTION plinss draft note Florian proposes and send it to pcupp 22:28:14 Created ACTION-501 - Draft note Florian proposes and send it to pcupp [on Peter Linss - due 2012-08-21]. 22:28:28 myakura has joined #css 22:56:00 disconnecting the lone participant, glazou, in Team_(css)21:51Z 22:56:02 Team_(css)21:51Z has ended 22:56:02 Attendees were glazou 22:57:12 myakura has joined #css 22:57:16 drublic has joined #css 23:00:03 pcupp: Next item... 23:00:15 pcupp: I have another thing describing anonymous grid items and how we create them 23:00:21 pcupp: There are some images there that help show this 23:00:31 pcupp: Current behavior in spec mirrors Flexbox behavior 23:00:45 pcupp: All children of grid are grid items, loose text is wrapped in anon grid item 23:01:07 pcupp: A complaint is that these items all stack on top of each other in the first cel 23:01:17 pcupp: If you turn on auto-flow, you'll get separate grid items that flow into boxes 23:01:28 pcupp: What we recently discussed on a last telecon, talked about what if we did something different 23:01:38 pcupp: What if we wrapped all the contents of grid element into one anonymous grid item 23:01:51 pcupp: and pulled actual grid items out of the flow of the anon one and positioned them 23:02:10 pcupp: Default grid item could be auto-positioned, or put in 1-1 23:02:16 pcupp: and so you get third image 23:02:32 pcupp: Introduced one more idea, what if you use this ocncept of everything in anon item 23:02:46 pcupp: and allow descendants with grid-pos properties to be pulled out of the flow, not just direct children 23:02:55 pcupp: fantasai pointed out a point recently, wrt markup 23:03:00 pcupp: e.g. form elements inside list items 23:03:09 pcupp: say you wanted labels in 1st column, inputs in 2nd column 23:03:22 pcupp: what do we do with this remaining markup? does it collapse down to nothing? 23:03:33 pcupp: With descendants pulled into grid, have this issue 23:03:45 pcupp: Then the conversation on www-style, fantasai proposed we could deal with this by a new 'display: subgrid' 23:03:57 pcupp: Then some discussion of pursuing subgrid, or deferring it 23:04:19 pcupp: Question to WG is, do we address this now, or defer to later level and just try to handle compat later 23:04:35 s/later/now/ 23:04:54 Tab: I support wrap everything in anonymous grid cell and pull things out 23:05:11 Tab: I think that also happens to solve the problem of what to do with leftover markup when you pull descendants out 23:05:16 Tab: goes into anon grid cell 23:05:24 pcupp: How do we keep it from displaying 23:05:42 Tab: make anon cell display: none by default 23:05:47 fantasai: We try not to have things disappear by default 23:06:01 fantasai: try to have things show up by default 23:06:05 fantasai: So what you're proposing is that if something's display:grid, then suddenly the things inside it wouldn't show up. 23:06:15 Tab: Template had default slot concept 23:06:23 Tab: Could even have that be the default template 23:06:57 fantasai: Pulling things out into the ancestor and having grid stuff all float together seems like a good idea. 23:07:08 Molly has joined #css 23:07:23 fantasai: we have a grid-auto-flow property that would let us switch into auto placement 23:07:49 fantasai: My concern with pulling sub-grids into a later level is that it seems like a lot of markup that we want to lay out with grid has structure to it. 23:08:02 fantasai: You want several layers of descendants to participatein the same grid and align together. 23:08:16 fantasai: To use the current level of grid you'd have to strip out that markup, and couldn't have graceful fallback to non-grid layout. 23:08:24 fantasai: So my concern with deferring it 23:08:42 fantasai: ... is that if it was possible to add later and still be possible to have sane markup at the current level 23:08:47 fantasai: ... but I'm concerned that we can't. 23:09:01 fantasai: Bert brought up -- mail on www-style 23:09:37 fantasai:
23:09:46 fantasai: you might want to have label and input and put borders around it 23:09:52 fantasai: [draws] 23:10:06 fantasai: want to align the labels and the inputs 23:10:22 fantasai: if you don't have subgrids you can't do that -- you either have to strip out the markup or keep it styled so that it will effectively disappear 23:10:37 fantasai: so this seems like a sensible common use case for ui grids -- to style intermediary list-item 23:10:50 Peter: When you use the term sub-grid, you mean children or descendant elements, not grids within grids? 23:11:10 fantasai: the idea was that display:subgrid behaves like display:grid except that the children are laid out into the same grid as the parent instead of creating new grid lines 23:11:19 fantasai: but coordinates are scoped and margins and padding are subtracted out 23:11:29 Steve: Is it a way of changing what the items are? 23:11:36 fantasai: I should pull up my email... 23:11:50 Phil: IN fantasai's proposal, she's saying the grid lines are permeating the descendants with display:subgrid 23:11:58 http://lists.w3.org/Archives/Public/www-style/2012Aug/0310.html 23:12:08 Phil: It's their children or however far you drill down... it's those items that influence the content-size tracks of the grid. 23:12:25 Phil: ??? to account for margin / border / padding on ancestor elements by pretending they have larger margin 23:12:32 Phil: Has great potential, I like the ... . 23:12:52 Phil: In level 1, is it not a reasonable requirement that people tailor their markup so they have the items at the right level to operate on the right grid level 23:12:54 ? 23:13:12 Phil: I don't know why we couldn't add this in a later level of grid. 23:13:21 Phil: And people need to be able to author markup with subgrid in mind today. 23:13:39 Phil: The issue isn't about authoring with subgrid in mind; it's about authoring the markup as it should be and then choosing to display it wit hgrid. 23:13:49 Tab: Example markup in wiki: this kind of thing is very reasonable. 23:14:00 Tab: The correct way to mark up html that puts the signifcant parts as not children of the grid 23:14:12 Phil: But in this example I created it to illustrate a problem that exists due to markup structure. 23:14:22 Phil: But I could have collected labels annd inputs as children of grid. 23:14:36 Peter: What you would have lost is how these things behave on a client that doesn't support grids 23:14:40 Tab: or a client without CSS at all? 23:14:52 Florian: You write the markup because it's the correct way to mark it up, then style it. 23:15:10 Tab: You sometimes need to adjust your markup some... the question is what's too much in terms of requiring adjustment in markup. 23:15:17 Tab: Having to flatten all children seems like too much. 23:15:35 Tab: Case of figure -- pulling out img and figcaption -- can't do that without losing markup connection from
. 23:16:07 Bert: With example on whiteboard -- issue is how you get a border around 2 things that are individually positioned. That's not just a matter of markup, also the issue of how to make a border around something that's not a single cell. 23:16:21 fantasai: This isn't an issue about creating pseudo-elements, since it's something that the markup has or should have. 23:16:42 Phil: One issue about border -- not that I'm saying it's how it should be done -- could be done with layering another element. 23:17:00 fantasai: But you need to put margins on 3 sides of both things... could get hairy with arbitrary children. 23:17:05 Tab: Subgrids good for this kind of case 23:17:36 fantasai: Subgrids work: if I want to position item into a grid... look at children and see how many cells spanning ... 23:17:42 fantasai: [draws] 23:17:56 fantasai: take up this many slots in the parent grid 23:18:15 fantasai: From children's perspective, this is the numbering system, but for parent and numbering system *this* is the positioning system. 23:18:37 fantasai: children affect sizing of parent grid, except extra margin added to items to account for subgrid's margin/border/padding 23:18:46 fantasai: That's the idea, and it would solve this problem. 23:18:55 Bert: I don't understand how it solves this problem. 23:19:12 fantasai: you'd give the li { display: subgrid }, li would be a grid item inside this grid; the label and the input would be grid items inside the subgrid 23:19:26 fantasai: the items in the subgrid participate in the parent grid, so [points at drawing] 23:20:00 Peter: I'm not sure why you need to create the level of subgrids -- couldn't the li be placed in cells and its children be placed in other cells? 23:20:12 fantasai: The children would then need to know the grid position of its parent 23:20:19 Peter: So its grid coordinate system is relative to its parent 23:20:26 Steve: consttraining th erange of auto fill 23:20:40 Steve: In some sense you're making grid items out of the children, but there's more to it than that. 23:21:11 fantasai: You're scoping their positioning, and you're taking the distance between margin and content edge of the parent and using it to change the size of the grid cells the items are going into so they stay inside each other geometrically. 23:21:43 fantasai: As Phil said, you can do the same thing manually by manually computing the right positions and the right extra margins on the items. But you have to track row/column and amount of margin. 23:22:03 Steve: I'm unclear how the border gets done 23:22:09 fantasai: you just put a border on the li -- it's there 23:22:11 Steve: ah, ok 23:22:24 Phil: So if everybody understands that -- back to the original question 23:22:32 Phil: So Tab wants to see it in level 1. 23:22:43 Phil: The more we try to solve in level 1 the further it is from being stable 23:22:55 Phil: We'd like to have a version of the spec to point to that reflects what we have in the marketplace 23:23:16 Tab: I'm fine with subgrid being in level 2. I don't think it's required for basic grid functionality. But I think being able to pull descendants out for your grid is necessary functionality. 23:23:37 Tab: ... there are required or recommended markup patterns in HTML that prevent you from flattening children 23:23:46 Phil: [missed] 23:24:01 Phil: ... could solve it in another way... what do we do with the semantic markup, maybe a mechanism for hiding it or something? 23:25:19 s/[missed]/I was coupling the subgrid solution fantasai proposed with the solution for what we do with the solution for leftover semantic markup, and I'm hearing Tab say we could defer subgrid and find other solutions for the semantic markup/ 23:25:33 fantasai: I'm not sure I'm comfortable with that 23:25:42 Phil: I'm not sure what that solution is; could take an action item 23:25:49 Phil: I'd prefer not to tie that to level 1 at all. 23:26:08 fantasai: Not sure if I full-on object to that, but afraid people will do bad things to their markup. 23:26:19 Tab: subgrid or descendants being pulled in? 23:26:29 fantasai: pulling good; concern is about subgrid 23:26:47 fantasai: Concern about people doing weird things to their markup to make alignment happen, impact a11y etc, bad markup practices. 23:27:05 Phil: To be clear, I was talking about pulling descendants as a whole. 23:27:29 fantasai: I think that's something you can't turn on in the future because it would break existing content because of random grid positioning properties on descendants. 23:27:45 fantasai: Could create a positioned-grid value required to pull descendants and turn it on that way 23:27:53 tab: I'm concerned about contortion of markup patterns 23:28:18 tab: I think the solutions to do pulling desceendants without subgrid are hacky on CSS side but won't encourage contortion of markup 23:28:22 fantasai: I think they both will 23:28:31 Phil: What about flexbox? 23:28:41 fantasai: We didn't have use cases for pulling descendants into the main flexbox 23:28:46 q+ 23:29:04 Tab: can also address all of those use cases by making the wrapper a flexbox as well... and that's not true of grid 23:29:12 fantasai: because of the laignment across both dimensions 23:29:13 q- 23:29:31 Phil: ok, so we're resolved to continue pursuing descendant solution, but not requiring subgrids as part of that solution? 23:29:34 Tab: That's what I want? 23:29:39 fantasai: I want to hear from other people 23:29:41 s/?/./ 23:29:42 myakura has joined #css 23:29:56 Steve: Weak approx to subgrid called honor-descendants 23:30:13 Steve: Have to explicitly say I want to say descendants positions should be interpreted, but I don't get extra mechanisms of subgrid 23:30:20 Tab: That solves problem of stray grid positioning 23:30:34 Tab: But it doesn't solve problem of people having to distort their markup right now to flatten everything into being children of the grid 23:30:40 Steve: I thought I'm turning it on so I didn't have to flatten. 23:30:45 Steve: Treat my children as being me. 23:30:50 Tab: So you're saying do that right now? 23:31:00 Steve: I'm saying to do that right now is a way of doing the descendants thing. 23:31:22 Tab: I don't think we have a problem with needing to be explicit right now. The reason to need to be explicit is if we're delaying it for the future. 23:31:30 Bert: why need a property at all? 23:31:41 Florian: We only need it if we introduce it later, and thus it needs to be opt-in 23:31:46 Bert: but the default should be on 23:31:48 Tab, Florian: yes 23:31:54 Steve: But it doesn't interact with subgrids? 23:32:17 Tab: We can patch this by saying that if a particular descendant wants to escape out -- still future-friendly for subgrid. 23:32:43 fantasai: I don't dispute that -- my concern is markup on whiteboard (input/label) -- people want to put border around input/label pairs -- and have that markup structure, e.g., for non-CSS reasons. 23:32:52 fantasai: Fact that we can't handle that right now without really being hacky 23:33:01 Bert: As long as you don't want image borders...normal borders you can do. 23:33:09 Bert: 3 borders on left cell and 3 borders on right cell 23:33:17 fantasai: label inside there... input has its own borders 23:33:28 Tab: People could hack it into working just with CSS 23:33:39 Tab: What are you concerned people will do to their markup to help that. 23:33:42 s/./?/ 23:33:53 fantasai: Not sure, but I think it would be pretty ugly. 23:34:32 Bert: Another worry with subgrid: if you suddenly take margins into account,things don't line up anymore. The label is no longer left-aligned to the frist grid line because there's a margin in-between. So if it's 100% it's 100% of something else -- the left over space -- not the grid. 23:34:45 Tab: The leftover space, given the grid and the extra margin. It will still work as long as we define it correctly. 23:34:56 Bert: I think it will be difficult to design because of subtracting margins. 23:35:05 fantasai: If you didn't want the space then you wouldn't put any padding there 23:35:24 Bert: But you're already putting the label within a grid cell, so you'd expect it to line up with the grid cell and not be influenced by something else. 23:35:46 Tab: As long as we craft the spec correctly, we can all make it work correctly -- even if you're pushed in on the left your right edge will still line up with the grid. 23:36:50 ... 23:37:10 dbaron: I think what Tab is saying that is if you didn't want the subgrid to cause things to not be lined up with the parent grid, then don't put margins/borders/padding on it 23:37:14 dbaron: And then it will ine up 23:37:21 dbaron: But if you do put margin/padding/border, we honor them 23:37:41 Bert: it works out -- but you're assigning things to the same grid column and they don't line up. That's confusing. 23:37:47 Tab: That's the actual functionality of subgrids. 23:38:00 Steve: If you don't put margins on the li, then it lines up. 23:38:02 Tab: yes. 23:38:15 Steve: You have the option of getting more indent. 23:38:49 fantasai: I think we should resolve on doing descendants going up into grid, mark subgrid as something to think about. 23:39:32 RESOLVED: descendants of grids can be positioned into the grid as part of Level 1, mark subgrids as an issue to think about 23:39:52 fantasai: Do we want to have that happen with position:grid, or just happen if your row or column is non-auto? 23:40:04 Tab: Oh, key it to something else like position:grid? 23:40:18 Phil: I think I like the row-or-column-is-non-auto. 23:40:34 Phil: Sorry, I think we'd need to introduce new value like none for grid-row or grid-column 23:40:50 Tab: You want most of your descendants to not do anything special 23:40:53 fantasai: Initial value would be none. 23:41:22 Phil: For chlidren of grid, in anonymous default grid item, would need to give them grid-row/column: auto 23:41:43 fantasai: Disadvantage: If you want to turn on auto positioning you'd need to turn those all to auto *and* turn on auto positioning 23:41:51 Tab: alternative is to make nonen compute to auto for children of grid 23:41:55 varous: no 23:42:07 s/varous/various/ 23:42:10 s/nonen/none/ 23:42:28 fantasai: so looks like either we can have descendants be positioned into the grid if they're non-auto row/col, or we can have auto-positioning be a single switch, but not both 23:42:37 fantasai: so we need to think about that 23:43:06 Steve: Had a question about default cell: why do you want to throw away the content if it's group into this default ...? 23:43:11 fantasai: I don't think we want to do that. 23:43:20 Tab: I just think we may want to allow you to throw away the content. 23:43:33 Tab: I'd prefer if it didn't make anything disappear until you actually position some children. 23:43:37 Tab: need to make sure that works properly 23:43:53 Bert: More generic problem there: in many cases there are things you want to throw away even though the children of the thing should still be displayed 23:44:09 Bert: We might want to have something that throws away everything except things that really want to be displayed. 23:44:14 Bert: useful for collapsing lists 23:44:24 fantasai: visibility:collapse but done right? 23:44:46 Phil: Next issue is the shorthand naming. 23:44:54 Phil: We added a bunch of new shorthands into latest ED. 23:45:32 Phil: I think we're pretty happy with names -- discussion about what used to be grid-rows and grid-columns -- now grid-definition-rows and grid-defintion-columns -- to make them more distinct from grid-row and grid-column. 23:45:41 Phil: Some suggestion of grid-row-tracks and grid-column-tracks instead 23:45:46 Phil: suggestions? 23:46:01 Tab: I agree with renaming -- grid-row vs. grid-rows was bad. 23:46:07 Tab: Not super-happy with grid-definition-rows 23:46:31 Phil: Recommended process for resolving on names? 23:46:42 q+ to suggest grid-columns and grid rows for definitions, grid-area for positioning. 23:46:43 fantasai: Brainstorm for a bit, straw poll. If nothing good, try again later? 23:46:53 ack Bert 23:46:53 Bert, you wanted to suggest grid-columns and grid rows for definitions, grid-area for positioning. 23:47:05 Bert: grid-columns and grid rows for definitions, grid-area for positioning 23:47:16 Tab: I think grid-area is shorthand for all 4 at once 23:47:24 Bert: Could say there are no individual property and just use shorthand. 23:47:35 fantasai: I think there are use cases for longhand, esp. with auto positioning. 23:47:45 Tab: [rapidly-described use case combinatorics] 23:47:53 Bert: They always have an x and a y position anyway. 23:48:00 Tab: I think it's useful to do x and y separately. 23:48:04 Tab: e.g. say all of these are in this column, this one's in this row, that's in that row, the other's in the other row 23:48:09 Steve: Instead of putting extra word in the definition, put it in the use? 23:48:19 fantasai: Problem with that is that it's the one you're going to type the most. 23:48:23 Bert: I think that's not the case. 23:48:32 Bert: I think you're going to use the positioning less than the definition. 23:48:44 Bert: Most grids will not be used with positioned elements not elements that are flowing. 23:48:51 Bert: So you don't need explicit x and y wery often. 23:48:55 Tab: Don't know about this. 23:49:18 Tab: I think that resaonably commonly -- grid-area works -- but still quite reasonable and reasonably common to do x and y positions separately. 23:49:30 fantasai: Another position was grid-template-rows/columns/slots for the template. 23:49:50 Bert: I like shorthand shorter: grid not grid-template. 23:49:59 Tab: Nice ideas, make sure they get pulled into brainstorming thread. 23:50:08 Phil: There was a side discussion during break, with tab fantasai peter steve bert. 23:50:25 Phil: Did you settle on something? Did you decide to remove named lines? 23:50:50 Steve: There were 2 decisioins I could recall. Nobody was in favor of curent syntax, but were in favor of model. Discussion about whether that meant to remove syntax or not. 23:50:56 Steve: Consensus that syntax improvement was needed. 23:51:16 Tab: One of us should put together beter syntax for name dlines 23:51:45 Steve: peter gave an example of usage of lines that acts as illustration of issue Peter actioned to work on: being able to delete a named line and having the positioning default in a useful and predictable way. 23:52:08 Steve: ... so that you can do media queries to set up grid and where the lines fall fall out in a natural way, and you don't have to rewrite a lot of your code for each media queries. 23:52:12 Phil: ok, I think I heard those 23:52:31 Tab: Useful part: can we remove the current syntax because we're going to do better and soon? 23:52:44 Steve: If we can come up with something in aweek we'd certainly put the new syntax in. 23:52:57 [Tab still wants the old syntax out, but gives in] 23:53:06 Phil: I'm just going to wrap up with status: 23:53:15 Phil: ... updates recently to grid. Template property now taking identifiers. 23:53:28 Phil: ... automatic placement algorithm updated based on discussion with fantasai -- forward only, no backfilling 23:53:32 Phil: ... new shorthands just mention 23:53:43 Phil: ... next steps: editors work on descendant piece, work on gutters 23:53:57 Phil: ... not sure if this was implied -- we also plan to pull in column/row-rule with column/row-gap 23:54:05 Phil: ... and issues in bugzilla we'll start working on. 23:55:09 .... 23:55:20 Discussion of what to discuss 23:55:29 jdaggett: We would like to not ship this prefixed. 23:55:37 Tab: Neither do we 23:55:58 jdaggett: So we should keep this to the absolute minimal spec, because whatever's there, we won't have a chance to fix anything 23:56:08 Florian: Can we decide on what we're talking about first? 23:57:11 discussion of scheduling constraints 23:58:25 and how long to discuss prefixes 23:59:14 Topic: Variables 23:59:19 Tab: I can do variables in half hour! 00:00:53 Tab spends half an hour erasing the board. 00:00:55 (j/k) 00:01:06 Tab: Question is what features to preserve in the draft and how to call them 00:01:12 Tab: Right now variables are created witha property 00:01:16 Tab: Few different ways to handle this 00:01:33 Tab: Right now they're declared as property declarations. 00:01:38 Tab: property name options 00:01:39 var-foo 00:01:41 $foo 00:01:42 my-foo 00:01:44 user-foo 00:01:48 Tab: 3 ways to use a variable 00:01:54 Tab: prop: $foo 00:02:12 Tab: prop: var(foo [, fallback]) 00:02:18 Tab: use var function with optional fallback 00:02:29 Tab: Option to do something when var isn't defined or is invalid, very useful functionality 00:02:34 Tab: other function is parent-var() 00:02:43 Tab: which does the same thing, but checks the variable value on your parent 00:02:52 Tab: Less than 1 week ago would suggest moving to $foo 00:03:04 Tab: Now I don't, because I think there's some interesting solutions 00:03:14 Tab: partially due to dbaron's selector idea and some conversations with fantasai 00:03:37 Tab: So think we should not go with $foo syntax 00:03:56 Tab: I want to do something like SASS's extend, or what dbaron proposed, which needs a very compact thing 00:04:03 Tab: This why I don't want to use that syntax right now 00:04:12 Tab: I want to leave us with these two functions var() and parent-var(), as written 00:04:25 Tab: and keep what's there for var declarations 00:04:31 Tab: maybe one of the other options suggestion 00:04:35 Florian: I'm happy with this proposal 00:04:45 jdaggett: When you're using the variable, what's the syntax 00:04:56 Florian: That was the way initially proposed to the group 00:05:01 Rossen: it's good 00:05:33 fantasai: I think it's good that the basic use is consistent with the more complex uses 00:05:46 jdaggett: I don't like the syntax, but $foo keeps the stylesheet a lot more tight 00:05:56 Molly: People are already familiar with $foo 00:06:02 jdaggett: It also causes confusion because it's a shell variable 00:06:10 jdaggett: But having compact notation is important 00:06:16 Tab: I think that's a decent argument against it 00:06:27 Tab: Because in preprocessors, it behaves very differently 00:06:34 Tab: In SASS etc. they are pretty much macros 00:06:48 Tab: They're global variables, can do replacement anywhere for anything 00:07:01 Tab: I think we want something similar to what SASS etc. do, but this isn't that 00:07:14 Florian: Our variables are different, so we shouldn't match their syntax 00:07:24 Tantek: Heard request from jdaggett for fully-written-out examples 00:07:28 Tab: i nthe spec 00:08:05 glazou: Last time we mentioned $foo, someone mentioned ppl behind the processors were willing to change their own $foo if we were ready to accept it for CSS 00:08:09 Tab: That's still the case 00:08:14 glazou: So why don't we use $foo 00:08:19 Tab: First of all, they can't match us entirely. 00:08:27 Tab: They can only do so in restricted cases, would be very confusing 00:08:39 Tab: You can't do it without severe hacking 00:08:57 Florian: They can change their syntax to match or not match ours. They can't change their behavior to match ours. 00:09:19 fantasai: Because we use the cascade and inheritance, and they do simple string substitution 00:09:47 plinss: That only saves us collision with SASS. Doesn't save us the confusion in minds of authors. 00:10:09 Florian: None of the existing languages that use $foo for denote variables ... 00:10:22 glazou: We still need a way to express parent-var, and with $ you can't 00:10:32 Tab: I want to reserve our use of $ for something similar 00:10:52 Tab: Where you can do variables for Selectors, and there a very short glyph-based thing like $foo is necessary, whereas less necessary in CSS value 00:11:19 Florian: I think we're going to take some flames for it, but we should go this way 00:11:42 Tantek: I'm going to go with your recommendation, and publish with that, and if it really is that objectionable to the authoring community we will hear about it very loudly from them. 00:11:52 Tantek: I'd rather have that debate there than here. 00:12:05 Tantek: Let's go with your judgement, and if authoring community has unified force against that, they we can reconsider. 00:12:14 szilles: Besides, you can always use SASS to replace the $foos. 00:12:48 fantasai: I agree with Molly that we need a very clear blog post explaining why we are deciding this way 00:13:16 jdaggett: I think it is important to talk about thie inheritance model 00:13:31 jdaggett: It needs to be in the forefront that this is not a macro replacement mechanism. 00:13:34 Tab: Cool 00:13:44 Tab: In the FPWD, all we had was var-foo and var(foo) 00:13:52 Tab: We couldn't specify fallback, and didn't have parent-var() 00:13:59 Tab: Are these acceptable in Level 1 00:14:13 Tab: They could be deferred, but are sufficiently simple and useful that could be part of Level 1 00:14:33 jdaggett: I really think for this level, since we aren't going to be behind a prefix for X months, we should keep this to a minimum. 00:14:44 jdaggett: In particular I don't like parent-var(), because it feels like an experiment 00:14:55 jdaggett: The things it's useful for, might be better ways to do it. 00:15:08 jdaggett: I think there's going to be little pockets of places where it will be difficult to get interop 00:15:26 jdaggett: I'm not saying I oppose the feature, but for Level 1, get the simplest functionality out there 00:15:35 Tab: I'm ok with deferring parent-var(), but really want to keep fallback 00:15:55 glazou: How about add a note explaining parent-var(), as "in the future we may consider this" 00:16:15 dbaron: So, I sortof have mixed feelings about this 00:16:23 s/this/dropping parent-var/ 00:16:30 dbaron: on onehand, I'm not crazy about the name parent-var() 00:16:40 dbaron: On the other hand, it seems trivial to implement once you have all the rest 00:16:49 dbaron: Although maybe I'm missing something 00:16:54 glazou: I think you're right it is very simple 00:17:06 glazou: I think web authors using variables will need more, parent-var() is only the first step 00:17:17 Tab: On one hand I have several use cases really awesome for parent-var in the spec 00:17:27 jdaggett: There may be many example,s but maybe that's not the right set 00:17:36 jdaggett: If we stake a claim on parent-var, everything else has to fit in 00:17:48 glazou: If it's simple to implement, can do Level 2 in a snap 00:18:01 Tab: ... grab property value from the parent and use the value in your stuff 00:18:08 dbaron: that's a can of worms 00:18:28 Tantek: I hear what you're saying, John, but rather than entertain that as a hypothetical possibility, invert that into a challenge 00:18:35 Tantek: Provide the use cases for other possibilities 00:18:48 Tantek: I think we should include it based on commentary that has been made 00:18:55 jdaggett: Keep in mind this is not prefixed 00:19:08 tantek: 2nd, we have a notion of variables in one place, which is the font-size 00:19:17 tantek: You can refer to font-size of yourself or parent in a few places 00:19:33 tantek: Nobody's come and said "I want font size of grandparent" 00:19:39 dbaron: we have rem now 00:19:51 Tantek: but probably safe to go with just parent-var 00:19:57 Florian: I say we go with L1 without parent 00:20:05 Florian: Then make a L2 quickly that just has parent 00:20:34 Florian: have the discussion about parent-var there 00:20:39 tantek: ... 00:20:47 jdaggett: This is going to spread like wildfire once it's implemented 00:21:17 Tab: I'm fine with this. Fine with doing small drafts that advance quickly. 00:21:32 glazou: Tantek, I would agree with you if it was going to take awhile, but this is small and fast 00:22:26 RESOLVED: Syntax of variables settled on var-foo and var(foo) 00:22:46 ACTION: TabAtkins, fantasai, and glazou to write blog post explaining why not using $ 00:22:46 Sorry, couldn't find user - TabAtkins, 00:23:00 RESOLVED: Include fallback in Level 1 00:23:10 RESOLVED: Defer fallback to Level 2 00:23:46 RESOLVED: Accept Variables L2 with parent-var() as work item 00:24:07 fantasai: I don't think we should go to LC yet; want to get a few weeks of feedback in response to this WD. 00:25:15 jdaggett: I want that sentence changed. He knows which sentence. 00:25:52 RESOLVED: Publish WD of CSS Variables providing sentence jdagget objects to is removed. 00:27:17 plinss: Who is building a test suite for Variables? 00:27:24 jdaggett: dbaron has already started 00:27:39 Tab: I'm going to expand that more, because I need to write test suites for 3 different specs I'm in charge of 00:29:37 s/Defer fallback/Defer parent-var/ 00:30:19 Meeting closed. 00:30:49 $ hg ci -m"Switch syntax from $test to var(test)." . 00:30:56 summary: Switch syntax from to var(test). 00:43:57 tantek has joined #css 00:47:51 jdaggett has joined #css 01:03:43 pcupp has joined #css 01:30:20 myakura has joined #css 01:45:20 arronei_ has joined #css 01:53:02 glenn has joined #css 02:10:07 jet has joined #CSS 02:27:39 pcupp has joined #css 02:38:38 jet has left #CSS 02:46:34 jet has joined #CSS 02:53:42 glenn has joined #css 03:05:46 tantek has joined #css 03:23:15 leaverou has joined #css 03:27:49 shepazu has joined #css 03:30:50 myakura has joined #css 03:54:18 glenn has joined #css 04:38:29 arronei_ has joined #css 04:45:26 tantek has joined #css 04:49:15 miketaylr has joined #css 04:54:58 glenn has joined #css 05:31:08 myakura has joined #css 05:40:46 dbaron has joined #css 06:07:41 drublic has joined #css 06:50:01 glenn has joined #css 06:50:19 Ms2ger has joined #css 07:03:12 tantek has joined #css 07:31:34 myakura has joined #css 07:57:49 drublic has joined #css 08:49:21 glenn has joined #css 09:00:06 jarek has joined #css 09:05:07 macpherson_ has joined #css 09:15:43 macpherson__ has joined #css 09:17:59 macpherson_ has joined #css 09:28:39 macpherson__ has joined #css 09:32:02 myakura has joined #css 09:50:06 glenn has joined #css 09:53:36 myakura has joined #css 10:50:44 glenn has joined #css 11:06:20 leaverou has joined #css 11:12:05 decadance has joined #css 11:51:23 glenn has joined #css 12:28:40 Zakim has left #css 12:29:19 shepazu has joined #css 12:39:10 leaverou has joined #css 12:52:03 glenn has joined #css 13:26:11 myakura has joined #css 13:52:43 glenn has joined #css 14:00:57 jet has joined #CSS 14:05:06 arronei_ has joined #css 14:10:26 miketaylr has joined #css 14:11:38 miketaylr has joined #css 14:21:36 jet_ has joined #CSS 14:46:01 jet has joined #CSS 14:46:47 glenn has joined #css 14:47:29 tantek has joined #css 15:03:52 krit has joined #css 15:23:28 jet_ has joined #CSS 15:32:26 jet has joined #CSS 15:42:21 dbaron has joined #css 15:51:04 florian has joined #css 15:52:51 glazou has joined #css 15:53:01 Zakim has joined #css 15:53:21 RRSAgent, make logs public 15:53:29 rrsagent, this meeting spans midnight 15:55:32 glenn has joined #css 15:56:46 lstorset has joined #css 15:59:19 SteveZ has joined #css 16:00:31 TabAtkins_ has joined #css 16:01:47 cabanier has joined #css 16:10:01 ScribeNick: TabAtkins_ 16:10:42 Topic: Prefixing Policy 16:10:46 Topic: Prefixes 16:11:13 dbaron: I thinkt he first thing is that we shouldn't think of it as a prefixing policy, but rather as an "experimental features" policy. 16:11:22 dbaron: Because the right solution may not involve prefixes. 16:11:28 Topic: Experimental Features Policy 16:11:35 florian: Two rpoblems with the current policy. 16:11:42 florian: There's no clear good way for authors to use it. 16:11:50 florian: And not even just clear - I think there's no good way at all. 16:12:05 florian: A common "best practice" is to list all the vendors followed by the unprefixed, which lets you write your site and forget about it. 16:12:13 florian: This matches most author's workflow. 16:12:20 sylvaing: Until we renamed things. 16:12:28 florian: Yeah, but if we dont' change things, that works. 16:12:41 tantek: I think your first statement was flawed. 16:12:58 tantek: I think that "making it work" isn't necessarily something the WG should be committing to, if it's experimental. 16:13:17 florian: There is no good way to use these, so people use them in bad ways. 16:13:35 glenn: Modernizr helps make this less painful, right? 16:13:47 tantek: This is why I think that David's way of reframing the problem is useful. 16:14:03 florian: the things that we consider "experimetnal" are being used. 16:14:24 florian: And with the current way we prefix things, there's no good way to use it, thus they do it in bad ways. 16:15:01 glazou: Note that when browsers introduce a new experimental feature, they don't say it as an "experimental" feature - it's just a feature! 16:15:17 glazou: "Now you can do border-foo!" 16:15:19 sylvaing: Authors are using it because it's in production releases 16:15:33 florian: This is true, but I think we should be careful about drawing conclusions from it. 16:15:38 tantek has joined #css 16:15:56 florian: If we refrain from shipping too many half-ready things, we get around the issue, but we harm the competitivity of either the browsers doing it, or the platform as a whole. 16:16:54 tantek: I think that Daniel's point is important, and calls to attention that we don't just have experimetnal features, we also have vendor-specific features, that are being shipped. 16:17:03 krit has joined #css 16:17:11 tantek: And the vendors are saying "you can use this, because we will support this". And this is a different class of problems. 16:17:22 sylvaing^: Is it really experimental if we have multiple browsers shipping interoperable implementations? 16:17:34 tantek: Sometimes vendor-specific features are loved by we bauthors and then the WG has to figure out how to spec it, and that's similar to experimental, but usually they're separate. 16:18:09 florian: I want to be careful about calling these things "vendor-specific". If apple introduces something that is meant to write the UI of itunes, or Moz introduce something meant for the UI of Firefox, etc., this is vendor-specific. 16:18:39 florian: But if you write a feature that you have no particular intent to share with other brwosers, but you serve it from arbitrary web servers to arbitrary brwosers, this is not vendor-specific. 16:19:03 florian: Opera has no reason to try and implement the things for iTunes, but it needs to implement the things used on iPhone, because they're exposed. 16:19:22 tantek: I think that problem has been previously characterized as "once you'veleaked it to the web". 16:19:40 hober: canvas, for instance. 16:19:46 tantek: Once you've leaked it, you can't take it back. 16:19:58 florian: For those things that aren't meant to hit the web at all, it's fairly easy to define the policy for them. 16:20:23 hober: A bit difficult, because there may be an initial use for a proeprty - it's specialized for a certain client - but after they work with it, it turns out to have general applicability. 16:20:36 hober: So I think it'll prove difficult to use a different mechanism for the two cases. 16:20:51 florian: I think that if something's not meant for the web, it just shouldn't be exposed to the web at all. 16:21:10 florian: If you later think you should expose it to the web, you can flip that switch later. 16:21:28 florian: If you have a context switch that lets you hide it from the browser when it's in "web mode", we'd avoid a lot of issues. 16:21:45 florian: They should probably be prefixed, to avoid accident collisions with WG stuff. 16:22:12 glazou: I'm not sure there's a firm line. Standalone web apps are becoming more prevalent. Nobody knew initially that iTunes was built in web stuff. 16:22:13 Of course, vendor-prefixed properties get created for several different purposes. see https://lists.webkit.org/pipermail/webkit-dev/2010-July/013534.html 16:22:49 glazou: Hiding stuff behind a pref isn't going to happen, or only for a few months until the standalone app is turned into a web app. 16:23:11 glazou: The proprietary CSS extensions we know of, only the ones designed for *very specific* things, like for MS word, don't eventually hit the web. 16:23:29 dbaron: There are plenty of vendor-prefixed things that haven't taken off. 16:23:43 glazou: Sure, but these are the no-question things. Others, vendors may at least consider it. 16:23:57 tantek: What do you mean by "things for ms word dont' eventually hit the web"? 16:24:08 glazou: The -mso- stuff never even considered to hit the web. 16:24:26 tantek: You can find tons of mso prefixes on the web. 16:24:38 glazou: Yes, but no one ever implemented them, or even intended to. 16:24:58 florian: I think you're not disagreeing with me - if you create mso or itunes things, and you initially isolate them... 16:25:16 florian: If someone else realizes they're not specialized and would be generally useful, someone can bring them to the WG. 16:25:25 glazou: *If* someone brings them to the WG. People don't do that. 16:25:51 jdaggett: About the mso stuff, that's just "gluck". The presence of a prefixed property in public isn't indicative that it's meaningful. 16:26:19 karl has joined #css 16:26:33 TabAtkins: a problem you brought up is that we are making things exposde to the public without bringing them to the WG 16:26:47 sylvaing: Can't do it. 16:26:52 glazou: It's a problem of strategy. 16:27:20 RRSAgent, pointer? 16:27:20 See http://www.w3.org/2012/08/13-css-irc#T16-27-20 16:27:22 sylvaing: People have public bits they don't want to expose. 16:27:53 TabAtkins_: That means that browsers are using the web and the WG as a means to bless their actions after they've blasted the web, so they retain first-mover advantage. 16:28:04 Rossen has joined #css 16:28:09 leif: The WG can bring things up on their own, yes. 16:28:28 sylvaing^: It's a matter of corporate disclosure 16:29:07 sylvaing: Sometimes it's not even mentioned. There are things in W8 that aren't even mentioned - just using CSS. 16:29:19 jdaggett: Some of these are proprietary proeprties - not really intended to be part of CSS. 16:29:27 jdaggett: And that's part of the problem. Authors dont' see that distinction. 16:29:53 jdaggett: Many marketing departments - there's a tendency to take feature X with a prefix on it and say that it's part of CSS3, even if the only thing that backs that up is a blog post or a private draft. 16:29:59 s/mentioned/submitted yet 16:30:33 florian: MS has probably extended CSS to make Metro UIs possible. Some of these features may be intended for the WG later, but not yet ready; others may not be intended for the web at all. 16:30:45 florian: For the ones not intended for the web at all, I say just dont' expose them at all. 16:31:06 florian: For the others that you intend to be on the web, it would be useful to ship them (because you have to), but not expose them to the web. 16:31:21 florian: This is similar to iTunes, and other types of things. 16:31:38 florian: So what happens when you actually expose things to the web. 16:32:42 florian: As long as you don't, you should have them prefixed, so that whatever ends up on the web (a standardized version of it, or something independent with the same name), we don't get name collisions between these two. 16:33:03 florian: Which the web doesn't care abuot, but the private app would stop working if a same-named feature started doing something else. 16:33:22 szilles: So I think you're saying that we own the unprefixed space, and anyone else must prefix. 16:33:46 florian: I think whether or not random people introducing random things to the web should or shouldn't prefix is a separate question. 16:33:58 florian: But for the things that *aren't* meant for the web, don't expose them, and prefix them. 16:34:35 glazou: Again, I think the idea to "don't expose them to the web" is unworkable. More apps move to webapps. 16:34:50 glazou: I don't think it'll happen. Browsers will want to expose them to the web sot hey can write webapps. 16:35:28 plinss: I think it's reasonable for webkit to understand epub stuff, but only when reading epub files. Not when doing normal web content. 16:35:47 glazou: When I'm downloading a random epub file from the web, should it or not render epub properties? 16:36:03 florian: If you can recognize it as epub... 16:36:13 glazou: There's no difference between epub and a random html file. 16:36:40 jdaggett has joined #css 16:36:41 hober: I think it's unreasonable to expect epub authors to have a different workflow than regular html workflows. 16:37:08 plinss: If it cant' tell, it can't tell. But if it can tell one way or the other, do or don't respect epub properties. 16:37:22 glazou: I don't think that's reasoanble. Right now on the web you have some epub readers. They're just webapps. 16:37:32 jdaggett: You're advocating a bad idea. 16:37:52 glazou: Not advocating - describing. 16:38:27 jdaggett: You're saying that any group that wants to create their own flavor of HTML or CSS, those things are their own entity. Whether any particular UA shows it in the way that's intended is a private matter. 16:38:37 szilles: Browsers aren't the only thing that can display web content. 16:38:46 szilles: They may accept different things than what the browser accepts. 16:38:58 szilles: If those other things become popular enough, there may be pressure to adopt what they do. 16:39:17 szilles: So I'm hearing daniel say that it's a market force that we cant' do anything about. 16:39:37 sylvaing: In W8, we try to have a clean separation between web and app. 16:39:55 sylvaing: But quickly, the Facebooks and Netflixes of the world, just build an app with a web container. 16:40:10 sylvaing: And quickly they want the full set of things that apps can do. 16:40:29 Koji has joined #css 16:40:32 florian: But at that point we get to the point where you're deciding that things are appropriate for the web, not just for siloed content. 16:40:42 jdaggett: I think the epub process is a perfect example of how we should not try and act. 16:41:03 jdaggett: Where you take a laundry list of features that someone says they want, and stick it into a document with no attempt to distill or worry about interactinos or do the hard work. 16:41:36 tantek: Regarding epub - I think they're a great example of the *reality* tha other groups will try to extend or fork the web platform. 16:41:59 tantek: Before epub we had chtml, though that's an example of something that died. 16:42:03 tantek: Other groups will try to extend. 16:42:15 tantek: We can try to outcompete them, or we can get outcompeted. 16:42:30 glazou: Epub is a nice extensions because they have public documents detailing everything. 16:42:46 hober: epub tried to track us as well as they could, given our schedule, and they tried to be good actors in this case. 16:42:49 glazou: yes, it's a good case. 16:42:57 glazou: It's not the best thing to do, but they tried to do good. 16:43:18 dbaron: They had a schedule, and no intention of putting in enough resources to meet that schedule properly. 16:43:29 szilles: I think it's important that such experiments are identified as such. 16:43:50 szilles: But I think we should adopt a "fast follow" appraoch, so that when something looks important, we can produce a similar version of it. 16:44:16 szilles: Not necessarily idetnical - one of the problems with the fast actors is that they often don't think about interactions,w hich slows us down. 16:44:35 jdaggett: It isn't just a matterof slow and burearcratic, as tantek puts it - it's just a damned hard problem. 16:45:01 glazou: It can be fast and agile and not disclosed because of competitive reasons. 16:45:18 tantek: Often burearcracy and process has gotten in our way historically. 16:45:24 tantek: We're aware of and trying to fix that problem. 16:45:59 jdaggett: Prioritization si crucial. 16:46:17 jdaggett: If we aren't prioritizing the right thing, if we're spending lots of time on exotic things here an there, that's a problem. 16:46:24 florian: I think it magnifies the problem - it's not a root cuase. 16:46:53 szilles: I think making it possible for us to do fast follow is how we should address this problem, not changing the way we identify things. 16:47:07 szilles: How we label is a red herring. 16:47:12 smfr has joined #css 16:47:13 plinss: It alleviates some of the pressure. 16:47:27 plinss: There's no disagreement in the group that thigns come up that we need to work on more aggressively. 16:47:54 glazou: From my perspective the problem is about getting the technical information about a property impld by one of the members and not yet disclosed, such as text-size-adjust. 16:48:05 tantek: People brought up a bunch of examples. 16:48:21 fantasai: Examples: text-size-adjust was not disclosed and became super-popular 16:48:38 fantasai: border-radius, microsoft's grid layout proposal... 16:48:50 fantasai: Looking at different ones of these, you'll make different suggestions about what's best. 16:49:01 fantasai: border-radius - why have prefixes? We all did the same. 16:49:18 fantasai: grid layout - if MS shipped what they had unprefixed, we'd have had no chance to fix the problems in it. 16:49:30 fantasai: So we shouldn't focus on justone of these problems, we should look at all of them. 16:49:36 fantasai: Like T&A is more of a border-radius case. 16:49:51 tantek: More general examples. 16:49:59 tantek: There was the UI example - UI of iTunes or Firefox. 16:50:20 florian: Slight break - we don't all agree on the exact details of the problem, but we all have a shared idea of what it is generally. 16:50:36 florian: So rather than get the details more, let's talk about solutions and see if it turns out good. 16:50:43 fantasai: Starting proposal! 16:50:45 fantasai: Section A. 16:50:58 fantasai: If it's not web-ready, ship it prefixed and don't expose it to the web. 16:51:04 Section B. 16:51:13 fantasai: For standards-track features, ship only in non-release builds. 16:51:29 fantasai: ...unprefixed. 16:51:59 fantasai: If another browser ships a release and we have some level of good interop and we think it's a good idea, everyone ship as release. 16:52:35 dbaron: The way another browser "ships a release" is by breaking these rules in the first place. 16:53:04 fantasai: If three browsers total implement (non-shipping) and we have interop and think it's a good idea, everyone ship. 16:53:40 fantasai: Maybe if it's not a solid spec and we dont' have a testsuite, but we're still forced to ship, ship both prefixed and unprefixed so authors can turn things off that are broken in a particular impl. 16:53:57 glazou: This does not solve the text-size-adjust problem. 16:54:37 szilles: What problem does this solve? 16:54:56 TabAtkins_: The bit where we have multiple prefixed versions living for a while and making authors lives hard. 16:55:21 szilles: In order to do that, you still need a test suite and therefore why not go through the process we have now. 16:55:48 florian: If you want to test *strict* interop, you need a test suite. If you just need a rough idea, you don't need that - subjecive judgements are possible. 16:55:49 q+ 16:56:24 ack tantek 16:56:30 tantek: Response to steve - what we ahve seen with T&A&transforms, these exampels have disproven your statement. 16:56:43 tantek: In practice, we have not needed a testsuite to get itnerop, as evidenced by author adoption. 16:56:58 tantek: if they weren't "sufficiently interoperable", authors wouldn't be using them so much. 16:57:03 tantek: This is a pretty strong bar. 16:57:23 glazou: "perceived interop", not "interop". 16:57:37 szilles: My concern is that, left to the vendors to declare interop, this won't work. 16:57:49 szilles: Marketing departments have a strong idea to do that. 16:58:06 plinss: I don't think anyone is suggesting that a single vendor declaring interop is sufficient. 16:58:33 plinss: I think the current process we have, where someone suggests we have sufficient interop and then asks the group for unprefix, is sufficient. 16:58:42 dbaron: But we did that with TTA, and the group said no the first time. 16:59:03 florian: When we asked the group "can we release TTA", we were aiming for a different level of interop. 16:59:05 hmmm, maybe I'm misremembering and thinking of something else 16:59:19 florian: We were asking for full interop. We're now not shooting for that - we want "sufficient interop". 16:59:19 dbaron - no you're remembering correctly 16:59:28 no, the first time we decided not to unprefix, largely because MS did not want to 16:59:29 we asked to unprefix TTA in Paris in February and were told no 16:59:40 I'm sure we can look that up in the minutes 16:59:40 and then when they decided to unprefix, that gave us consensus in the WG 16:59:55 florian: Now, between these two stages, you shoudl ship prefixed *and* unprefixed, so individual authors can use the unprefixed if it works for them, and provide brwoser-specific styles using prefixes to work around problem in specific browsers. 17:00:07 glazou: I'm seeing two cases. 17:00:17 glazou: I don't think that this process is the difficult one. 17:00:42 glazou: I think the hard one is the browser vendor developing a proprietary feature and then everyone else discovers it by surprise,a nd we have to implement. 17:00:55 florian: If text-size-adjust was released under this process, it would not be in a webkit prefix. 17:01:24 florian: It would put us in mostly the same difficulty as now, except that browsers who decided to implement it wouldn't be forced to implement it with a webkit prefix, which is today's situation. 17:01:39 florian: This system doesn't prevent the bad things from happening, but it untaints them. 17:01:53 florian: All the things we're trying to do with text-size-adjust now, we'd mostly have to do anyway. It won't go away. 17:02:03 florian: But at least we're not stuck witht he webkit prefix name that everyone has to support. 17:02:12 florian: It's not fantastic, but it's an improvement. 17:02:31 tantek: There's a bunch of different problems ehre. 17:02:47 tantek: I like the proposal as developed. It doesnt solve all the problems, but it soles all of them. 17:02:58 q+ 17:03:07 florian: I think it doesn't solve all of them, but it solves some of them better than the current world. 17:03:38 szilles: If you publish anything unprefixed before you have a reasonable belief that it's reasonably interoperable, you're going to get uninteroperable things, and it will become unusable. 17:03:46 s/soles all of them/solves some of them well enough/ 17:04:08 szilles: Or everyoen will follow the bad design. 17:04:23 TabAtkins_: The reality is that everyone follows the bad design *and* puts a webkit prefix on it. 17:04:38 szilles: But it prevents us from doing better under a better name. 17:04:54 "if it works, the author will use the unprefixed version because it's shorter typing" 17:04:59 -Szilles 17:05:21 glenn: A random remark - I noticed a posting that "the point of the vendor prefix is to assert the instability of a feature". 17:05:48 glazou: A corollaorya of that is that purely proprietary things shouldnt' use a prefix. 17:05:58 dbaron: I don't think we should try to come up with a master plan for the future. 17:06:04 dbaron: We should be figuring out how to adjust what we're doing. 17:06:13 dbaron: And I think it will require continued adjustment in the future. 17:06:16 ack dbaron 17:06:18 dbaron: We won't do it all today. 17:06:28 s/corollaorya/corollary/ 17:06:28 dbaron: I think a few directions in which we should be adjusting things... 17:06:34 dbaron: (1) ship less prefixed stuff on the web 17:06:41 dbaron: (2) unprefix things faster when we get interop 17:07:02 florian: I think we need to acknowledge that not everyone will follow the policy. 17:07:14 florian: This will happen, so our policy shoudl just not make things worse when this happens. 17:07:37 hober: Note that dbaron's #2 is something we can do right now withotu changing policies. 17:07:40 "when we get interop" - what level of interop? authors vs. test suites 17:07:52 fantasai: Actually, the current policy is just the "legacy content" excuse. 17:07:57 fantasai: That's what we used for TTA. 17:08:21 TabAtkins: for the one issue of let's unprefix faster, let's formally adopt Elika's stated proposal (from dbaron) 17:08:31 szilles: I can live with that 17:09:04 glenn: That's reminiscent of the knowledge that Maciej required for CR-exit. 17:09:09 s/knowledge/language 17:09:12 glenn: For HTML. 17:09:29 szilles: I like that it's not individual manufacturers making that decision. 17:09:47 tantek: One thing I'llr aise is that one recent RFC deprecated the use of x-. 17:09:56 glenn was referring to this email: http://lists.w3.org/Archives/Public/public-html/2012Aug/0190.html 17:09:58 tantek: But they drew a strong line between vendor-specific and experimental features. 17:10:06 tantek: They think that using x- for vendor-specific still works. 17:10:15 tantek: But not for experimental, because in the end everyone implemented it anyway. 17:10:23 tantek: So let's consider that work and analysis done by IETF. 17:11:06 plinss: Let me assert that, while learning from IETF is useful, we might not want to follow them exactly - they have a different problem space. 17:12:00 TabAtkins_: So are there standing objections to fantasai's proposal? 17:12:27 mmielke has joined #css 17:12:30 glazou: No objection, but I'd like to see it written otu formally in an email, as it's nearly unreadable here in the minutes. 17:12:55 [consensus] 17:13:10 glazou: We'll post to email, and formally resolve in a few days if there are no objections. 17:13:39 Topic: Fonts 17:15:25 s/Maciej required for/Maciej suggests for permissive version of/ 17:15:28 http://people.mozilla.org/~jdaggett/tests/simplekerningligs.html 17:15:34 jdaggett: I wanted to talk about default font features. 17:15:39 jdaggett: We talked aboutit a bit on the call. 17:15:52 jdaggett: People seemed comfortable, but there were some concerns fromMS developers. 17:15:54 also, https://groups.google.com/group/mozilla.dev.platform/msg/6107b1b7bd4fb799?dmode=source&output=gplain&noredirect was my earlier proposal on experimental features 17:15:59 jdaggett: So we'll quickly review. 17:16:18 jdaggett: [shows demo] 17:16:28 alternate link for that is https://groups.google.com/forum/?fromgroups#!topic/mozilla.dev.platform/itl6mtx2dxI[1-25] 17:16:31 jdaggett: This is showing raw text with no kerning or ligatures, and the second line is FF default, with ligatures and kerning. 17:16:41 florian: The default is influence by data coming fromthe font? 17:16:52 jdaggett: No, there is a set of features that are declared as "default" in the OT spec. 17:17:25 jdaggett: Because FF is turning these on by default, the fourth line and the second line match. 17:17:52 jdaggett: However, if we go over to Chrome, the default case is different from the random-feature case. 17:18:10 jdaggett: The internal reason for this is that there's a different rendering path with differetn defaults. 17:18:21 jdaggett: I'm saying that the default case should be the same as the random-feature case. 17:18:33 jdaggett: So that turning on a random feature shouldn't also turn on random other features. 17:18:55 jdaggett: [shows comparative screenshot] 17:19:08 jdaggett: What this shhows is language-sensitive features. 17:19:26 jdaggett: In turkish there is a dotted and dotless i. So when you do small caps, you need to put a dot on the i to be correct. 17:19:44 jdaggett: This is specified with a language tag. This gets sent downt ot he font engine, and that handles things correctly. 17:19:53 jdaggett: In IE10, this works correctly, but it's not yet implemented in webkit. 17:20:03 jdaggett: But weird behavior in IE10 for another feature. 17:20:11 jdaggett: In serbian, this glyph should be a localized alternate. 17:20:32 jdaggett: But if you turn on a randomf eature, FF gives you the same thing, but in IE10 all of a sudden the localized feature appears. 17:21:01 glenn: So the algorithm used by the UA to enable the OT advanced tables is different in different brwosers. 17:21:08 jdaggett: Yes, but I'm saying there shouldn't be side-effects from random features. 17:21:30 florian: So either everyone should match FF and keep the default features on, or they shouldn't turn on the default at all unless they're epxlicitly asked for. 17:21:34 s/brwosers/browsers/ 17:21:44 sylvaing: (1) there is no font-feature-settings - what features are on by default? That's a difference. 17:21:59 sylvaing: (2) when you do ask for a specific font feature, do you get just that, or do other things pop up? 17:22:16 jdaggett: If we go to the OT spec... 17:22:20 jdaggett: It's a bit scattered. 17:22:28 jdaggett: These are the default features,a cross scripts. 17:22:36 jdaggett: Some specific scripts have extra features by default. 17:22:38 http://people.mozilla.org/~jdaggett/tests/default-feature-list.html 17:22:49 jdaggett: [describes the table] 17:23:14 http://people.mozilla.org/~jdaggett/tests/simpleccmptest.html 17:23:24 jdaggett: [shows tone marks using one fo the default OT features] 17:23:45 jdaggett: This works in Chrome too, which shows that though they're not enabling the features by default, they have some logic that is turning on this feature when they show up. 17:24:07 sylvaing: Do you have a ref to the OT spec? 17:24:18 jdaggett: In CSS3 Fonts, section 7, there are several links in the text. 17:24:32 szilles: Which spec? ISO or MS? 17:24:35 jdaggett: Loosely-defined. 17:24:43 jdaggett: ISO is a file-format spec - it doesn't cover layout. 17:24:51 jdaggett: So we have to be a bit looser about what we consdier "the spec". 17:24:55 http://www.microsoft.com/typography/otspec/ 17:24:59 jdaggett: Hopefully they'll be more rigorous in the future. 17:25:16 ISO/IEC 14496-22 "Open Font Format" standard. The standard was published in 2007, and is now freely available for download from ITTF website. OpenType version 1.6 is identical to the “Final Draft International Standard” version of ISO/IEC 14496-22 FDIS “Open Font Format” (second edition). 17:26:01 miketaylr has joined #css 17:26:43 sylvaing: Our default rendering is consistent across the windows platform 17:26:54 jdaggett: So if you could review this list and suggest changes, would be great. 17:27:00 jdaggett: I think we're covered here. 17:27:14 florian: If I'm following you right, there are three ways of doing this. 17:27:18 http://www.microsoft.com/typography/otspec/featuretags.htm 17:27:22 florian: One is the Chrome/MS way, which is not ideal. 17:27:30 florian: Another is the Firefox, which may require an extra switch. 17:27:32 jdaggett: Let me finish. 17:27:45 jdaggett: The features in the list in red are those which can be controlled. 17:27:54 jdaggett: ...via font-variant-ligatures. 17:28:09 jdaggett: I've put in a "none" value to font-variant-ligatures which turns off all defaults. 17:28:36 jdaggett: That will not disable the requried features. 17:28:47 jdaggett: These are usually specialized features that are *needed* for correct rendering of various things. 17:29:11 glenn: How would someone shut down the rlig feature? 17:29:19 jdaggett: font-feature-settings: rlig 0;. It's possible. 17:29:59 jdaggett: I was going to put in an example of this showing a use-case of seeing the individual characters in Arabic, but I don't want to explain how to shut these things down easily. 17:30:06 jdaggett: There are some perforamnce considerations. 17:30:23 jdaggett: As the glyph composition shows, some of these are already handled in an ad-hoc way. 17:30:27 krit has joined #css 17:30:36 jdaggett: Most fonts, you can do a simple analysis and do a fast path if the font doesn't have a feature at all. 17:30:46 jdaggett: It just means there's a little additional logic before taking the fast path. 17:31:09 jdaggett: So I think we should resolve that the "none" value resolves the issue. 17:32:26 Bert: Is "none" the same as setting "no-*" for all the others? 17:32:54 jdaggett: Yes. 17:33:19 sylvaing: What about an "auto" value that is a default? 17:33:29 jdaggett: I'm keeping "normal" as the default. 17:33:42 jdaggett: kerning has "auto", because that's more prevalent and can be controlled by browser vendors. 17:34:13 RESOLVED: Accept font-variant-ligatures as written: "normal" is initial value, and "none" is added which turns off those features. 17:34:34 plinss: My only concern is that "normal" seems underdefined. 17:34:41 jdaggett: There's a section that defines the common defaults. 17:34:51 glenn: Could you put those common defaults for this feature in this section? 17:34:53 jdaggett: Oh, sure. 17:35:24 plinss: The reason you're not explicitly saying "'normal' means foo and bar" is because it varies on font engine and script> 17:35:27 jdaggett: Yes. 17:35:35 RESOLVED: Public a new WD of Fonts. 17:36:15
17:36:21 RESOLVED: Publish a new WD of fonts. 17:36:25 "My system just crashed." "Oh, good." 17:45:16 s/put those common defaults for this feature in this section/put a link from "common defaults" to its defining section/ 17:51:56 dbaron: LOL! 17:52:40 Rossen has joined #css 17:57:44 krit has joined #css 18:00:35 http://www.w3.org/Style/CSS/Tracker/products/10 18:01:26 ScribeNick: Bert 18:01:37 Topic: CSS3 Text 18:02:03 fantasai: We resolved to postpone to level 4, but now we have a shorthand idea. 18:02:23 ... [issue-236] 18:02:26 http://www.w3.org/Style/CSS/Tracker/issues/236 18:02:58 tab: sounds useful, now we have a useful way to address aliasing. 18:03:03 florian: I'd agree 18:03:33 fantasai: So resolve that word-wrap is shorthand for overflow-wrap? 18:03:50 RESOLVED: make word-wrap shorthand fpr overflow-wrap 18:04:23 issue-221? 18:04:23 ISSUE-221 -- text-emphasis-color can't recompute color to match text on descendants -- raised 18:04:23 http://www.w3.org/Style/CSS/Tracker/issues/221 18:04:45 fantasai: there is an errata open, should be posted to css3-color 18:05:20 smfr has joined #css 18:05:42 smfr has joined #css 18:05:49 http://www.w3.org/Style/2011/REC-css3-color-20110607-errata.html 18:06:01 action bert: add errata to css3-color errata ist about currentcolor, (as in above URL) 18:06:01 Created ACTION-502 - Add errata to css3-color errata ist about currentcolor, (as in above URL) [on Bert Bos - due 2012-08-22]. 18:06:23 issue-243? 18:06:23 ISSUE-243 -- graphical effects and text-decoration -- raised 18:06:23 http://www.w3.org/Style/CSS/Tracker/issues/243 18:06:36 record of currentColor errata is in http://lists.w3.org/Archives/Public/www-style/2012May/0541.html 18:06:37 fantasai: issue with underline and shadow and all these kinds of things 18:06:43 ... if you have an ancestor, 18:07:05 ... say whole para is underlined and a text has shadow, etc. 18:07:12 ... is the underline shadowed? 18:07:32 SteveZ: Is the underline logically part of the para even if physically it is not? 18:07:43 fantasai: How about visibility? 18:07:53 SteveZ: If not visible, also not undelrined, I think. 18:08:02 dbaron: ssociated with the text. 18:08:12 ... text decor gets colors from elt it comes from. 18:08:29 fantasai: if invisible, definitely not visible. 18:08:36 dbaron: You mean opacity? 18:08:39 fantasai: yes 18:08:47 dbaron: opacity happens all at once. 18:08:54 ... I can't imagine another option 18:09:04 ... opctity on ancestor applies to all descentants. 18:09:26 fantasai: Then remaining question is filter efefects (same way?) and tet shadow, 18:09:36 tab: filter efect is same yes 18:09:50 fantasai: part of underline could be shadowed and part not, looks weird. 18:09:57 SteveZ: looks weird eihter way 18:10:06 fantasai: [draws on white board] 18:10:17 dbaron: three cases: 18:10:33 ... shadow on something inide, on same, on something outside. 18:10:43 ... debate is on inside case 18:10:57 SteveZ: For emphasiz, I think the udenrline should get shdaow 18:11:20 fantasai: [draws text with underline, part of it get shadow] 18:11:26 ... does underline get shadow? 18:11:45 TabAtkins_: I think so. Some case lookk weird, but bulk is ok. 18:11:53 dbaron: I have diff. intuition 18:11:55 http://lists.w3.org/Archives/Public/www-style/2012Jan/att-0265/underline-shadow.png 18:12:12 sylvaing: ie does shadow the underline 18:12:33 ... so the etst case is para is underlined, and a part of iut has shadow? 18:12:38 fantasai: yes 18:12:51 sylvaing: webkit shadows the underine, ff also, 18:13:06 dbaron: what i syour test case, sylvaing ? 18:13:37 18:13:38 18:13:46

This is underlined

18:13:51 sylvaing: [trying to copy his test case] 18:14:06 SteveZ: it makes more sens with shadow below than with above. 18:14:27 sylvaing: looks like opera doesn't shadow th eunderline 18:15:31 dbaron: Not sure we could do anything than what we do. WOnder how Opera is able to. 18:15:38 ... text-shadow is inherited. 18:15:51 ... we don't even now what is outside or inside 18:16:00 fantasai: But you do know for udnerline. 18:16:16 florian: We don't shadow the undelrine either way. 18:16:32 s/either way/either way you nest them/ 18:17:22 bert: in fantasai 's drawing i think without shadow looks better... 18:17:39 dbaron: To implement, you'd redo your text decoration... 18:17:47 fantasai: Basically the same way as for color 18:18:05 s/Basically/Basically you do your shadow finding/ 18:18:25 fantasai: So it is possible to implement, what do we want? 18:19:05 ... if we decide it is not shadowed, users can still aplly a filter effect to get a shadow. 18:19:13 ... It is not a very common case. 18:19:30 sylvaing: We have interop between 3 browsers out of 4 i tested. 18:19:44 SteveZ: General underline rule covers position and color. 18:19:55 ... We'd like it to behave the same way. 18:20:05 ... Filter effects hould apply, we said. 18:20:18 ... Authors would be surprised if shadow was absent. 18:20:44 tab: I dont' care that much, lets go with [??] 18:21:03 plinss:biased towards finding shadow the same way as the color. 18:21:12 ... decotration visually belongs to parent, 18:21:26 ... slight bias. 18:21:45 SteveZ: So doesn't matter much now, and once it does, we'll put in a proeprty to control it. 18:21:58 plinss: I'm never quite sure how it should behave, 18:22:07 SteveZ: It's certainly one of th emost complex definitions. 18:22:36 dbaron: inclined to agree with bert about lower one [no shadow] being better. 18:22:56 SteveZ: I think it depends on the shadow. THis shadow is above. Below would look less strange. 18:23:19 plinss: the letter is different color, undelrine visually doens't belong to that text. 18:23:29 I was actually saying I agreed with Brad (since fantasai quoted his opinion), but it turns out Brad and Bert agree :-) 18:24:37 fantasai: I'll look strange no matter what. 18:24:56 sylvaing: is there a use case where it is abad thing what browsers do now? 18:25:17 dbaron: I think i prefer to go the other way, more consistent with the model. 18:25:28 SteveZ: Despite that filters apply? 18:25:40 dbaron: Different kinds of things. 18:25:54 TabAtkins_: They just apply to the pixels. 18:26:05 more consistent with the model and with most of the people who expressed an opinion about which is better 18:26:13 SteveZ: How would the user see the difference wheteher it is picel based or not? 18:26:39 sylvaing: Without a use caseshowing it is clearly wrong, I'd not like to change. 18:27:11 A) shadows draw the same decorations as the text they're shadowing 18:27:29 glazou: bottom 18:27:50 [strawpoll] 18:28:02 sylvaing: top 18:28:12 Bert: bottom 18:28:18 koji: top 18:28:25 SteveZ: top 18:28:33 glenn: top 18:28:36 ted: top 18:28:39 alan: top 18:28:44 fantasai: abstain 18:28:49 tantek: abstain 18:28:53 TabAtkins_: top 18:28:56 dbaron: bottom 18:29:03 florian: bottom 18:29:07 leif: bottom 18:29:11 http://lists.w3.org/Archives/Public/www-style/2012Jan/att-0265/underline-shadow.png 18:29:13 peter: bottom 18:29:41 fantasai: How about a public poll? 18:29:56 sylvaing: Does anybody object to what is already done? 18:29:56 glazou: NO CONSENSUS 18:30:12 florian: That would be ok, even if it is against what i prefer. 18:30:17 dbaron: yep 18:30:22 RESOLVED: top 18:31:01 s/top/ apply shadow, because it is what is most widely implemented now. 18:31:17 issue-273? 18:31:17 ISSUE-273 -- Interaction of text-decoration longhands and blink -- raised 18:31:17 http://www.w3.org/Style/CSS/Tracker/issues/273 18:31:46 fantasai: issue is that text-deco takes a number of values, including blink. 18:31:59 ... we dont have long hand for blink. 18:32:21 ... we can make 'blink' a valid value in one of the long hand properties. 18:32:28 ... or we can make a blink property 18:32:44 ... or we can throw it away in the DOM. 18:33:04 [jokes about blink] 18:33:15 fantasai: Could be a text-decoration-style 18:33:28 TabAtkins_: I'm using animation instead of blink 18:33:49 glazou: [shows his home page with blinking underline] 18:34:02 dbaron: most browsers haven't implemented blink. 18:34:12 ... not in webkit and IE. 18:34:13 Tab: can be implemented as an animation 18:34:31 glazou: I don't like special cases. so not fantasai's last option. 18:35:04 dbaron: We added an additional proeprty -moz-tex-blink to solve this issue. 18:35:15 glazou: i like that one. 18:35:34 dbaron: It is an extra property for a feature we might rather remove. 18:35:46 fantasai: Prefer to not ceate new property, seems excessive. 18:35:59 ... prefer to put in on text-decoration-style. 18:36:36 TabAtkins_: Prefer to ignore the blink on the shorthand, parse it, but doens't do anything. 18:36:43 fantasai: not even store it? 18:37:04 tab: right, doens't round trip, only round trips functionally. 18:37:51 dbaron: it is backwards-incompatible to pout it on anything else than tetx-decoration-style. 18:38:05 ... in fact, current spec seems not backwards compatible. 18:38:19 glazou: do not want to deprecate it. 18:38:33 TabAtkins_: But only two impls, so why not deprecate it? 18:38:40 plinss: We have two impls. 18:38:57 We haven't yet implemented the backwards-incompatible change that's in the spec 18:39:01 tantek: dprecate doesn't mean remove. 18:39:05 it looks like we still accept 'text-decoration: underline blink overline' 18:39:23 plinss: But still needs to be defined, even if deprecated. 18:39:56 ... can you say 'underline red overline' 18:40:08 dbaron: Not according to spec, and don't thing you should be able to 18:40:18 plinss: and 'underine solid overline'? 18:40:25 fantasai: Seems odd ordering. 18:40:33 ... Inclinded to say no. 18:40:48 dbaron: Easiest path forward is to make 'blink' value of text-decoration-line 18:41:01 ... the way we make the shorthand is bit weird. 18:41:12 ... because on eof the long hands is the old property. 18:41:23 ... We coluld just have added the new properties 18:41:51 ... we moved text-decoration functionailty. 18:42:08 ... blink is funny since CSS1. 18:42:32 [talk about history of netscape] 18:43:23 florian: Opera has implemented it. I'm not srongly asking for deprecation, but in favor of deprecation. 18:43:50 SteveZ: You don't really want people to use blink for accessibilty reasons. 18:44:07 fantasai: We can map BLINK tag to anaimation in user agent style sheet. 18:44:15 glazou (before SteveZ): If we're going to deprecate it, should have an example explaining how to do it with animations. 18:44:33 plinss: resolve to put blink on txt-decoration-line and deprecate it? 18:44:56 florian: so: should not, but are allowed to use blink? 18:45:13 plinss: it is a warning that it *may* be removed from spec later. 18:45:45 RESOLVED: blink is value of text-decoration-line and it is deprecated with warning that authors should not use it. 18:46:41 RESOLVED: add example of corresponding animation to the spec. 18:46:58 jdaggett has joined #css 18:47:00 (in the UA style sheet appendix) 18:47:03 http://people.mozilla.org/~jdaggett/tests/letter-spacing-tests.html 18:47:23 jdaggett: I did some tests. 18:47:31 ... Checking interopreability. 18:48:06 ... letter spacing should control spacing on either side of char, but should not affect last letter (if right aligned line) 18:48:20 ... [shows image] 18:48:28 http://dev.w3.org/csswg/css3-text/#letter-spacing 18:48:33 "Letter-spacing must not be applied at the beginning or at the end of a line." 18:48:38 ... But implementatiosn add spacing after last letter. 18:48:57 ... [shows another image] 18:49:13 ... THis image shows fully justified. 18:49:27 fantasai: The spec already says what UAs must do. 18:49:42 jdaggett: It doesn't say *how* spacing is applied. 18:50:14 ... at the end of the line yu should not get space. 18:50:24 fantasai: Yes, that is a bug according to the current spec. 18:50:51 jdaggett: But the spec doesn't say exacty that 18:51:22 dbaron: the spec is precise, but you are describing a differnet model, eqwually precise, but different at element boundaries. 18:51:41 jdaggett: I think you atually have to get into how it works, e.g., in rtl. 18:52:06 fantasai/dbaron: What impls do is already bug, according to current spec. 18:52:14 jdaggett: I don't see that text. 18:52:23 .. What fantasai quoted is not precise enough. 18:52:42 fantasai: Give me an example that is not covered by the spec, and we'll improve the spec. 18:53:02 jdaggett: and between ltr trl boundaries? 18:53:14 fantasai: It is still "between chars" as the spec says. 18:53:25 SteveZ: Hald on each side, and you can't tell the difference. 18:53:45 fantasai: You can do it as trailing edge, but you stll have to handle the boundaries correctly. 18:53:53 jdaggett: I'll have to look more. 18:54:00 ... I started from looking nto justification. 18:54:13 ... letter nd word spaceing is input to justify. 18:54:22 ... allowed ot expand in different places. 18:54:37 ... but the actual algo wasn't clear form the spec, for different values. 18:54:48 ... Each diff value of text-justify, 18:54:57 florian: I have a similar concern: 18:55:15 ... reading the spec, good algos can be done, but spec doesn't tell you how. 18:55:32 ... the spec doens't induce vendors to implement those algos 18:55:49 SteveZ: It is modeled on systems from well before XSL. 18:56:06 jdaggett: Now we are designing knobs with semi-undefined justification systems. 18:56:29 ... how these inputs are used, i don't see differences between justify values. 18:56:44 fantasai: Priorities between buckets. 18:56:57 ... It sorts the expansion opportunities into buckets. 18:57:04 ... It doesn't tell you the algo precisely. 18:57:13 ... It is not our job to define the algo. 18:57:26 jdaggett: That's the pb, Knobs have no precise meaning. 18:57:36 alan: not ndefined, maybe udnerspecified. 18:57:53 florian: Intentinally, i think. Don't prevvent better algos. 18:58:01 jdaggett: But we need a mininmum. 18:58:16 ... I don't udnertsand th euse cases for the different justify values. 18:58:21 ... What are teh examples. 18:58:33 ... I dnbd' tsee a whole lot of difference in trying them. 18:58:45 ... It seems to have been modeled on IE 5.5. 18:58:59 ... Not clear where the difference are. 18:59:11 ... What are the use cases, maybe sylvain can tell? 18:59:17 .. Are the cases till relevant? 18:59:22 s/.. /... / 18:59:31 sylvaing: You wan tto deprecate some? 18:59:44 jdaggett: Spec is just too vague. 18:59:57 fantasai: table in spec shows the differences. 19:00:22 florian: Don't agree. It seems most of these are needed for internationaliztion. 19:00:33 fantasai: One case is mixed scripts on one line. 19:00:49 ... Interword will expand the spaces and nothing else. 19:00:59 ... ideograph exapnds between ideographs. 19:01:06 ... distribute expands both. 19:01:22 florian: Different countries have different expectaions. 19:01:37 jdaggett: Do we have collected the examples? 19:01:50 florian: With this spec we can impl an algo that matches the spec. 19:02:06 ... But that algo may still not be very good. 19:02:15 ... A bad algo can stil be conformant. 19:02:36 fantasai: We cannot define all algos. That's more than a PhD research. 19:02:51 jdaggett: All I ask is some simple use cases. 19:03:02 ... why is it important to have these property values? 19:03:10 fantasai: Pictures? 19:03:18 jdaggett: Conncrete exampels. 19:03:40 jdaggett: Is there enough info in the spec to say if an impl matches? 19:04:06 ... Not saying we should deprecate. But I don't see the diff. when trying them out. 19:04:31 florian: I'm not sure I'm asking for more specific. That might lock into bad algo. 19:04:40 ... But I'm gemnerally unhappy. 19:04:48 ... Not sure if more defined makes me happier. 19:05:04 SteveZ: Document whatr the differences are is one yhing. 19:05:16 jdaggett: Spc shoul dat leats have rudimentary examples. 19:05:33 SteveZ: You say we should take things out *until* we can provice examples? 19:05:44 jdaggett: Posting to www-style is OK, too. 19:06:08 jdaggett: Would like to ask sylvaing to find where it comes from. 19:06:20 ... No doubt came from cases in MS Office. 19:06:33 ... can we get more info? 19:06:50 ... The description by MS is "this is good for Thai" 19:06:57 ... But why is it good? 19:07:12 fantasai: So you wan texamples in the spec. I'll take an action. 19:07:22 sylvaing: And I one to fine out about IE5 19:07:31 s/fine/find/ 19:07:49 jdaggett: We are trying to break it down by script. That is not the ideal way. 19:07:58 fantasai: Typographic tradition. 19:08:07 jdaggett: Kashida is an example. 19:08:14 ... Could apply to cursive in general. 19:08:23 ... Even if it is not currently used for latin. 19:08:30 SteveZ: Swash charcters? 19:08:42 ... They can go across words. 19:08:47 jdaggett: They extend? 19:08:51 SteveZ: yes 19:09:00 jdaggett: This is about alongating. 19:09:16 s/along/elong/ 19:09:46 ACTION fantasai: put examples of text-justify in the spec. 19:09:46 Created ACTION-503 - Put examples of text-justify in the spec. [on Elika Etemad - due 2012-08-22]. 19:10:19 ACTION sylvaing: look into history of text-justify in IE 5+ 19:10:19 Created ACTION-504 - Look into history of text-justify in IE 5+ [on Sylvain Galineau - due 2012-08-22]. 19:11:32 issue-276? 19:11:32 ISSUE-276 -- Split Text Decoration into separate module? -- raised 19:11:32 http://www.w3.org/Style/CSS/Tracker/issues/276 19:11:47 jdaggett: Why needed to split? 19:11:53 fantasai: module is very long. 19:12:08 ... text-deco no interaction with anything else in spec. 19:12:26 florian: Useful if that makes things faster. Does it here? 19:12:45 fantasai: Don;'t think so now. Maybe future levels may be different. 19:12:55 ... Table of contents makes more sense. 19:13:13 florian: Somewhat helpful for prioritizing. 19:13:33 ... Smaller spec easier. 19:14:43 jdaggett: I think the spec needs to be stronger. Take thinks to level 4. 19:14:54 s/stronger/smaller/ 19:15:05 ... This spec should be considered for what is specified and anot and push thibgs out accordingly. 19:15:17 ... DOn't think tetx-deco needs its own spec. 19:15:30 SteveZ: But splitting makes it easier. 19:15:36 tantek: Agree. 19:15:54 florian: I'm happy with split if editors want it and take on editing both. 19:16:13 jdaggett: *AND* not new features in either part. 19:16:21 fantasai: Agreed. No new features planned. 19:16:52 ... But we need to talk about one issue next. 19:17:20 bert: it is so hard to find in which spec a prop is defined. 19:17:24 Handy CSS property index for split specs: http://meiert.com/en/indices/css-properties/ 19:17:32 tantek: That is a glbal pb. Needs to be fixed. 19:17:42 glenn: snapshot? 19:17:51 fantasai: snapshot doesn't incude anything below CR. 19:18:07 Molly has joined #css 19:18:25 http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Ap%20{%20font-size%3A%203em%3B%20text-decoration%3A%20line-through%20}%0Aa%20{%20xpadding%3A%200.2em%3B%20}%0Aa%3Ahover%20{%20background%3A%20yellow%3B%20}%0A%3C%2Fstyle%3E%0A%3Cp%3Eone%20%3Ca%3Etwo%3C%2Fa%3E%20%3Ca%3Ethree%3C%2Fa%3E%20%3Ca%3Efour%3C%2Fa%3E%20%3Ca%3Efive%3C%2Fa%3E%20six 19:18:31 RESOLVED: split text-decoration into sepearet module. 19:18:50 issue-275? 19:18:50 ISSUE-275 -- constant vs. varying text-decoration positions -- raised 19:18:50 http://www.w3.org/Style/CSS/Tracker/issues/275 19:19:18 issue-270? 19:19:18 ISSUE-270 -- text-decoration-skip value for border/padding/margin -- raised 19:19:18 http://www.w3.org/Style/CSS/Tracker/issues/270 19:19:32 fantasai: [explains example above] 19:19:44 ... strange effects on hover. 19:20:17 ... imagine you're hovering over a link, with padding 19:20:25 ... the strike through is fragmented. 19:20:31 ... looks really bad. 19:20:45 dbaron: We discussed text-decaration models a lot. 19:20:56 ... We came up with one. Took many years to get it impleented. 19:21:12 ... FF implemented it. Now you say we don't want thtta model. 19:21:29 fantasai: Use case is editor's names on drafts. 19:21:45 ... I added padding around the links. 19:21:52 ... That broke strike trhrough. 19:22:42 ... Any kind of padding on inline elements will break it. 19:22:56 alan: padding is not content, text-decoration should not apply. 19:23:08 sylvaing: But underline doesn't stop under padding. 19:23:19 correction: it actually does 19:23:49 glazou: Say in an editor I select a paragraph, and it has modification marks, highlighted with line thrhough. 19:23:55 fantasai: But the para is a block. 19:24:14 ... Issue is if ancestor is striking through an elt. 19:24:18 dbaron: Proposal? 19:24:37 fantasai: I propose keyword 'box-decoration' 19:24:45 dbaron: On inline elts only? 19:24:48 fantasai: Yes. 19:24:53 (display:inline, not inline-block, etc.) 19:24:56 jet_ has joined #CSS 19:24:58 ... If text-deco is pallied by ancestor 19:25:11 ... then is is applied from margin edge to margin edge. 19:25:21 tantek: We had long discussions long ago. 19:25:33 ... We all did something different with CSS2 19:25:45 ... We settled on a model that looks reasonable. 19:25:58 ... We had to make exceptions for blocks 19:25:59 tantek^: about how box properties apply to inlines 19:26:11 ... This seems liek ame pb. We missed an exception. 19:26:31 ... Same case as how borders and bgs apply to boxes. 19:26:55 ... Rather than add property, we need to fix the definition. 19:27:16 ... We did it with borders and bg, I think we should try to do the same here. 19:27:23 glazou: It's only inline? 19:27:31 fantasai: Yes, strictly. 19:27:45 ... Either define, or add value (or both). 19:27:53 for text-decoration-skip 19:27:57 dbaron: We aren't yet interop on the CSS 2.1 behavior. 19:28:16 dbaron: So I'm ok with it even though it's a change from 2.1. 19:28:32 tantek: Maybe apply an optimistic change and give authors a way to scream if it breaks pages. 19:28:45 ... Evaluate case by case, then change default accordingly. 19:28:55 glazou: I can live with proposed change. 19:29:10 ... MAkes no sens for non-inline. 19:29:30 fantasai: Should try to do it by default. 19:30:07 
19:30:58 leaverou has joined #css 19:31:16 dbaron: Drawing the text-dco is thus independent of the text. Draws through margins. 19:31:26 florian: what does it mean? 19:31:38 dbaron: May be detecatable in cases with nested inlines. 19:31:49 ... E.g., with relative pos. 19:31:51 Zakim has left #css 19:33:39 dbaron: Add new value to text-decoration-skip. Not part of initial value. Default is to draw decoration from margin edge to margin edge. 19:33:47 difference between "from margin to margin" and "through inlines" is detectable with painting order, e.g., with text 19:33:57 Default is to draw decoration on margin/padding/border 19:34:31 RESOLVED: Add a new value to text-decoration-skip controlling whether decorations are drawn through the padding/border/margin of display:inline elements. This new value is not part of the initial value and therefore (change from CSS 2.1) decorations are drawn through padding/border/margin of inlines by default. 19:38:01 Blatt has joined #css 19:39:29 miketaylr has joined #css 19:51:14 Blatt1 has joined #css 19:54:30 Blatt1 has left #css 19:58:53 Blatt has joined #css 20:02:27 jet_ has joined #CSS 20:09:19 krit has joined #css 20:13:31 csswg? 20:14:28 fantasai: i think daniel/tab knows the skype csswg username 20:14:34 not me 20:26:17 achicu has joined #css 20:28:45 mvujovic has joined #css 20:32:21 ScribeNick: fantasai 20:32:33 Zakim has joined #css 20:32:45 Zakim, make room for 3 20:32:45 I don't understand 'make room for 3', glazou 20:32:55 Zakim, room for 3 20:32:55 I don't understand 'room for 3', glazou 20:33:01 zakim, room for 3? 20:33:03 ok, plinss; conference Team_(css)20:33Z scheduled with code 26631 (CONF1) for 60 minutes until 2133Z 20:33:51 vhardy_ has joined #css 20:34:05 Team_(css)20:33Z has now started 20:34:12 +??P0 20:34:36 vhardy__ has joined #css 20:34:49 Zakim, ??P0 is me 20:34:49 +glazou; got it 20:35:12 krit: waiting for you on the call above 20:35:15 +krit 20:35:52 https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html 20:36:09 Vincent: FPWD request for filters 20:37:03 krit: Are there any questions? 20:37:28 krit^: Spec is a combination of predefined filter effects, SVG filter effects, and CSS shaders 20:37:45 alan: SVGWG already agreed to publish 20:39:09 fantasai: Last time CSSWG discussed this, we concluded we wanted several "targets" of things to filter 20:39:33 krit: what's your skype id ? 20:39:39 fantasai: One was the background, another was background + border as a single unit, another was borders only, another was content only, another was entire element as a whole 20:39:41 krit85 20:39:55 krit: leaving the call now 20:39:59 -glazou 20:40:13 fantasai: Can I apply e.g. an opacity filter, or a blur filter, to any one of these things listed above? 20:40:28 fantasai: If not, I think that's an issue 20:40:34 hober: ok with just marking that as an issue 20:40:35 fantasai: sure 20:41:20 fantasai: are you thinking of blending and compositing? 20:41:50 fantasai: It's in there. I haven't heard of doing this for filters too (but it makes sense) 20:42:33 no idea what the technical term, only that we want to be able to apply filters to each part 20:43:04 fantasai: We've had requests for background-fiter, border-filter, etc-filter (replace filter with opacity, or shadow, or whatever) 20:43:19 fantasai: We decided we should do this generically with filters, rather than adding a new property for each 20:43:47 fantasai: So this module needs to be accommodating those requests somehow 20:43:52 ACTION krit: mark this as an issue 20:43:52 Sorry, couldn't find user - krit 20:44:23 ACTION dschulze: mark this as an issue 20:44:24 Created ACTION-505 - Mark this as an issue [on Dirk Schulze - due 2012-08-22]. 20:44:34 alan: Anything else? 20:45:03 -krit 20:45:04 Team_(css)20:33Z has ended 20:45:04 Attendees were glazou, krit 20:46:08 RESOLVED: Publish Filters FPWD 20:46:21 Topic: Masking 20:46:46 Topic: Transforms 20:46:54 http://dev.w3.org/csswg/css3-transforms/#animation 20:47:09 krit: Talked about interpolation, and request for some tests 20:47:39 krit: All browsers do ? 20:47:50 krit: All browsers do matrix decomposing 20:47:54 krit: ... 20:48:25 http://wiki.csswg.org/topics/interpolation-rotate3d 20:48:26 krit: Let me post a link 20:48:39 krit: What I tested was browsers interpolation on rotate3d 20:48:58 krit: Actually looks like all browsers do magic decomposing (matrix decomposing) 20:49:01 ???? 20:49:33 krit: Suggest we always to matrix decomposing 20:49:48 s/Suggest/Suggest that when rotate3d() is involved/ 20:49:51 for rotate3d we always decompose with matrix 20:50:03 thats is what all browsers do with the exception of chrome 20:50:19 chrome does number interpolation if the roatate is arround 0,0,1 20:50:21 0,10 20:50:22 Koji has joined #css 20:50:23 or 1,00 20:51:17 I can change the behavior of Chrome in WebKit to match all other browsers 20:51:23 fantasai: Is matrix decomposition satisfactory for what users would want to do? 20:51:44 I would expect that useres want number interpolation 20:51:54 but that is not what browsers seem to do 20:52:18 dbaron: Not that great 20:52:38 It seems unlikely that IE10 can change the behavior 20:52:52 it is already ready for shipping 20:54:31 sylvaing: current behavior is used in our app frameworks - could be tricky to change 20:54:53 20:55:02 hober: i'm happy with krit's proposal on this issue 20:55:40 it will be harder if we depend on the unprefixed version of the feature; also depends on other live content that may use this. 20:55:40 fantasai: So do we really want to lock that in? or just consider it a bug ? 20:56:11 A bug in browsers or implementation? 20:56:18 sylvaing: It's hard for us because we use this in our app frameworks. 20:56:18 fantasai: Usually the problem is switching behavior from a numeric interpolation case to a matrix decomposition one 20:56:21 fantasai: Other way around I understood from last time was not so much of a problem 20:56:23 TabAtkins: In first case, where everything's the same, would expect angle. 20:56:26 TabAtkins: But where vectors are different, would be weird. 20:56:28 TabAtkins: Even if we do numeric interpolation, interpolating the 3 args numerically is probably not what authors want. 20:56:32 dbaron: I think we want numeric interpolation when the 3 components are the same 20:56:40 TabAtkins: That would be minimally good 20:56:53 TabAtkins: That would at least allow rotation along an axis that is not x/y/z 20:57:07 dbaron: If authors want something more complicated to animate, then they have to explicitly split it up the way they want 20:57:27 I am unsure if Safari can implement numerical interpolation for rotate3d in general 20:57:44 fantasai: Seems better than matrix decomp 20:58:00 TabAtkins: So question is, do we normalize the vector before comparison? 20:58:04 Vincent: Don't think that'll work 20:58:16 krit: Spec wants the vectors to be normalized 20:58:31 krit: Safari doesn't, sticks on CoreAnimation 20:58:38 krit: Can't do numeric interpolation 20:59:08 sylvaing: That's their problem. 20:59:19 krit: This will mean that you'll have different behavior on Safari than other browsers 20:59:37 TabAtkins: Not strictly true. Safari just has to do some additional bookkeeping 20:59:41 decadance has joined #css 21:00:20 dbaron suggests doing this on a telecon 21:00:37 Proposal A: rotate3d() always uses matrix decomposition 21:01:06 Proposal B: rotate3d() uses numeric interpolation when the first 3 arguments (defining the axis) match 21:01:30 Proposal C: roate3d() uses numeric interpolation when the first 3 arguments (defining the axis) match *after normalizing the vector* 21:01:57 A is implemented right now, but what authors will want 21:02:04 is B or C 21:02:17 RRSAgent: url? 21:02:17 I'm logging. Sorry, nothing found for 'url' 21:02:17 because otherwise can't rotate along axes other than xyz 21:02:41 krit: There is no B, spec says they are normalized 21:02:43 rrsagent, pointer? 21:02:43 See http://www.w3.org/2012/08/13-css-irc#T21-02-43 21:02:50 TabAtkins: At what stage? Does it say computed values are normalized? 21:02:55 TabAtkins: If not, we can say that 21:03:17 The spec says it's normalized, but doesn't say when, so it's basically meaningless. 21:03:30 plinss: Only place that user would notice is when rotate takes you back where you came from? 21:03:34 dbaron: No, lots of cases 21:03:46 dbaron: If you decompose a 90deg rotation into 2 components, won't do exactly the same thing 21:04:03 dbaron: The bigger the angular difference, the more noticeable it is 21:04:13 dbaron: Past 180deg, will notice greatly because might get different direction of rotation 21:04:20 dbaron: or different number of rotations. 21:04:29 krit: Animating from negative vector to positive vector? 21:04:34 dbaron: Just count as a mismatched vector. 21:05:34 fantasai: So we're down to A or C. 21:05:45 fantasai: I think we should go with C, since that's what authors will want. 21:05:50 hober: Go with A, that's what's implemented 21:06:12 TabAtkins: This isn't a compat issue, so we don't need to do bugwards compat 21:07:22 plinss: My concern is that sometimes you get matrix decomposition behavior, and some cases you don't. Will authors be surprised about that? 21:07:32 hober, TabAtkins: it's predictable 21:07:54 TabAtkins: If the vector is the same, we interpolate otherwise not 21:08:53 Vincent: We have two vectors, right, we could ... even if they don't match 21:09:12 Vincent: Could do better behavior than decomposing 21:09:24 plinss: That would be less surprising to the author, I think 21:09:42 TabAtkins: So that would be option D, fully define interpolation 21:10:03 dbaron: There are a bunch of places where you'll have to make a lot of arbitrary decisions 21:10:33 dbaron: special behavior for antiparallel vectors? If so, use that behavior for any >90deg angle? What about 90deg angles? 21:10:50 hober: Would be nice if Simon were here for this 21:11:14 plinss: Anyone want to take an action to try to define D 21:11:28 ACTION Vincent: Write a proposal for vector interpolation for rotate3d() 21:11:29 Created ACTION-506 - Write a proposal for vector interpolation for rotate3d() [on Vincent Hardy - due 2012-08-22]. 21:12:09 plinss: anything else? 21:12:31 krit: Can we publish after decision about rotate3d()? 21:12:38 plinss: How far are we from LC? 21:13:13 krit: Some minor issues, would also like to publish WD and ask for review before going to LC 21:13:20 plinss: Asking if this is last WD before LC 21:13:48 RESOLVED: Publish WD of Transforms after rotate3d() is resolved 21:14:00 s/rotate3d()/rotate3d() animation/ 21:14:15 The other issue, by the way, is whether "falling back to matrix interpolation" means for the function or for the entire list. 21:14:19 http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html 21:14:26 I think it should be just for the function. 21:14:39 krit: CSSWG decided to apply masking to HTML content, SVG WG ants to work together with CSSWG 21:14:47 krit: So we made FXTF draft for masking 21:14:56 krit: It's a proposal that just specifies ... for browsers 21:15:10 krit: We have Firefox that .. and we have Webkit that does something with masking 21:15:17 krit: Specification which tries to address both proposals 21:15:26 krit: Two different sets of properties 21:15:31 krit: One is mask-image, similar to bg image 21:15:45 krit: idea is that authors don't need to learn new syntax for it 21:15:53 krit: syntax is exactly the same 21:15:58 krit: behavior is same, just with masking 21:16:04 krit: masking process ... filter 21:16:20 krit: There's also 2nd set of properties mask-box-image 21:16:31 krit: similar to border-image 21:16:32 http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html#mask-box-image 21:16:37 drublic_ has joined #css 21:16:52 krit: Does CSSWG want to go with this approach? 21:16:57 krit: any concerns about this? 21:17:37 fantasai: Are there use cases for all these properties? 21:17:46 krit: They are quite useful, easier/ more poweful than SVG masking 21:17:51 krit: So think it's very useful 21:18:11 krit: ... 21:18:17 krit: mask-box-image, used quite a lot 21:18:26 krit: still a feature that's heavily used on mobile devices today 21:18:54 fantasai: My opinion is basically if roc thinks it's a good idea, it's good 21:19:14 hober: harmonizing webkit-mask with SVG is a no-brainer, should continue to work on it 21:19:28 dbaron: Would like a chance for other to people look at it 21:19:49 krit: roc said same thing as you, fantasai 21:20:02 Vincent: Goal was to see if group thinks its a good idea to work on this 21:21:14 fantasai: Think it's good to work on this, think that idea of aligning with existing properties seems smart, 21:21:41 fantasai: Think that in cases where the values match an existing property, should refer to the definitions in the existing property rather than repeating it 21:22:00 e.g. postion should refer to definition of in css3-background rather than duplicating it 21:22:28 dbaron: I'm a little unsure how high priority this should be 21:22:35 dbaron: There's been some stuff in webkit for awhile 21:22:45 dbaron: we've had a huge a mount of pressure for TTA, but not so much for masking 21:23:20 dbaron: That makes me think that there are a bunch of other things this group works on that are probably higher priority than this 21:23:26 krit: I can't disagree with that of course 21:23:39 krit: We want to address this in SVGWG, so don't see how it can harm the CSSWG 21:24:05 hober: In the contextof is it a priority, I've certainly had on my to-do item to spec -webkit-mask, so thankful to dirk for taking this on 21:24:32 s/TTA/transforms, transitions, and animations/ 21:24:41 Bert: I have two questions 21:24:52 Bert: Since 'clip' has never been used, why would 'mask' be used more? 21:25:06 Bert: Second, isn't this a kind of filter 21:25:18 TabAtkins: We have lots of examples of -webkit-mask being used on the Web 21:25:36 krit: Used a lot for images and videos 21:25:56 krit: clip-mask can also be used similar to shapes in CSS exclusions 21:26:05 krit: I'm fine to specify if CSSWG wants 21:26:31 fantasai: Speccing something that replaces -webkit-mask with a standard feature seems like a good idea 21:27:17 hober: And doing it in a way that harmonizing with SVG is good 21:27:32 krit: Been in Webkit for 4 years 21:28:10 Leif: Not handled by other spec? 21:28:50 TabAtkins: Theoretically could be a filter, but like box-shadow, something that seems ot benefit from having its own property. Also SVG has its own masking already anyway 21:29:03 Mask the filters? :) 21:29:19 krit, also http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html should say who the Editors are 21:29:29 krit: In SVG, masking, then filters, then clipping is separate step 21:29:53 jdaggett: Should we move on? 21:30:22 Topic deferred, giving dbaron &co to ask others for feedback 21:30:43 Topic: Writing Modes 21:30:51 vhardy_ has joined #css 21:31:34 koji: In the end I would like one working group resolution, so would like to start from some background. 21:32:06 koji: UTR50 started last August 21:32:34 koji: At that point, there was a problem that UTR50 defines it scope to capture major us in Japanese, and there was probably a little different from what fantasai wanted for CSS3 Writing Modes 21:32:42 koji: So after UTR50 draft 1 was done, there was a lot of feedback 21:33:08 koji: But rather tha each codepoint issue, of upright vs. sideways, but what is scope and goal of UTR50 and scope/goal of Wirting Modes 21:33:17 koji: The editor, Eric, set scope to Japanese 21:33:26 koji: Most feedback I saw was scope should be global rather than Japanese 21:33:42 koji: Other feedback like multi-language / math expressions shoudl be handled 21:33:52 koji: Some people wnat that consistency by ignoring osme legacy usage 21:34:01 koji: Some people want better typogrpahy than what's used today 21:34:20 koji: Some issues resolved by discusison, but in the end , everyone wants different scope for UTR50 and discussion was stuck, and that's what I saw before the UTC 21:34:38 jdaggett: I don't think that's a fair representation because the basis of UTR50 was to make the default orientation a character proeprty 21:34:47 jdaggett: To not be a combination of other properties and font information 21:35:03 jdaggett: The original draft of Writing Modes had that as the defining factor of orientation 21:35:21 jdaggett: The goal of UTR50 was to give us a defautl distinction, that at least set Latin sideways, and kanji upright 21:35:28 jdaggett: beyond that, I don't think it's as important 21:35:32 koji: Everyone agrees with that 21:35:38 koji: Issues is about symbols 21:35:48 jdaggett: Key point is that this thing have consistency 21:36:00 jdaggett: Specifics of whether one symbols is upright/sideways is much less important 21:36:07 jdaggett: Just trying to set a set of reasonable default 21:36:19 jdaggett: If you're talking about math expressions in vertical text, you're off in the weeds 21:36:27 jdaggett: What has come out of UTC and the mail you sent around, this is the scope 21:36:35 jdaggett: That is much more confined scope, I'm fine with that 21:36:44 koji: The UTC resolved to tighten the scope 21:36:53 koji: Now UTR50 scope is Japanese and then East Asian 21:37:01 koji: And it's goal is interchangeability rather than better typography 21:37:06 koji: And to capture major use 21:37:19 florian: So they won't address non-EA things? 21:37:30 koji: I misunderstood at first point, but scope they mean priority 21:37:57 fantasai: Scope is all of Unicode 21:38:01 fantasai: Figure it out for all of Unicode -- the question is when different usage has conflicting requirements, then usage in East Asia win 21:38:23 koji: For that, usage in East Asia wins, and Japanese wins over that 21:38:38 koji: For some scripts, Unicode defines its scope to being able to write about such scripts, but not to write its native scripts 21:38:45 Florian: ... 21:38:52 jdaggett: and that's precisely why we shouldn't bikeshed on this 21:38:57 jet has joined #CSS 21:39:31 koji: Basic idea is goal of UTR50 is to interchange 21:39:42 koji: For various specific applications, encouraged to tailor 21:39:57 koji: So UTR50 resolved to go back or tighten the scope 21:40:14 koji: means if we follow UTR50, CSS Writing Modes scope would match that of UTR50 21:40:34 Florian: Question is They have changed the way they define everything, are we ok with that. 21:40:51 jdaggett: As long as there's not an uproar, then it's okay 21:41:25 fantasai: UTC's scope document (UTC member confidential) seemed reasonable to me 21:41:30 fantasai: though one point I wanted clarified 21:42:02 jdaggett: I think writing mode should just say that ... is defined by this property over here in Unicode. 21:42:16 fantasai: I think we just need them to publish a draft that has known errors fixed. 21:42:54 jdaggett: Koji, I'm upset that you were going to UTC meeting as representative of this group without informing us what was going on before it. 21:43:06 koji: I apologize for that. 21:43:16 koji: I prefer to use UTR50 as is, and I want to make sure everyone is ok with that. 21:43:20 jdaggett: I think we're all fine. 21:43:29 koji: UTC resolved not to do SVO for the first version. 21:43:47 koji: writing mode has text-orientation: upright. Discussion about whether upright is forced or smart. 21:43:54 koji: e.g., parentheses being upright 21:44:12 koji: UTC had resolved to add SVO to solve that 21:44:28 jdaggett: I think we should make text-orientation: upright be upright always 21:44:41 jdaggett: authors who want sideways parentheses should use sideways (or mixed) 21:44:52 koji: Could defer smart upright or define our own properties 21:44:58 fantasai: or refer to existing draft tables. 21:45:03 florian: it's an option, but we shouldn't pick it 21:45:23 jdaggett: It's only an illusion that this is smart. It only goes so far. It many situations it will not look right. 21:45:35 florian: This kind of table can only be maintained by Unicode. 21:45:47 Steve: I'd propose we either drop upright or leave it as forced upright as Koji suggested. 21:46:06 Steve: And we have the option, later, if a table for smart upright is later defined that we think is worth adopting, we have the option of adding a value to use that. 21:46:14 Florian: I think that's fair. 21:46:32 fantasai: My original intention with text-orientation that all values would be usable at a span level or at a paragraph level. 21:46:53 fantasai: If upright becomes forced-upright then forced upright is only usable on a particular span, because it breaks on hyphens, brackets. 21:47:02 fantasai: I don't see a use case where forced upright is better than upright. 21:47:09 Steve: Do you want to take upright out? 21:47:17 Steve: We don't have a definition of what smart upright would do. 21:47:23 jdaggett: We need upright in some situations. 21:47:31 jdaggett: Need to have it for making Latin upright. 21:47:59 Florian: I think we're in agreement. 21:48:25 fantasai: I'm not happy with upright being a forced upright, but I'm not going to override the WG. 21:48:40 fantasai: I don't think there's a use in having ... 21:48:46 fantasai: We could use the data that are already there. 21:49:00 Florian: I think having smart upright would be nice, but I wouldn't do it before Unicode defines and maintains what it means. 21:49:10 jdaggett: I think smart-upright is an illusion. 21:49:26 koji: UTC had some discussion on this, and they may add the value of ??? in the future. 21:49:53 Bert: Can you explain difference between smart and forced? 21:50:29 fantasai draws "(some-text)" in both forced and smart upright 21:50:49 jdaggett: With a regular font this isn't going to work, because regular fonts don't have vertical metrics. 21:51:00 fantasai: IF you have a font that has vertical metrics, or you're using capital letters... 21:51:19 fantasai: People want to do this on book spines and things -- to get this effect, you need to put spans around ( - and ) 21:51:25 jdaggett: For the set of use cases here I think that's acceptable. 21:51:37 alan: esp. if you have to modify the spans individually for the lack of font metrics 21:51:47 fantasai: If you don't have vertical metrics you might as well use ... 21:52:33 Florian: I understand that smart upright is valuable, and I think we can pursue it in the next level based on what's going on in Unicode. 21:52:40 Peter: We're still calling the value 'upright'? 21:52:57 jdaggett: If you have smart upright, then you have no way of forcing character to upright 21:53:04 fantasai: You could use tate-chu-yoku. 21:53:08 RESOLUTION: text-orientation:upright is a forced upright; it always means upright 21:53:53 koji: Excel does forced upright up until 2007; switched to smart upright in 2007. Been doing vertical writing since 1995. 21:54:31 koji: Last one is HO property is being removed from UTR50 draft 7. 21:55:12 jdaggett: Mongolian and Phags-Pa are vertical-only languages, but for convenience when they are discussed in English text they are often rotated into the horizontal 21:55:25 jdaggett: The way the fonts are designed -- typically designed rotated 90 degrees. 21:55:43 jdaggett: The HO property was to call out set of scripts that have this behavior -- scripts that are vertical only but rotated left when displayed horizontally 21:55:51 Glenn: Goes back to history of Mongolian 21:56:19 [discussion of history of scripts] 21:56:38 jdaggett: It was never really a very important property, because it just said whether the script was Mongolian or Phags-Pa. 21:57:03 Koji: Some points have different orientation of glyphs from the Unicode code chart. 21:57:20 Koji: So to make visually correct orientation you have to render differently from UTR50. 21:57:33 Koji: Because UTR50 reflects against code charts, and code charts and fonts don't match. 21:58:22 jdaggett: Summarizing: the handling of Phags-Pa and Mongolian is different from other scripts in the way you deal with orientations, and you can leave it to implementations to figure that out. 21:58:33 (before prev line) Koji: ... 21:58:45 Steve: Using the horizontal metrics in vertical settings 21:59:15 jdaggett: Spec can write a simple sentence saying that the way fonts are designed for Mongolian and Phags-Pa are unique, and implementations need to deal with that separately. 21:59:37 fantasai: Problem is that the Unicod ecode charts have it upright as though in vertical text, but fonts have it sideways assuming reference is horizontal text. 21:59:45 Steve: Just the way people historically made the fonts. 22:00:31 mvujovic has joined #css 22:00:33 Bert: schedule? 22:00:40 jdaggett: I think the draft needs cleanup first. 22:00:48 fantasai: Also need to wait for UTR50 to publish an update. 22:00:59 Steve: As long as it's in something equivalent to last call or one step away from... 22:01:10 achicu has joined #css 22:01:15 jdaggett: First we need a WD that just says [...] 22:01:26 jdaggett: The ED right now points at a fictitious property. 22:01:46 Bert: What schedule do we expect? LC soon? 22:01:54 jdaggett: Depends on edits Koji makes in Unicode. 22:02:18 jdaggett: ... incorporates changes that have been discussed. Draft 7 will. Expect to publish next UTC (November). 22:02:22 s/jdaggett/koji/ 22:02:40 koji: UTC has public review period after the draft. If people agree with it, could go quickly. 22:03:04 jdaggett: First step is to get a WD that says ... 22:03:17 fantasai: Other thing we were blocked on was an objection from Glenn on the naming of the logical directions. 22:03:38 Glenn: before/after vs. head/foot 22:03:51 Steve: Glenn made one objection, Murakami-san made one, I'm unhappy (but only unhappy) 22:04:10 jdaggett: Can we put an issue in the spec labeling this as an objection? 22:04:25 GLenn: Don't want to block this; I'm in the unhappy category. 22:04:33 Glenn: Some concern about cultural notion of head and foot. 22:04:38 jdaggett: Why can't we mark this as an issue? 22:04:47 jdaggett: shouldn't block this as a WD 22:04:53 [agreement, it seems] 22:05:05 [desire to resolve before LC] 22:05:24 Steve: Are people willing to reconsider this or should we go away and give up? 22:05:38 Florian: I'd prefer not to reconsider. 22:05:46 Peter: I'd prefer not to discuss discussing it right now. 22:06:02 Peter: We'll rename it before we go to last call. :-) 22:06:23 Topic: Lists 22:06:30 ScribeNick: fantasai 22:06:41 TabAtkins: There are two issues to talk about 22:06:53 TabAtkins: This has been sitting in WD because nobody has reviewed the draft yet 22:06:57 TabAtkins: Would like to advance the spec 22:07:05 TabAtkins: Otherwise I'll request LC 22:07:15 TabAtkins: In simplest case, marker positions are same 22:07:26 TabAtkins: Outside that, all implementations have different ideas of how markers are positioned 22:07:38 TabAtkins: spec is similar to what IE does, because that was sanest 22:07:47 Rossen: 3 years ago looked at it 22:08:04 Rossen: We spent a ton of time looking at list markesr and looked at all the different implementations 22:08:16 Rossen: As soon as you have anything other than simplest possible text with marker inside, all hell broke loose 22:08:37 dbaron: There's a section called marker positoining, but nowhere near long enough to cover all this 22:08:52 TabAtkins: Split across marker position and marker attachment 22:09:04 TabAtkins: Actual definition in Ch 7 22:09:20 TabAtkins: 7.1 defines behavior in terms of terms, and what that means.. then defined in ... right there 22:09:33 http://dev.w3.org/csswg/css3-lists/#positioning-markers 22:10:03 TabAtkins: If it's incomplete, please give me feedback. Correct me on anything that's wrong. 22:10:15 TabAtkins: Counter handling. Everybody is pretty sane on this 22:10:23 TabAtkins: Tried to tighten up definitions in the spec 22:10:37 TabAtkins: Added the counter-set property, equivalent to counter-reset, except doesn't create a new scope 22:10:47 TabAtkins: This is required if you want to implement HTML's value attribute in terms of CSS 22:11:02 TabAtkins: same as counter-increment, just sets to explicit value intead 22:11:52 TabAtkins discusses some weird case 22:12:07 TabAtkins: I defined the ::marker pseudo-element 22:12:13 TabAtkins: So you can style it, e.g. color the marker 22:12:26 TabAtkins: Can be done right now with hacks and markup tweaks, rather annoying to do 22:13:05 TabAtkins: marker-attachment property, was put in at request of bidi requirements groups 22:13:22 TabAtkins: To address the problem of list markers appearing on the wrong side 22:13:45 dbaron: I think this is a bad name 22:14:58 TabAtkins explains the use case 22:15:25 dbaron: We had a really long discussion about this at a TPAC 22:15:41 arno has joined #css 22:16:20 dbaron: Given that there's a whole bunch of issues with whether the marker follows text-align stuff, or whether it moves around floats, 'marker-attachment' sounds like it addresses those issues, and it doesn't 22:16:28 dbaron: maybe 'marker-side' or 'marker-direction' 22:16:43 Rossen: If it's an arrow, if it points to the left or the right? :) 22:17:40 plinss asks about marker direction of contents 22:17:57 TabAtkins: Last thing is inline list items 22:18:05 jarek has joined #css 22:18:08 dbaron: Does it support list-style-position: outside 22:18:20 TabAtkins: Hm, probably should 22:18:36 TabAtkins: Ok, those were changes that need review 22:18:44 TabAtkins: Let's start with one jdaggett is pacing about 22:18:51 TabAtkins: Which is the question of user-defined identifiers 22:18:59 TabAtkins: Do we preserve the case of user-defined idents? 22:19:06 TabAtkins: ASCII case-fold? 22:19:09 TabAtkins: .. 22:19:19 http://wiki.csswg.org/topics/custom-ident-case-sensitivity 22:20:40 jdaggett: we should design a simple system 22:20:53 jdaggett: this is not very important 22:21:06 jdaggett: CSS is otherwise case-insensitive 22:21:09 TabAtkins: Interesting thing here is that @counter-style lets you redefine idents, including case-insensitive ones in CSS2.1 22:21:29 jdaggett: users expect it to be case-insensitive 22:21:45 TabAtkins: So proposal is to make them case-insensitive, figure out which kind it is 22:22:02 jdaggett: Not always the best ways, but define something simple 22:22:14 jdaggett: for where handled within itself 22:22:23 Florian: Seems reasonable, but what do you do on the OM side of things? 22:22:49 Florian: Does the OM output the saem case as input or lowercase or what? 22:23:02 TabAtkins: Just do whatever OM does for idents 22:23:36 fantasai: What idents do depends on whether it's a predefined keyword or not 22:24:21 jdaggett: There are user idents in @font-feature rules 22:24:37 Florian: From an author point of view, jdaggett's proposal is best. 22:24:48 Florian: Question is if we will get this right on implementation side 22:25:23 dbaron: What is jdaggett proposing? 22:25:35 fantasai: Unicode lowercasing 22:25:55 dbaron: In some cases where there are user-defined idents, we want a mechanism for fast comparison 22:25:59 dbaron: such as atomization 22:26:21 dbaron: if there isn't a function that you can get a unique thing that you can compare, then we have a problem 22:26:27 dbaron: some unicode case comparisons that don't give you that 22:26:27 animation keyframes use user idents too, which are exposed to JS via animation events 22:26:40 jdaggett: You might be thinking of full case mapping 22:26:46 jdaggett: Unicode has simple case mapping and full case mapping 22:27:08 jdaggett: full case mapping doesn't preserve lenght of a string, e.g. eszet will become double capital S 22:27:26 jdaggett: There's also a simple set that preserves length of string 22:28:25 fantasai raises issue of lowercasing, uppercasing, case-folding 22:28:41 drublic has joined #css 22:28:43 ACTION jdaggett: propose case-comparison proposal 22:28:43 Created ACTION-507 - Propose case-comparison proposal [on John Daggett - due 2012-08-22]. 22:29:10 TabAtkins: Should we resolve on ASCII-case-insensitivity 22:29:26 jdaggett: Uncertain about that 22:29:42 TabAtkins: It's in the platform, HTML has it in a number of places too 22:29:49 Bert: Agree with jdaggett that it's a weird thing 22:29:56 mvujovic has joined #css 22:30:02 TabAkins: I'm concerned about going back to case-sensitive 22:30:19 plinss: So we're proposing to make idents case-insensitive in a form TBD 22:30:27 dbaron: I'd also like to resolve that the form will support atomization 22:30:52 dbaron: There has to be some conversion you can do once, such that you can do atomization 22:31:00 fantasai: I think that's true for all of the casing optimizations. 22:31:09 fantasai: You just can't do round-tripping. 22:31:18 plinss: What about Unicode normalization? 22:32:09 plinss: These identifiers are going to cross document boundaries, and cross into script. entirely possible that multiple style sheets applying to one page are generated by different people with different editors with different normalizations 22:32:13 jdaggett: then they will not match 22:32:26 dbaron: If we want to fix that, then we want to normalize the whole sheet as parse time 22:32:40 TabAtkins: I don't think you can avoid perf problems without doing that. 22:32:51 dbaron: You have to do it in so many different places. 22:33:31 dbaron: Unless you can test this for everything 22:33:55 fantasai: I think if we had a normalization form that worked for content, we could normalize the entire web platform on parse, and it'd be fine. But we don't have that. 22:35:36 fantasai: So I don't think we can do normalization until we have a normalization form that works. 22:35:41 plinss: That's valid feedback to i18n 22:36:19 plinss: This issue keeps coming up 22:36:24 Zakim has left #css 22:36:55 RESOLVED: user-idents in CSS are case-insensitive, insensitivity of a type TBD 22:37:20 ... but where the type of case comparison allows for atomization and hashing via a single up-front conversion 22:38:08 Topic: Counter Styles 22:38:46 fantasai: Previous discussion was to have counter styles in a different document 22:39:09 fantasai: Proposal is to put @counter-style with them 22:39:49 Florian: Point of splitting was to not put the counter styles list on the REC track 22:40:10 The definition of Caseless Matching (Case Folding) in Unicode 6.0 section 5.18 actually seems like it would be ok. 22:40:21 scribe: Bert 22:40:53 fantasai: Definitions of all counter styles in 2.1 make a good module. 22:41:06 ... Finsihed and complete, after case-insens inssue. 22:41:16 ... All the rest deals with a lot of things, not near LC 22:41:23 ... It is holding up counter style 22:41:41 ... So we might as well give it is own title 22:41:55 jdaggett: As bare minimum ou need to [???] 22:42:05 ... Splitteing counter-style 22:42:14 s/???/address OM/ 22:42:23 TabAtkins_: Takes 5 mins to define. 22:42:43 ... As soon as I have a checkout of the tetx. 22:43:16 florian: jdaggett has an opinion, but not as strong as whether or not to define long list of counter styles normatively. 22:43:30 ... We should on defining that long list. 22:43:34 ... I vote for not. 22:43:46 glenn: define whats in 2.1 and thats it. 22:43:54 fantasai: Do't want to limit ot 2.1 22:44:13 ... The criteria for 2.1 where basically what bert and howcome knew about. 22:44:31 tantek: Will fantasai draw up ciriteria? 22:44:48 dbaron: We shoukd have a def for the 2.1 one, Everyone impls them. 22:44:55 all the 2.0 ones 22:45:02 some of which were dropped from 2.1 22:45:02 glenn: Want to focus on 2.1, want to see a proposal. 22:45:23 fantasai: Want to see how hard it is for author to come with a style. 22:45:30 ... If it is hard, we should prefedine 22:45:40 ... Khmer might be easy for an author. 22:45:45 ... CJK is not easy. 22:46:01 glenn: mapping between numbers anbd symbols and then author can work it out. 22:46:08 fantasai: hat's what were talking about 22:46:17 jdaggett: Multiple ways of doing it. 22:46:44 http://www.w3.org/TR/2008/REC-CSS2-20080411/generate.html#propdef-list-style-type 22:46:49 has a bunch that are not in 2.1 22:47:10 TabAtkins_: Should not define a common resource. W3C would not host it. 22:47:34 glenn: rathole to define what is significnt or not, base don community size, e.g 22:47:53 jdaggett: We do 't know what the quality is of the definitions we have. 22:48:00 ... Should be a community effort. 22:48:23 plinss: You say (1) we cannot define it, (2) it is a quality issue. 22:48:52 jarek_ has joined #css 22:49:16 jdaggett: We cannot judge the quality. Who can jusge the Khmer numbering here? 22:49:30 glenn: I was there and I talked with the government there. 22:49:44 florian: We should draw a line somewhere. 22:50:09 s/I talked with/would not accept a proposal unless it came from/ 22:50:26 tantek: jdaggett is asking for community. Community provides examples, test cases, etc. We can check them. 22:50:33 jdaggett: We cannot check them. 22:50:46 plinss: You aregue ther eis npublic review. 22:50:57 florian: Toss it out to specialized group. 22:51:17 SteveZ: Why doesn;'t the wikipedia solution work here? Put it out, 22:51:24 ... Leave the community to get it right. 22:51:33 ... *We* are not going to get it right. 22:51:41 TabAtkins_: OK 22:51:49 fantasai: I'd like a counter style smodule 22:51:57 ... That defines 2.0 and 2.1 styles. 22:52:10 ... And has informative appendix with the other currently in the draft. 22:52:19 some people: no 22:52:28 plinss: [missed] 22:52:37 tantek: We have a wiki. Propose it there. 22:52:48 ... If the community steps up, that's great. If not, too bad. 22:53:25 koji: I agree wiki is good place to develop for a community. But o ce developed, how to put it in browsers? 22:53:38 florian: You don't. 22:53:50 ... Authors copy it it to their own style sheets. 22:54:07 SteveZ: Knowing what we know, we would have creatred a registry. 22:54:25 dbaron: here is the set in 2.0, I think all implemented in browsers. 22:54:40 ... One value got split in current draft, because of multiple interpretations. 22:54:48 ... CJK ideographic. 22:54:54 ... Split into 6 values. 22:55:17 fantasai: Complication with that one is that an author is not going to come up with that on hois own. 22:55:25 ... Those should be in the required set of built-ins. 22:55:44 dbaron: I think the required set should be the 2.0/2.1 set plus these 6. 22:56:01 plinss: 2.0 is not the justification, it is just our source. 22:56:14 tantek: What is already implemented is the justification. 22:56:24 dbaron: It is sane and not a big addition. 22:56:35 glenn: 2.1 list is enough for me. 22:56:45 ... Everything else, incl 2.0, in a registry. 22:56:57 dbaron: Don't kick out if it is implemented cross-browser. 22:57:18 [discussion about what FF supports] 22:57:44 florian: I can live with dbaron proposal. Not further than that. 22:57:53 TabAtkins_: Everything else goes into registry on wiki. 22:58:00 sylvaing: test cases? 22:58:13 dbaron: I think I submitted some. May have been removed since. 22:58:25 sylvaing: If no 2 impls, we can remove. 22:58:35 ... Strat with that, everything goes to wiki. 22:58:45 TabAtkins_: TEsting is easy, generate a 1000 numbers. 23:00:20 RESOLVED: Move counter-style rule and symbols functions to the coutner stylesspec. Retain in that spec the 2.0, 2.1 and the six way cjk ideographic split. Move rest of counter styles to registry on W3C wiki. 23:01:01 [discussion about origin of six-way split of cjk ideographic] 23:01:11 florian: Mark 6-way split at risk? 23:01:24 dbaron: Agreed. 23:01:53 RESOLVED: {cont'd) and mark 6-way split at risk. 23:02:17 glenn: I object to 6-way split. At risk is OK. 23:04:54 arno has joined #css 23:07:14 jarek has joined #css 23:21:10 Topic: Editorship 23:21:17 Alan: Propos krit as editor on Filter effects 23:21:23 RESOLVED: krit as editor on Filter effects 23:21:26 Topic: Sticky Positioning 23:21:55 jet has joined #CSS 23:21:58 hober: I posted to www-style a proposal for adding a new position value 23:22:05 hober: called 'sticky' 23:22:10 hober: similar to relpos 23:22:31 fantasai: It's like a combination of relpos and fixedpos that actually works 23:24:54 Koji has joined #css 23:26:04 hober: It's in-flow like relpos 23:26:14 hober: but the calculation of the offset is based on the intersection of the veiwport and the containing block 23:26:26 hober: common use cases are, e.g. sidebar in a web page 23:26:42 hober demonstrates 23:26:55 hober: This sort of thing is really common on the Web, using scroll events to emulate with JS 23:27:14 hober: All just a single new position value 23:27:26 hober: footer and header of table are always visible in viewport 23:27:49 hober shows address book that works like iPhone address book headers 23:28:25 plinss asks about a case of header and footer overlap 23:28:42 hober: So I think it might be worth, in the longer term, adding a property for handling collisions 23:28:49 hober: complicated if doing in multiple dimensions 23:28:57 by default would overlap 23:29:03 hober: Looking for resolution to pursue the feature 23:29:23 szilles: How does it behave for print? 23:29:31 fantasai: would be same as relpos 23:29:46 [5 conversations at once] 23:29:58 glazou: I think it's not that easy to specify 23:30:03 hober: I'll take an action to write a description 23:30:10 szilles: If I don't have scrolling it doesn't move 23:31:01 fantasai: Then you have the overlapping problem you have with fixed pos -- end up with tons of overlap. If you want this effect when printing you need to make space for it. 23:31:08 plinss^: why not print on every page 23:31:27 glazou: If I can describe it this was included in the P language 23:31:50 glazou: mechanism similar to pseudo-elements, you could select any element, such as viewport 23:32:08 glazou: then had an element, and on that you could say "min-y: 0" inside the viewport 23:32:21 glazou: meant element was always visible or invisible 23:32:35 hober: Common design pattern, ppl emulate a lot with JS 23:32:45 hober: But scrolling has gotten strange as time has gone on, so increasingly problematic 23:33:30 Rossen: One question I have, new value is that the behavior is not applicable or useful for position: absolute 23:33:38 sticky, real world use case: http://store.apple.com/us/configure/MD102LL/A?= 23:33:40 hober: yes 23:33:48 arronei: news.google.com sidebar 23:34:08 hober: Of all cases I've seen, makes more sense for in-flow positioning than out-of-flow. You want to leave space in flow for the item 23:34:37 plinss: Suggest considering abspos version of this 23:35:28 Bert: Seems you might want sticky differently in horizontal and vertical dimensions 23:35:54 hober: Suppose you had a wide table, not so tall 23:36:18 hober: you might want the column headers to stick the viewport, but if you scroll the table horizontally itself, you might want the row headers to stick within the viewport but not the scrolly 23:36:29 hober: is it the nearest scrollable ancestor that you stick to? 23:36:44 hober: do you have same decision in both dimensions? 23:36:48 arno has joined #css 23:36:49 hober: worth thinking about 23:37:08 plinss: Think proposal is for hober to write something up for css3-positioning 23:37:22 plinss: would you co-edit? 23:37:23 hober: either way 23:37:28 hober: add the proposal to http://wiki.csswg.org/spec/css3-positioning 23:37:31 glazou: Suppose green is the viewport 23:38:02 glazou draws a big green box, left half has three black boxes stacked on top. Another black box below that, followed by red box, followed by blue box 23:38:24 smfr, an example is running shopping cart totals positioned to left/right of forms 23:38:25 glazou: with collision could you get them to stack? 23:38:27 overlap by default 23:38:39 hober: I think overlapping by default is the right behavior here, could reus collision later 23:38:49 hober: also question of percentage values, at what distance do you start sticking 23:39:03 stacking gets hard; you end up with a float-like algorithm 23:39:22 I'm not convinced that reusing this same collision avoidance mechanism is the right thing. 23:39:26 Topic: Animations 23:40:17 https://docs.google.com/spreadsheet/ccc?key=0Akz3Ts2PEQF2dE1fTHhJMlJBbnp6UmZNY2dzVHpEVGc 23:40:30 sylvaing: This describes list of issues we had at last F2F 23:40:41 sylvaing: some things fixed already 23:40:57 sylvaing: hopefully reach LC at TPAC or before 23:41:05 sylvaing: couple left over from Hamburg 23:41:09 sylvaing: where in cascade do images go? 23:41:23 sylvaing: I believe dbaron described what Gecko was doing 23:41:38 sylvaing: The emerging consensus was that transitions would happen at the very end 23:41:51 sylvaing: you would go from current animation value to the trnasition end, but never really resolved on it 23:42:00 https://www.w3.org/Bugs/Public/show_bug.cgi?id=14713 23:42:07 http://lists.w3.org/Archives/Public/public-fx/2012AprJun/0107.html 23:42:19 sylvaing: we discussed this part 23:42:21 s/images/animations 23:42:27 sylvaing: here's gecko's cascade 23:42:30 sylvaing: we never resolved that 23:42:40 sylvaing: I haven't checked recent webkit, but they used to have .. at the bottom 23:42:57 sylvaing: in Gecko transitions are more important than animations 23:43:19 dbaron: Except we would start a transition during an animation? 23:43:36 webkit still applies animations after everything else 23:43:39 dbaron: starting a transition happens when we detect a computed value change that was not caused by an animation 23:43:47 dbaron: the restyling operation.. 23:43:57 dbaron: The before and after styles are different in the no-animation case 23:44:10 dbaron: I'm trying to remember what's the difference... 23:44:17 s/dbaron/sylvaing/ 23:44:34 sylvaing: Other implementations don't let user !important and UA !important override animations. I think we do want that 23:44:39 dbaron: I think we do want that. 23:44:51 dbaron: Questio nis whether we want them under the other !important rules 23:45:46 sylvaing: so any opinions? 23:45:56 Florian: I remember having an opinion, but don't remember what it was 23:46:21 fantasai: What are the options? 23:46:49 sylvaing: Option A, animations are higher than UA and author !important rules 23:46:58 sylvaing: Gecko allows them to override 23:47:29 dbaron: Another option would be to put animations here, between author normal an dauthor override 23:47:42 fantasai: Where would scoped style fit in with that? 23:48:26 dbaron: Author override and scoped would be a group 23:48:48 dbaron: Question would be whether animations would go before the !important rules, or after them 23:49:20 fantasai: So either animations would come right before all the !importants, or it would come right after all the author styles (including !importants) 23:50:04 fantasai: I think having animations override user/UA !imporant rules it's not a good idea 23:50:48 dbaron explains why having transitions at the end of the cascade makes sense: the UA/user !important rules would prevent computed value changes that could trigger transitions 23:51:04 sylvaing: so user rules could start them, but that's just about it 23:51:14 glazou: I'm using them in BlueGryffon to prevent animations to run 23:51:45 dbaron: Use case: user wants to override colors, but is fine with animations causing movement 23:53:12 RESOLVED: Animations are below user !important rules, not above them. [still discussing whether below or above author !important] 23:53:47 fantasai: So remaining question is whether author !important override animations or not 23:54:41 glazou: yes I think both User and Author !important should override animations 23:55:34 RESOLVED: Animations override all normal rules, but are overridden by all !important rules. 23:56:24 RESOLVED: Transitions happen last in the cascade 23:56:42 https://www.w3.org/Bugs/Public/show_bug.cgi?id=14713 23:57:09 sylvaing: snapshotting of values at the start of animation, action on smfr and dbaron on which properties snapshot or not 23:57:15 sylvaing: talk about that yet? 23:57:18 dbaron: not yet, no 23:58:28 sylvaing: Raised by ... 23:58:37 sylvaing: afaict not used 23:58:41 dbaron: Yes, let's remove them 23:59:03 RESOLVED: Remove initAnimationEvent method https://www.w3.org/Bugs/Public/show_bug.cgi?id=15338 23:59:26 sylvaing: need to define a constructor 00:00:01 https://www.w3.org/Bugs/Public/show_bug.cgi?id=14781 00:00:17 sylvaing: Spec doesn't specify starting frmae / ending frame, spec defines generating them but doesn't define when ... 00:00:33 dbaron: I believe we update it dynamically 00:00:42 sylvaing: at some point you have your first frame, and others follow. 00:00:48 dbaron: You're animating from that to some other pont 00:01:04 dbaron: if there's a style change that changes here, you're following this line instead of this line 00:01:13 Florian: You put a transition for the adjustment being smooth? 00:01:16 dbaron: Yes, maybe? 00:01:37 sylvaing: I think we do it static at the moment. Think Webkit does too 00:02:09 hober: Should be snapshotting after delay 00:02:15 sylvaing: but compute first frame, last frame 00:02:24 sylvaing: we didn't have a use case for dynamic case 00:02:38 dbaron: My worry about dynamic case is mostly style changes that are nearly sequential 00:02:50 dbaron: Because it'll expose when browsers coalesce things or not 00:02:56 jdaggett has joined #css 00:02:56 dbaron: Would like to minimize how much that's exposed 00:03:01 leaverou_ has joined #css 00:04:16 sylvaing: Is that related to issue of which properties to snapshot? 00:04:25 dbaron: testcases with a 5s delay are annoying 00:05:23 dbaron: If I move th emouse into it while animating, it jumps to other position while animating 00:05:30 sylvaing: Shouldn't this relate to general snapshotting issue? 00:05:34 sylvaing: ok, think it's the same bug 00:06:23 https://www.w3.org/Bugs/Public/slhow_bug.cgi?id=15850 00:07:09 sylvaing: I don't understand how you get an invalid rule here 00:07:15 https://www.w3.org/Bugs/Public/show_bug.cgi?id=15850 00:08:14 sylvaing: Have a few more edits, then ask for new WD 00:09:58 RESOLVED: Publish updated WD with those edits 00:10:26 sylvaing: Aiming for LC at TPAC or before 00:11:57 Topic: Scientific Notation 00:12:54 TabAtkins: Required for SVG. 00:13:12 dbaron: Unitless lengths and scientific notation are allowed in SVG attributes. 00:13:41 TabAtkins: One use is to align with SVG 00:13:51 TabAtkins: Other is it's useful in transformation matrices 00:14:25 TabAtkins: Syntax spec already defines parsing for it, just have a flag for it to turn it on or off. So no additional work on the spec side. 00:14:48 8.574e-21parsec == 1px 00:14:50 Florian: I will not object to scinot, but I'm not interested in it 00:15:17 plinss: Any objections to adding scientific notation? 00:15:20 Bert: Yes. 00:15:47 Bert: I'm not happy with what we add, we don't have anything left for normal people. 00:16:22 hober: Tab has two use cases 00:16:30 hober: I don't consider them incredibly important, but they're reasonable. 00:16:45 fantasai: I defer to dbaron. 00:16:54 dbaron: I'm against it, but I'm not going to object. 00:17:01 fantasai: That's my opinion. 00:17:06 szilles: I'm not opposed, I'm not for 00:17:18 alan: I think rationalizing things with SVG seems reasonable to do 00:17:28 szilles: Useful, but not critical. 00:18:11 Florian: which definition of scinot is this? 00:18:37 Tab: Same as SVG. Number e integer 00:18:50 Florian: How does this interact with minimum you're supposed to support 00:19:21 TabAtkins: Turns into equivalent number 00:19:35 dbaron: scinot is not valid in integers, only valid in numbers 00:19:45 dbaron: Don't want to deal with scinot in integers 00:20:45 TabAtkins quotes his spec text 00:21:28 dbaron and TabAtkins discuss parsing problems 00:21:38 and floats 00:21:43 hober: Just force it to be a number 00:22:06 .... 00:22:24 dbaron: Things that are integer are things we will represent using an integer rather than a floating type. Really don't want to encourage people to do exponents 00:22:46 Florian: Since you don't care either way, when we're specifying precision of support, shouldn't require ... cancel out 00:23:04 TabAtkins: So you're allowed to do truncation as you're parsing 00:23:28 dbaron: SVG's integer type does not accept scinot 00:23:34 http://www.w3.org/TR/SVG11/types.html#BasicDataTypes says doesn't take scientific notation and does 00:23:58 proposal: scinot for , allow range-checking based on parse time as well as interpretation-time limits 00:25:20 straw poll -> no consensus 00:25:34 Straw poll again, more formally 00:25:36 glazou: yes 00:25:39 bert: NO 00:25:42 koji: abstain 00:25:44 szilles: yes 00:25:48 jdaggett: no 00:25:55 glenn: yes 00:26:00 hober: abstain abstain 00:26:04 alan: yes 00:26:12 fantasai: defer to dbaron 00:26:15 tantek: defer to dbaron 00:26:16 dbaron: no, but not objecting 00:26:17 Tab: yes 00:26:21 yes 00:26:24 Florian: abstain 00:26:32 leif: why not, yes 00:26:35 plinss: yes 00:27:03 "Simon says" 00:27:11 :D 00:28:31 Bert: Not really fair to ask every F2F until not enough around 00:28:34 who disagree 00:29:15 5 no, 8 yes 00:29:30 RESOLVED: add scinot to CSS 00:29:50 Topic: text-size-adjust 00:30:00 dbaron: Don't know what there is to discuss... 00:30:07 tantek: Question is about going to FPWD 00:30:11 dbaron: Think I'd rather not. 00:30:14 with the ED as is 00:30:14 Meeting closed. 00:30:30 but it's just 5:30? 00:31:42 text-size-adjust shut the whole thing down 00:33:14 smfr has left #css 00:35:11 glazou has joined #css 00:46:16 glenn has joined #css 00:50:43 arno has joined #css 02:35:21 achicu has joined #css 02:35:31 achicu has left #css 03:14:57 dbaron has joined #css 03:30:27 shepazu has joined #css 04:06:03 leaverou has joined #css 05:02:23 dholbert has joined #css 05:22:38 dbaron has joined #css 05:32:46 fantasai has joined #css 05:33:00 macpherson has joined #css 05:33:31 hober has joined #css 05:33:55 dholbert has joined #css 05:33:55 plinss has joined #css 05:34:00 stearns has joined #css 05:34:11 paul___irish has joined #css 05:34:20 logbot has joined #css 05:34:24 heycam has joined #css 05:35:03 CSSWG_LogBot has joined #css 05:35:11 gsnedders has joined #css 05:35:12 shans_away has joined #css 05:35:12 glazou has joined #css 05:35:31 sylvaing_away has joined #css 05:36:01 vhardy_away has joined #css 05:36:31 alexmog_away has joined #css 06:39:34 leaverou has joined #css 06:42:43 Ms2ger has joined #css 06:42:46 jet has joined #CSS 07:00:34 leaverou has joined #css 08:16:57 tantek has joined #css 08:20:13 tantek has joined #css 09:01:27 drublic has joined #css 09:27:28 SimonSapin has joined #css 10:11:38 karl has joined #css 12:51:00 miketaylr has joined #css 14:29:38 krit has joined #css 14:33:30 glenn has joined #css 14:34:51 ksweeney has joined #css 14:36:32 ksweeney has left #css 14:41:44 dbaron has joined #css 14:59:21 jet has joined #CSS 14:59:45 myakura has joined #css 15:25:58 jet_ has joined #CSS 15:39:55 drublic_ has joined #css 15:51:25 drublic has joined #css 15:59:40 cabanier has joined #css 16:05:14 jet has joined #CSS 16:08:49 shepazu has joined #css 16:14:17 jet has joined #CSS 16:46:57 Rossen has joined #css 16:53:59 dbaron has joined #css 17:44:04 arno has joined #css 18:06:14 jet has joined #CSS 18:17:39 jet has joined #CSS 18:36:28 dbaron has joined #css 18:42:39 jet_ has joined #CSS 18:54:08 krit has joined #css 18:58:31 lstorset has joined #css 18:58:53 arno has joined #css 19:05:53 jet has joined #CSS 19:09:07 shepazu has joined #css 19:43:26 jet has joined #CSS 19:53:21 shepazu has joined #css 20:00:38 dbaron has joined #css 20:02:10 jet has joined #CSS 21:14:09 bradk has joined #css 21:14:17 dbaron has joined #css 21:15:46 Hello. Anything happening here? 21:16:40 ksweeney has joined #css 21:16:59 ksweeney has left #css 21:21:02 vhardy_ has joined #css 21:31:37 bradk: f2f finished yesterday 21:32:13 Ah. No wonder. I thought it was also today. 21:47:28 vhardy_ has joined #css 21:51:06 vhardy_ has joined #css 21:53:47 vhardy_ has joined #css 21:55:25 krit has left #css 22:05:34 vhardy_ has joined #css 22:37:46 vhardy_ has joined #css 22:57:22 drublic has joined #css 23:02:47 vhardy_ has joined #css 23:04:39 vhardy_ has joined #css 23:05:49 vhardy_ has joined #css 23:15:35 dbaron has joined #css 23:36:52 arno has joined #css 23:44:00 vhardy_ has joined #css 23:48:37 krit has joined #css 00:02:40 arno has joined #css 00:12:05 vhardy_ has joined #css 00:28:10 vhardy_ has joined #css 00:58:17 krit has joined #css 01:07:24 arno has joined #css 01:17:30 miketaylr has joined #css 01:19:25 vhardy_ has joined #css 01:43:49 vhardy__ has joined #css 02:58:16 drublic has joined #css 03:28:54 vhardy_ has joined #css 03:41:13 vhardy_ has joined #css 03:49:11 dbaron has joined #css 04:28:14 vhardy_ has joined #css 04:58:45 drublic has joined #css 05:22:40 vhardy_ has joined #css 07:32:37 Ms2ger has joined #css 07:57:43 tantek has joined #css 08:59:35 drublic has joined #css 09:15:33 SimonSapin has joined #css 09:29:47 drublic has joined #css 11:00:35 drublic_ has joined #css 11:33:01 krijnh has joined #css 11:43:58 florianr has joined #css 13:10:52 arronei has joined #css 13:57:23 jdaggett has joined #css 14:13:39 vhardy_ has joined #css 14:41:24 miketaylr has joined #css 14:44:34 jarek has joined #css 14:52:14 vhardy_ has joined #css 15:15:28 vhardy_ has joined #css 15:19:01 dbaron has joined #css 15:59:26 leaverou has joined #css 16:29:42 arno has joined #css 16:30:11 TabAtkins has joined #css 16:39:12 krit has joined #css 17:01:50 dbaron has joined #css 17:11:15 jet has joined #CSS 17:19:05 jet_ has joined #CSS 17:28:18 jet has joined #CSS 17:41:26 jet_ has joined #CSS 18:19:33 dbaron has joined #css 19:55:20 tantek has joined #css 20:18:39 drublic has joined #css 20:23:39 isherman has joined #css 20:43:09 drublic has joined #css 21:11:30 jarek has joined #css 21:20:08 drublic has joined #css 21:27:06 arno has joined #css 21:40:25 arno has joined #css 22:00:20 miketaylr has joined #css 22:22:07 tantek has joined #css 00:12:31 drublic has joined #css 00:50:05 myakura has joined #css 00:57:19 myakura has joined #css 01:25:26 tantek has joined #css 02:47:54 miketaylr has joined #css 04:00:25 krit has joined #css 07:58:13 Ms2ger has joined #css 09:38:43 drublic has joined #css 09:54:14 drublic has joined #css 10:07:25 drublic has joined #css 12:32:09 koji has joined #css 13:11:52 drublic has joined #css 14:13:07 koji has joined #css 14:37:00 lstorset has joined #css 15:35:07 drublic has joined #css 16:08:49 drublic has joined #css 17:04:31 drublic has joined #css 20:13:06 cabanier has joined #css 21:17:02 jarek has joined #css 21:18:04 jarek has joined #css 21:28:48 leaverou has joined #css 23:11:04 drublic has joined #css 23:43:59 Liam has joined #css 23:56:00 tantek has joined #css 00:01:26 tantek has joined #css 01:02:21 tantek has joined #css 01:16:10 tantek has joined #css 01:17:22 tantek_ has joined #css 03:03:23 tantek has joined #css 04:10:49 tantek has joined #css 06:57:24 tantek has joined #css 07:02:41 Ms2ger has joined #css 07:38:16 tantek_ has joined #css 08:07:45 jet has joined #CSS 08:20:26 jet has joined #CSS 08:30:39 tantek has joined #css 11:33:26 drublic has joined #css 20:10:15 jarek has joined #css 20:49:23 leaverou_ has joined #css 22:23:57 leaverou has joined #css 02:07:07 leaverou has joined #css 06:56:13 leaverou has joined #css 07:06:39 leaverou has joined #css 07:52:43 drublic has joined #css 08:20:12 drublic has joined #css 08:49:06 drublic has joined #css 10:13:27 SimonSapin has joined #css 11:16:32 drublic has joined #css 12:05:31 drublic has joined #css