IRC log of css on 2012-08-13

Timestamps are in UTC.

00:20:50 [dbaron]
dbaron has joined #css
00:45:19 [leaverou]
leaverou has joined #css
01:25:50 [krit]
krit has joined #css
02:28:53 [leaverou]
leaverou has joined #css
03:08:30 [leaverou]
leaverou has joined #css
03:09:21 [leaverou_]
leaverou_ has joined #css
03:12:47 [krit]
krit has joined #css
04:05:58 [krit]
krit has joined #css
15:47:10 [RRSAgent]
RRSAgent has joined #css
15:47:10 [RRSAgent]
logging to
15:47:16 [Zakim]
Zakim has joined #css
15:47:27 [glazou]
RRSAgent, make logs public
15:47:34 [glazou]
RRSAgent, span over midnight
15:47:34 [RRSAgent]
I'm logging. I don't understand 'span over midnight', glazou. Try /msg RRSAgent help
15:49:14 [glazou]
rrsagent, this meeting spans midnight
16:01:52 [TabAtkins_]
TabAtkins_ has joined #css
16:12:45 [arronei_]
arronei_ has joined #css
16:15:43 [florian]
florian has joined #css
16:16:49 [TabAtkins_]
ScribeNick: TabAtkins_
16:16:52 [Rossen]
Rossen has joined #css
16:17:44 [dbaron]
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]
jdaggett has joined #css
16:17:58 [TabAtkins_]
[sorting through agenda items]
16:17:59 [vhardy_]
vhardy_ has joined #css
16:18:58 [tantek]
tantek has joined #css
16:20:03 [vhardy_]
vhardy_ has joined #css
16:24:34 [hober]
krit: yes, once we finish making it
16:24:44 [krit]
hober: great, thanks!
16:25:12 [krit]
hober: W3C STYLE conference room for dialing in?
16:27:05 [hober]
krit: i assume so
16:29:38 [dbaron]
do we have a phone in this room?
16:33:41 [krit]
does someone have a cell phone if not? :P
16:34:23 [SteveZ]
SteveZ has joined #css
16:34:28 [fantasai]
ScribeNick: fantasai
16:34:31 [fantasai]
Topic: @supports
16:34:37 [fantasai]
dbaron: We've published one WD to /TR
16:34:41 [fantasai]
dbaron: There's been some minor tweaks
16:34:48 [fantasai]
dbaron: and the addition of a bunch of OM stuff to spec
16:34:49 [dbaron]
16:35:08 [fantasai]
dbaron: Want to discuss mainly OM stuff today
16:35:29 [fantasai]
dbaron: One piece is relatively straightforward, 8.1 is numbers, we used 12 and 13
16:35:35 [fantasai]
dbaron: 8.2 is relatively straightforward
16:35:54 [fantasai]
dbaron: in that we already have an interface for MediaRule that has all but the first attribute here
16:36:03 [fantasai]
dbaron: instead of conditionText it has mediaText
16:36:11 [fantasai]
dbaron: 1. Is conditionText right
16:36:24 [fantasai]
dbaron: 2. Do we want a parent interface on which the bottom three are shared
16:36:58 [fantasai]
glazou: We ask browser if it supports a property and a value
16:37:12 [fantasai]
Tab: No, it's more than that -- it's conjunctions with and/or/not, not just a sigle property declarations
16:37:23 [fantasai]
Tab: You could make a tree structure for it, but I don't know how valuable that is
16:37:30 [fantasai]
dbaron: Doubles implementation work of @supports
16:37:41 [fantasai]
Florian: Let's not do that until someone asks for it
16:37:53 [fantasai]
dbaron: I named it conditionText to match a bunch of other things that end in Text in the OM
16:38:49 [fantasai]
fantasai: Question, it's medaiText for MediaRule, why is it conditionText for SupportsRule?
16:39:08 [fantasai]
Tab: you're thinking it should be supportsText?
16:39:43 [fantasai]
Tantek: Seems confusing, asking if it "supports Text"
16:40:23 [fantasai]
fantasai: But all these things are condition rules, why is only this one called conditionText
16:40:49 [fantasai]
Florian: Would be nice if all three rules used conditionText
16:41:07 [fantasai]
dbaron: I think mediaText is in the other chapter of DOM 2 Style...
16:41:43 [fantasai]
Florian: So .media.mediaText could be equivalent to .conditionText
16:41:52 [fantasai]
Florian: And have all of them have .conditionText
16:42:17 [dbaron]
Daniel: So for @media, .media.mediaText and .conditionText would be equivalent?
16:42:25 [fantasai]
dbaron: yes
16:42:37 [fantasai]
glazou: for both getting and setting?
16:42:39 [fantasai]
dbaron: yes
16:43:05 [fantasai]
glazou: Wrt additional interface, would that get implemented?
16:43:13 [fantasai]
(additional common interface)
16:43:34 [fantasai]
dbaron: My inclination would be to put it in the spec and mark it at risk
16:43:52 [dbaron]
16:44:31 [fantasai]
Florian: Back on conditionText itself, need to define how serialization works
16:44:43 [fantasai]
Florian: In your stylesheet, if you have not not not, do you collapse into one not?
16:44:51 [fantasai]
Tab: Are you allowed to do logical simplifications
16:44:55 [fantasai]
Florian: I'd like to simplify
16:44:59 [fantasai]
Tab: I'm ok with that
16:45:31 [fantasai]
Florian: also multiple nested parens that don't do anything, can you collapse that
16:45:43 [fantasai]
dbaron: Don't want to require that ...
16:45:50 [fantasai]
Florian: Want to have identical serializations across browsers
16:46:05 [fantasai]
dbaron: We wanted to use a token string
16:46:17 [fantasai]
Florian: We copy the string exactly from the style sheet
16:46:26 [fantasai]
Florian: ... we simplify
16:46:34 [fantasai]
dbaron: I don't think there's a need to simplify
16:46:39 [fantasai]
dbaron: It's extra code on our end to simplify
16:46:49 [fantasai]
Florian: In my case what I wrote was the easiest implementation
16:47:26 [fantasai]
Glenn: Need to define this if you want to test it
16:47:44 [fantasai]
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 [fantasai]
Florian talks about preserving invalid conditions
16:48:23 [dbaron]
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 [fantasai]
Glenn: What about white space and comments?
16:49:03 [fantasai]
fantasai points to the current spec, which has a proposal
16:49:25 [fantasai]
dbaron: I think in order to preserve semantics, you need to preserve where comments are, if not what's in them
16:49:36 [fantasai]
Florian: Seems easier to just pass through the string
16:50:09 [fantasai]
glazou: So you empty the comments, and report back an empty comment?
16:50:18 [fantasai]
Florian: No, if we do this, we'd preserve the comment
16:50:53 [fantasai]
dbaron: Sounds like we both implemented at a layer above the tokenizer, went back to stylesheet and pulled out the text
16:51:05 [fantasai]
glazou: Still match curly braces etc?
16:51:26 [fantasai]
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 [fantasai]
glazou writes on the board:
16:52:20 [fantasai]
@supports (foo: {;};);
16:52:57 [fantasai]
dbaron: That's syntactically because of the second semicolon... and the third semicolon
16:53:03 [fantasai]
glazou errases that and writes
16:53:13 [fantasai]
@supports (foo: {;} blah)
16:53:18 [fantasai]
glazou: Catch everything correctly?
16:53:20 [fantasai]
dbaron: yeah
16:53:29 [fantasai]
Florian writes
16:53:39 [fantasai]
@supports (foo: {;} blah) and (bar:baz)
16:53:55 [fantasai]
Florian: We preserve the contents of the parens, but we parse and normalize the structure around it
16:54:21 [fantasai]
Florian adds more parens and double nots, points out that they get simplified out
16:54:36 [fantasai]
dbaron: We don't preserve any structure
16:55:38 [fantasai]
Florian discusses .condition, which would have a tree structure, and whether that should be simplified
16:55:45 [fantasai]
plinss thinks it's better not to simplify
16:56:10 [fantasai]
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 [fantasai]
glazou: I think I prefer dbaron's approach
16:56:56 [fantasai]
glazou: Being able to read back the condition exactly as the author wrote it is good
16:57:11 [fantasai]
Glenn: what about the case when you construct via script?
16:57:19 [fantasai]
dbaron: It's the same
16:58:08 [fantasai]
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 [fantasai]
dbaron: And would be allowed to drop contents of a comment, could do so
16:58:24 [fantasai]
dbaron: They can't drop the comment
16:58:40 [fantasai]
glazou: I would prefer if you don't do that
16:58:58 [fantasai]
Tab: Would prefer to do that, because otherwise you have to go back to the source text
16:59:13 [fantasai]
Tab: Once you have a parse tree, theoretically you should be able to kill the source text
16:59:36 [fantasai]
Tab: The exact source text doesn't exist in the parse tree, because the parse tree is made of tokens
17:00:59 [fantasai]
Tab: Implementations that don't preserve the source text should be able to implement this
17:01:45 [fantasai]
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_]
TabAtkins_ has joined #css
17:01:54 [ChrisL]
ChrisL has joined #css
17:02:26 [glazou]
glazou: I want to read the proposal before accepting it
17:03:23 [fantasai]
RESOLVED: Have intermediary condition rule interface
17:03:28 [fantasai]
(name TBD)
17:03:51 [fantasai]
Discussion of grouping rules (contain declarations) vs. others?
17:04:04 [fantasai]
Tab: Need to look at @keyframes
17:04:14 [fantasai]
plinss: @page
17:04:51 [dbaron]
RESOLVED: .conditionText goes on that common interface
17:04:55 [fantasai]
RESOLVED: conditionText on the common interface, for @media is equivalent to .media.mediaText
17:05:21 [fantasai]
glazou: If it's conditionText, should be ConditionRule
17:05:27 [fantasai]
glazou: to be consistent
17:05:51 [fantasai]
RESOLVED: CSSConditionRule
17:05:52 [dbaron]
(Tab suggests we have GroupRule and ConditionRule.)
17:06:30 [fantasai]
RESOLVED: conditionText returns either the token stream or source text from the style rule, with no logical simplifications, just tokenization ones
17:06:47 [dbaron]
(i.e., could optionally collapse whitespace or drop contents of comments)
17:07:21 [fantasai]
jdaggett: What should we be doing for new @rules, are we defining a specific serialization?
17:07:25 [fantasai]
Florian: This one is pretty specific
17:07:36 [fantasai]
glazou: I suggest we take that question to the OM discussion
17:08:25 [fantasai]
glazou: DocumentRule?
17:08:38 [fantasai]
Florian: have to decide normalization of conditionRule for URLs
17:08:54 [fantasai]
dbaron: normalization of urls is hard, might require us to drop @document from the spec atm
17:09:13 [fantasai]
dbaron: 9.3 is OM interface to do @supports queries
17:09:35 [fantasai]
dbaron: I feel strongl that this should not allow logical combinations, because JS can do that
17:10:17 [fantasai]
glazou: We had the exact discussion with matchMedia, and came to the exact opposite conclusion
17:10:50 [fantasai]
glazou: supportsCSS is good as it is, maybe we need another interface too
17:11:03 [fantasai]
Tab: We did the entire media query for matchMedia so that you could attach a listener
17:11:17 [fantasai]
glazou: I agree, but from an author's perspective
17:12:12 [fantasai]
17:12:25 [fantasai]
sylvaing: People will want to pull from conditionText and put it into the matching function.
17:12:41 [fantasai]
Tab: you can't interchange media queries and support queries
17:12:51 [fantasai]
Tab: There are some that look identical
17:13:33 [fantasai]
fantasai: So, the comment I have here is that supportsCSS seems very general, but this only takes a property-value pair
17:13:43 [fantasai]
Tab wants the name to be short
17:14:06 [fantasai]
sylvaing: Is there any objection to the functionality here?
17:14:17 [fantasai]
glenn: Do you want to query a property with any value?
17:14:23 [fantasai]
Tab: We are specifically *not* doing that.
17:15:02 [fantasai]
glenn: I'm ok with the functionality, concerned about where it is atteched (window object)
17:15:35 [fantasai]
glenn: Could attach to navigator
17:15:38 [fantasai]
17:15:42 [fantasai]
17:15:51 [fantasai]
Tab: I propose creating a new CSS object and attaching it to that
17:16:08 [fantasai]
Tab: Right now the constructors for everything else have enormous names, e.g. CSSPixelValue
17:16:17 [fantasai]
Tab: would be nice to be able to say CSS.px()
17:16:34 [fantasai]
Florian: 3 acceptable proposals to me: window, navigator, or what Tab is saying
17:16:46 [fantasai]
fantasai agrees with Florian
17:17:47 [fantasai]
Glenn: Keep in mind that properties on window are shadowable
17:18:08 [fantasai]
dbaron: That was true in ECMA262 Edition 5, which was regresion from Edition 3, and was fixed in 5.1
17:19:26 [fantasai]
fantasai: [...]
17:19:39 [fantasai]
dbaron: want to avoid supportsProperty because ECMA uses properties
17:20:06 [fantasai]
dbaron: Could be ok with supportsCSSValue
17:20:13 [fantasai]
Florian: CSS.supportsValue
17:20:17 [fantasai]
Florian: Still reasonably short
17:20:37 [fantasai]
fantasai^: Would expect CSS.supports() to be the function that takes the whole @supports condition string
17:20:38 [stearns]
+1 to supportsValue
17:21:57 [fantasai]
some meta-discussion
17:22:28 [fantasai]
Florian points out it is being implemented now
17:23:07 [fantasai]
jdaggett is not buying this argument, we get a lot of this situation of implementing things in editor's drafts
17:24:16 [fantasai]
fantasai proposes compiling list of proposals, posting to www-style, discussing over breaks, and revisiting later
17:24:39 [fantasai]
Bert: Does window always exist?
17:24:50 [fantasai]
Tab: A global object exists, and for compat reasons it's called window
17:25:35 [fantasai]
0. window.supportsCSS()
17:25:40 [fantasai]
1. CSS.supportsValue()
17:25:52 [TabAtkins_]
2. CSS.supports()
17:26:02 [hober]
17:26:08 [fantasai]
17:26:19 [fantasai]
ACTION glazou: email www-style
17:26:19 [trackbot]
Created ACTION-489 - Email www-style [on Daniel Glazman - due 2012-08-20].
17:27:11 [fantasai]
Florian: Issue -- you strip WS at the ends, do you also strip comments?
17:27:37 [fantasai]
dbaron: You trim the property name, because it has to be a property name
17:28:01 [fantasai]
Florian: So, around value, whatever, around property, nothing. Ok
17:28:49 [fantasai]
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 [fantasai]
Bert: Is the property normalized?
17:29:09 [fantasai]
fantasai: What about escapes
17:29:26 [fantasai]
dbaron: You're not parsing CSS, just taking a property name
17:29:39 [fantasai]
Bert: Unicode normalization?
17:30:08 [fantasai]
Tab: Not an issue, our properties are all ASCII
17:30:15 [fantasai]
sylvaing: What if you pass in a variable name?
17:30:39 [fantasai]
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 [fantasai]
glazou asks about tests
17:30:59 [fantasai]
Opera has submitted theirs, Mozilla needs to submit theirs
17:31:11 [fantasai]
O(100) tests
17:31:45 [dbaron]
that's the same as O(1)
17:50:19 [Koji]
Koji has joined #css
17:51:20 [stearns]
my word-count/test ratio heuristic says that css3-conditional will need 334 tests
17:52:17 [vhardy_]
vhardy_ has joined #css
17:52:28 [vhardy__]
vhardy__ has joined #css
17:53:55 [smfr]
smfr has joined #css
17:56:59 [fantasai]
Tab: So, fantasai Florian and I have a suggestion
17:57:18 [fantasai]
Tab: We like CSS.supports(), but it implies very generic, so have that take the conditionText of a supports rule
17:57:56 [fantasai]
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]
fantasai: For two-value, was it CSS.supportsValue()?
17:58:51 [fantasai]
Florian: No, CSS.supports() with two arguments it works as currently defined
17:58:59 [dbaron]
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 [fantasai]
dbaron: I'm worried that creating this CSS object might be more controversial
17:59:21 [fantasai]
dbaron: But I'm ok with giving it a try
17:59:37 [fantasai]
hober: Concerned about compat with random websites that use CSS as a global
17:59:49 [dbaron]
Tab: If CSS doesn't work, ok with reverting to window.suppportCSS
17:59:49 [fantasai]
Glenn prefers CSSStyleRule.supports
18:00:18 [fantasai]
Tab: We wouldn't look at that until testing support for @rules anyway
18:00:26 [fantasai]
szilles: It isn't CSS supports, its UA supports
18:02:00 [fantasai]
RESOLVED: CSS.supports() with one (conditionText-compatible) or two (property, value) arguments. Fall back to window.supportsCSS if not possible.
18:02:08 [fantasai]
ACTION TabAtkins: ask WebApps about global CSS object
18:02:08 [trackbot]
Sorry, couldn't find user - TabAtkins
18:02:09 [dbaron]
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 [dbaron]
ScribeNick: dbaron
18:02:51 [dbaron]
Topic: Selectors4
18:03:58 [glazou]
18:04:32 [fantasai]
18:04:53 [dbaron]
fantasai: some changes since we last discussed this
18:05:01 [dbaron]
fantasai: scoped selectors (3.3): we defined 2 ways of scoping selectors
18:05:15 [dbaron]
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 [dbaron]
fantasai: Updated prose for :scope pseudo-class.
18:05:42 [dbaron]
Tab: If someone can come up with better names than contained and constrained, that would be appreciated. Not different enough.
18:06:15 [dbaron]
glazou: querySelector on an element?
18:06:23 [dbaron]
fantasai: yeah, example 2 should refer to Element.querySelector()
18:06:41 [dbaron]
fantasai: Other change to discuss is 8.4: :valid-drop-target
18:07:13 [dbaron]
fantasai: We resolved to add this.
18:07:36 [dbaron]
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 [dbaron]
glazou: :valid-drop-target:active ?
18:07:57 [dbaron]
fantasai: It's not being activated right now.
18:08:12 [dbaron]
glazou: Like when you click and haven't released the button yet
18:08:26 [dbaron]
fantasai: I think it would be more confusing.
18:08:37 [dbaron]
fantasai: I looked over other suggestions in the minutes, other suggestions were :active-drop-target
18:08:51 [dbaron]
fantasai: We switched in order to distinguish between valid and invalid drop targets.
18:09:03 [dbaron]
fantasai: But that seems a bit abstract. I think Sylvain's issue is more important.
18:09:27 [dbaron]
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 [dbaron]
[discussion about invalid vs. not drop target]
18:10:55 [dbaron]
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 [dbaron]
glazou: Behavior you describe is not in conformance to mouse clicks
18:11:46 [dbaron]
glazou: I think :valid-drop-target:active is better
18:11:50 [dbaron]
glazou: Need :dropped
18:12:12 [dbaron]
fantasai: Original request is what will recieve the drop if I let it go
18:12:24 [dbaron]
fantasai: I don't want to have to combine pseudos for this
18:13:05 [dbaron]
Tantek: other name suggestions from cursor:no-drop
18:13:19 [cabanier]
cabanier has joined #css
18:13:48 [dbaron]
fantasai: If we went with that, :active-drop, :drop, :no-drop
18:14:32 [arronei_]
how about :drop-target and :no-drop-target
18:14:33 [dbaron]
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 [dbaron]
Tab: [speaking at >150wpm]
18:14:59 [fantasai]
arronei, I like :active-drop and :drop, they're nice and short
18:15:08 [fantasai]
arronei, the -target part doesn't seem necessary
18:15:14 [dbaron]
Tab: The :invalid pseudo-classe doesn't apply to all the dom, only things with validity constraints.
18:15:57 [arronei_]
just saying :drop isn't explicit enough in my opinion
18:16:31 [arronei_]
does it mean I can drop something or I am dropping something?
18:17:00 [dbaron]
Bert: difference between :active-drop and :drop:hover ?
18:17:14 [dbaron]
fantasai: might not need to actually be inside the boundary
18:17:16 [dbaron]
18:17:38 [dbaron]
fantasai: Solitaire on windows actually has two options for this behavior: can go to the closest one
18:17:49 [dbaron]
Bert: at least cover a part of it?
18:17:52 [dbaron]
fantasai: not in all interfaces
18:18:11 [dbaron]
Florian: [asked Q]
18:18:38 [dbaron]
Florian: difference between :drop:hover and :active:drop -- in theory? in practice?
18:18:40 [tantek]
18:18:49 [dbaron]
fantasai: [really fast]
18:19:16 [dbaron]
ack dbaron
18:19:16 [fantasai]
dbaron: You might not be triggering :hover at all with drag and drop
18:19:25 [dbaron]
ack tantek
18:19:30 [fantasai]
fantasai explaining that interfaces might trigger drops even if not hovering
18:19:35 [fantasai]
e.g. solitaire on windows
18:19:37 [dbaron]
Tantek: I think this use of :active is a different semantic from :active elsewher
18:19:58 [dbaron]
Tantek: bad from teaching perspective. Closer to :hover than :active.
18:20:07 [dbaron]
Florian: :current-drop ?
18:20:18 [dbaron]
Tantek: with some drag&drop interfaces, button might not be down
18:20:35 [dbaron]
Tab: I like :can-drop
18:20:41 [dbaron]
Florian: That's :drop, not :active-drop
18:20:59 [dbaron]
fantasai: :will-drop, :can-drop, :no-drop
18:21:11 [dbaron]
fantasai: :current-drop, :can-drop, :no-drop
18:22:00 [dbaron]
Tantek: :can-drop, :drop, :no-drop
18:22:29 [Koji]
Koji has joined #css
18:22:37 [dbaron]
(these are in order of replacing :active-drop-target, :valid-drop-target, :invalid-drop-target)
18:22:55 [dbaron]
fantasai: :drop, :can-drop, :no-drop
18:23:11 [dbaron]
Florian: :current-drop, :valid-drop, :invalid-drop
18:23:37 [dbaron]
Florian: I don't like :no-drop because it sounds like it includes things that aren't drop targets.
18:24:06 [dbaron]
Peter: but value in being consistent with cursor
18:24:18 [dbaron]
?: no-drop cursor could be used where not a drop target
18:24:22 [dbaron]
Tantek: That's not how it's used in UIs.
18:24:30 [dbaron]
glazou: I'm not seeing this discussion going anywhere.
18:24:48 [dbaron]
fantasai: I like these 2, these 2 ok, really don't like these 2.
18:25:22 [dbaron]
now down to:
18:25:29 [dbaron]
:active-drop, :drop, :no-drop
18:25:34 [dbaron]
:drop, :can-drop, :no-drop
18:25:44 [dbaron]
:current-drop, :valid-drop, :invalid-drop
18:26:05 [dbaron]
Steve: I don't like :drop
18:26:27 [dbaron]
ACTION fantasai to email www-style about the possiblities
18:26:27 [trackbot]
Created ACTION-490 - Email www-style about the possiblities [on Elika Etemad - due 2012-08-20].
18:26:37 [dbaron]
Florian: I suggest putting all 3 in the spec
18:27:00 [florian]
and put the later two at risk
18:27:02 [dbaron]
fantasai: Next thing for discussion is :user-error (11.5)
18:27:08 [drublic]
drublic has joined #css
18:27:29 [dbaron]
fantasai: We had proposal for :-moz-ui-invalid, :invalid limited to when user has already interacted with it.
18:27:41 [dbaron]
fantasai: Mozilla has some heuristics for when :-moz-ui-invalid is triggered
18:27:54 [dbaron]
fantasai: But the ideas it do it when you actually want to highlight things as invalid.
18:28:31 [dbaron]
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 [dbaron]
glazou: In case of elements implemented by UA, I understand. What about elements implemented by the Web author?
18:29:11 [dbaron]
Tab: setCustomValidity can do that
18:29:33 [TabAtkins_]
dbaron: The problem we're dealign with here is that some elements are invalid when they haven't yet received input.
18:29:49 [TabAtkins_]
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 [TabAtkins_]
dbaron: the form cant' be submitted in that state.
18:30:10 [TabAtkins_]
dbaron: But you still need to know when the control has received input.
18:30:21 [dbaron]
need an API for that
18:30:43 [dbaron]
Tab: Not sure that's necessary here because if it's a custom control, you can put a class on it
18:31:29 [dbaron]
fantasai: [reads definition of :user-error]
18:31:47 [glazou]
Tab's prose has :user-error :-)
18:33:12 [dbaron]
dbaron: [explains rationale for :-moz-ui-invalid]
18:33:55 [dbaron]
fantasai: In terms of custom controls, you want it to really be invalid whenever it's invalid.
18:34:15 [dbaron]
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 [dbaron]
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 [dbaron]
Tantek: If we're actually trying to fix this properly, we might want to consider this orthogonal pseudo-class.
18:35:23 [dbaron]
Tantek: That was the context of the discussions about how :-moz-ui-invalid came to be.
18:35:42 [dbaron]
fantasai: I'm happy to spec whatever you want to implement.
18:35:48 [dbaron]
Bert: Sounds like :fresh
18:35:51 [dbaron]
Tantek: or the opposite
18:36:01 [dbaron]
Tantek: :user-dirtied
18:36:05 [dbaron]
fantasai: :user-interacted
18:36:25 [dbaron]
Tantek: A little vaguely defined -- tabbing through, clicking and then clicking elsewhere
18:36:36 [dbaron]
Tantek: Don't want prematurely precise specification.
18:37:35 [dbaron]
Tantek: ... distinguish between user-interacted with form or interacted with element?
18:37:48 [dbaron]
Peter: We can't know what all possible ways of interaction will be over next 10 years.
18:38:03 [dbaron]
Tantek: specify a simpler thing that designers can combine to get effects
18:38:13 [dbaron]
fantasai: I think we should spec :user-error
18:38:27 [isherman]
isherman has joined #css
18:38:38 [dbaron]
fantasai: e.g., because we need things to be highlighted after user tries and fails to submit form
18:38:59 [dbaron]
fantasai: I think we should spec this, and add that later when more concrete
18:39:06 [leaverou_]
leaverou_ has joined #css
18:39:12 [dbaron]
Tantek: This is just as concrete -- just the same thing without the intersection with :invalid
18:40:50 [dbaron]
Florian: How do you select thing when user pressed submit, failed, and the user never interacted with control?
18:42:06 [dbaron]
[lots of fast talking]
18:42:34 [dbaron]
fantasai: could split out :user-omitted and :user-invalid
18:42:54 [dbaron]
Florian: I'd like to have :user-error and also have what Tantek suggested
18:42:58 [dbaron]
Florian: ...
18:43:02 [dbaron]
Tab: That's placeholder
18:43:30 [dbaron]
Tantek and Tab argue about how form UIs are designed
18:43:40 [dbaron]
fantasai: Any objections to adding :user-error as is?
18:43:51 [dbaron]
Bert: Can we add something like what Tantek said?
18:44:00 [dbaron]
Tantek: I'd like to also mention :user-interacted
18:44:07 [dbaron]
fantasai: I think it's separate
18:44:16 [dbaron]
Tantek: Potentially makes :user-error unnecessary.
18:44:43 [dbaron]
RESOLVED: Have :user-error as-is, and have an issue about :user-interacted.
18:44:56 [dbaron]
Tab: Next up is the minor changed to the reference combinator.
18:45:10 [dbaron]
Tab: We changed this to allow host languages to...
18:45:19 [dbaron]
Tab: Before, attribute had to be IDREF or ID selector.
18:45:30 [dbaron]
Tab: Now, have use cases from Web Components that want more ways to match.
18:45:46 [dbaron]
Tab: Host language can define alternate ways (e.g., full selectors).
18:45:56 [dbaron]
glazou: reference combinator badly needed for epub
18:46:26 [dbaron]
fantasai: Then the column combinator (14.1)
18:46:40 [dbaron]
18:46:52 [dbaron]
fantasai: this is a combinator, not a pseudo-class (as it was in previous draft)
18:47:07 [dbaron]
fantasai: needs knowledge of the host language
18:47:33 [dbaron]
fantasai: anything with a tabular structure and a row-major table
18:47:45 [dbaron]
fantasai: In a column-major model, it's a row combinator.
18:47:53 [dbaron]
glazou: The // are really too similar to a reference combinator.
18:48:02 [dbaron]
glazou: why not || ?
18:48:08 [dbaron]
Tab: Intended to look like a reference combinator
18:48:22 [dbaron]
glazou: I don't want 2 things, one with keyword inside and the other without keyword inside.
18:48:28 [dbaron]
fantasai: I'm happy with either option.
18:48:42 [dbaron]
glazou: I'm happy with anything, but these really look too similar.
18:49:38 [dbaron]
dbaron: I think I'm not happy with the change from pseudo class to combinator, but I don't remember why
18:50:24 [dbaron]
fantasai: pseudo-class would create branching structure
18:50:28 [dbaron]
ack dbaron
18:51:03 [dbaron]
fantasai: Combinator intended to express relationship between elements, not pseudo-class.
18:51:49 [dbaron]
glazou: Impossibility to use :nth-child() and friends to style rows and columns with spans.
18:51:59 [dbaron]
dbaron: There's another selector here for that.
18:52:24 [fantasai]
dbaron: concerned wrt perf for combinator rather than pseudo-class
18:52:30 [Bert]
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 [fantasai]
dbaron: authors will tend to write the faster option with the pseudo-class, but the slower with the combinator
18:53:03 [fantasai]
dbaron: Now that UAs have implemented filtering for descendant combinators
18:53:13 [fantasai]
dbaron: maybe that's not a huge problem...
18:53:21 [fantasai]
dbaron: Another perf problem I forget
18:53:44 [dbaron]
glazou: Alan and I wrote a document for pseudo-elements.
18:54:13 [dbaron]
glazou: at some point want to eliminate restriction on other selectors to the right of pseudo-element
18:54:34 [dbaron]
glazou: and then we could have the column as a pseudo-element and have selectors inside the table
18:55:06 [fantasai]
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 [fantasai]
ACTION fantasai: summarize all issues raised here into the draft
18:55:56 [trackbot]
Created ACTION-491 - Summarize all issues raised here into the draft [on Elika Etemad - due 2012-08-20].
18:56:11 [dbaron]
Sylvain: This is dependent on document-language constructs?
18:56:12 [dbaron]
fantasai: yes
18:56:28 [dbaron]
fantasai: So wouldn't apply to grids, applies to table elements, not display:table.
18:56:35 [dbaron]
fantasai: So, determining the subject of a selector
18:56:42 [dbaron]
fantasai: Discussion on the list about syntax.
18:56:56 [dbaron]
fantasai: Currently using an ! after the subject of the selector.
18:57:20 [dbaron]
fantasai: Seemed better to append it because it splits the selector better when appended.
18:57:52 [dbaron]
fantasai: We need to put something on the compound selector, and it either needs to be before or after.
18:58:17 [dbaron]
glazou: Implemented this in STTS 14 years ago.
18:58:26 [dbaron]
glazou: Want ! at beginning because it's visible; hard to see at end.
18:58:35 [dbaron]
fantasai: ! at beginning also looks like "not"
18:58:56 [drublic]
drublic has joined #css
18:59:09 [dbaron]
glazou: Everybody confused by !important, but everybody using it without a problem.
18:59:35 [dbaron]
fantasai: We need something either before or after subject.
18:59:40 [dbaron]
fantasai: How does this work with pseudo-elements?
18:59:59 [dbaron]
glazou: Alan and I extracted pseudo-elements spec from selectors4.
19:00:25 [dbaron]
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 [dbaron]
glazou: I think extraction of pseudo-elements makes sense.
19:01:09 [dbaron]
glazou: Pseudo-elements spec has informative, brief description of syntax.
19:01:54 [dbaron]
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 [dbaron]
Sylvain: Did we talk about :lang updates
19:02:12 [dbaron]
fantasai: I was goin to in Hamburg, but forgot
19:02:24 [dbaron]
fantasai: :lang() now accepts comma-separated list, and wildcard matching for BCP47
19:03:03 [dbaron]
Florian: This was valuable for Metro?
19:03:09 [dbaron]
Sylvain: Yes, can make style sheets a lot shorter.
19:03:50 [dbaron]
fantasai: Are people ok with this?
19:04:24 [sylvaing]
in scenarios where the content supports many languages - web apps/widgets, ebooks - this significantly shortens selectors
19:04:41 [dbaron]
fantasai: Edits tonight, and maybe we can resolve to publish tomorrow?
19:06:06 [dbaron]
Tantek: Maybe capture ! syntax as an issue and publish that way?
19:06:09 [dbaron]
glazou: I'm not ok with that
19:06:19 [dbaron]
fantasai: I'd like to resolve this issue or drop the feature.
19:06:44 [dbaron]
glazou: I want it specified as prepend, though I'm ok with an issue noting that it's an issue.
19:06:56 [dbaron]
Peter: Or we could do both.
19:07:03 [dbaron]
Tab: Do we expect this to be implemented in normal CSS?
19:07:05 [vhardy_]
vhardy_ has joined #css
19:07:14 [dbaron]
did peter mean "before or after" or "before and after"?
19:07:25 [fantasai]
19:07:32 [dbaron]
Tab: I'd like to move this to a profile for batch processors.
19:07:35 [plinss]
before and after
19:07:48 [dbaron]
glazou: Top user feedback since 1998.
19:08:25 [dbaron]
fantasai: Do we want profiles for dynamic and non-dynoamic?
19:08:36 [dbaron]
glazou: we already have some profiles
19:09:01 [dbaron]
fantasai: I'll create a profile that excludes it from dynamic
19:09:30 [dbaron]
RESOLVED: ! before the selector (with issue about after)
19:09:38 [dbaron]
Bert: Append with a space between?
19:10:21 [dbaron]
€ul > li:only-child
19:10:56 [dbaron]
Tab: Being able to style a column when you hover it isn't addressed by anything.
19:11:02 [dbaron]
Tab: Because the column element isn't in :hover
19:11:34 [dbaron]
glazou: stuff on the right of pseudo-element!
19:11:59 [dbaron]
RESOLVED: publish new WD of selectors4
19:12:05 [dbaron]
<br type="lunch">
19:13:19 [Koji_]
Koji_ has joined #css
19:31:51 [jet]
jet has joined #CSS
19:45:48 [Koji]
Koji has joined #css
20:11:18 [jet]
jet has joined #CSS
20:15:54 [fantasai]
ScribeNick: fantasai
20:16:23 [fantasai]
Tab: I was thinking about asking for FPWD, but think it's not quite ready yet
20:16:39 [fantasai]
Tab: The purpose of bringing up here is to explain reasoning between having syntax draft
20:16:50 [fantasai]
Tab: and get objections / feedback up front rather than later
20:17:10 [fantasai]
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 [fantasai]
Tab: There are some things that are officially undefined
20:17:31 [fantasai]
Tab: Even some cases defined, there are coner cases that are handled differently by different browsers
20:17:43 [fantasai]
Tab: What I've done instead, instead of using a grammar, is to define in terms of a state machine parser
20:17:51 [fantasai]
Tab: Broken up into 2 steps like HTML parsing algo
20:17:56 [fantasai]
Tab: Fist step is tokenizer, other is parser
20:18:04 [fantasai]
Tab: resulting in a CSS OM
20:18:12 [fantasai]
Tab: Goal is to make everything extremely well-defined
20:18:17 [fantasai]
Tab: Also make it easy to modify,
20:18:28 [fantasai]
Tab: And easy to read and understand
20:18:39 [fantasai]
Tab asks dbaron for feedback
20:18:58 [fantasai]
dbaron: Some of it, I just don't quite understand what states your state machine goes through in the parser
20:19:02 [fantasai]
dbaron: Not so worried about tokenizer side
20:19:28 [fantasai]
Tab: There's a top-level state, and then 3 substates: at-rule, selector, ..
20:19:37 [fantasai]
Tab: at-rule mode or selector mode, depending on what is seen
20:19:47 [glazou]
20:20:12 [fantasai]
Tab: parser very easy to write, took me about a day. Tokenizer took about a week
20:20:25 [fantasai]
dbaron: Part of what worries me is that
20:20:36 [fantasai]
dbaron: defining correct error recovery with this parser spec
20:20:47 [fantasai]
dbaron: we have a bunch of abstract error-recovery rules, we know exactly what they mean
20:20:59 [fantasai]
dbaron: With this spec, seems easy to get the error-recovery rules wrong in the spec
20:21:09 [fantasai]
Tab: Differing implementations of those rules
20:21:25 [Rossen]
Rossen has joined #css
20:21:27 [fantasai]
dbaron: Because easy to make mistakes in the implementation
20:21:47 [fantasai]
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 [fantasai]
dbaron gives an example of matching curly braces
20:22:14 [fantasai]
dbaron: If you describe that as an abstract rule, you describe it and you're done
20:22:30 [fantasai]
dbaron: If you do it as a state machine, you need to fall into that out of many different states
20:22:43 [fantasai]
Tab explains how he handles it
20:22:45 [fantasai]
in the spec
20:23:02 [fantasai]
Tab: I think I've handled that correctly
20:23:23 [fantasai]
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 [fantasai]
Tab: I think I've defined it in away that you get it for free
20:23:37 [fantasai]
dbaron talks about a stack of stacks
20:23:50 [fantasai]
dbaron: Stack defines recovery points
20:23:58 [fantasai]
Tab: Initial concept is stacks, where you can enter an error
20:24:17 [vhardy_]
vhardy_ has joined #css
20:24:22 [fantasai]
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 [fantasai]
dbaron: We should probably sit down together some other time
20:24:53 [fantasai]
Tab: There are some minor changes to the grammar, discussed by the group
20:25:06 [fantasai]
Tab: Including the plus-or-minus sign direction in the definition of NUMBER token
20:25:43 [fantasai]
Tab: Group resolved to include that already
20:26:01 [fantasai]
Tab: A few other places with corner cases or inconsistencies. Need to list them
20:26:28 [fantasai]
Florian: Didn't you discuss at some point not accepting comments between ! and important?
20:26:45 [fantasai]
Tab: One issue that makes parser hard to handle right now... gives parser infinite lookahead
20:26:53 [fantasai]
Tab: Appears we need to retain comments in token stream
20:27:06 [fantasai]
Tab: Then you can have unlimited number of tokens between ! and important
20:27:23 [fantasai]
Tab: !/*comment*/ /*... */ /*...*/important
20:27:39 [fantasai]
Tab: ...
20:27:47 [fantasai]
dbaron: I don't see what you mean here.
20:27:53 [fantasai]
dbaron: why is this lookahead?
20:28:00 [fantasai]
dbaron: You get a !
20:28:06 [fantasai]
dbaron: you go into "parsing !important" path
20:28:16 [fantasai]
dbaron: Either you get identifier "important"
20:28:26 [fantasai]
dbaron: Or you get something else, in which case you go into error condition
20:28:50 [fantasai]
Tab: Issue is, it's not always an error
20:29:01 [fantasai]
Tab: could have it in a variable
20:29:07 [fantasai]
dbaron: Think we should change it so ! can't show up in a variable
20:29:24 [fantasai]
Tab: ! would be counted as a delim, which is a valid part of a variable
20:29:47 [fantasai]
20:29:59 [fantasai]
dbaron: Don't think saying you can't have a ! in variable prevents [that]
20:30:10 [fantasai]
Tab: Then I'd have to be more explicit in the grammar
20:30:20 [fantasai]
Tab: Before, just match value production, and everything worked
20:30:54 [fantasai]
20:31:08 [fantasai]
Florian: Do people put comments between '!' and 'important'?
20:31:44 [fantasai]
glazou: You should check
20:31:51 [fantasai]
Bert: I don't think we need to check, there's no reason to change it
20:32:14 [fantasai]
Tab: Plan to ask FPWD within next 2-3 weeks
20:32:19 [fantasai]
Tab: Please bring up objectins on the list beforehand
20:32:32 [fantasai]
Bert: Would like the grammar normative, not the state machine
20:32:38 [fantasai]
Tab: I would like the opposite
20:33:35 [fantasai]
Tab: If the grammar doesn't cover every possible input stream, then it's not well-defined error recovery
20:33:45 [fantasai]
Bert: I don't care about those
20:33:49 [fantasai]
jdaggett: Why not?
20:34:17 [fantasai]
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 [fantasai]
Bert: But all of those are within the core grammar
20:34:46 [fantasai]
Bert: original model was only to define correct style sheets, slowly been adding more rules to handle errors
20:34:58 [fantasai]
Tab: I care that we define all error-handling
20:35:05 [fantasai]
Florian: And all interpret them the same way
20:35:26 [fantasai]
Florian: For HTML parsing, having common CSS handling has been important to get interop
20:35:32 [fantasai]
Florian: Think the situation is not as bad for CSS
20:35:46 [fantasai]
Florian: I'm tempted to go this way, though I don't think we need it as badly as HTML
20:36:10 [fantasai]
Tab: We have inconsistent/poorly-explained rules for handling e.g. braces. Want to make this obvious and clear.
20:36:26 [fantasai]
s/braces/braces in unexpected places/
20:36:38 [fantasai]
Tab: Can implement as not a state machine
20:36:47 [fantasai]
Tab: as long as results match
20:37:03 [fantasai]
Bert: Can't, if it's a state machine have to parse in start-to-end order
20:37:20 [fantasai]
Bert: Proving this one is the same as the CSS2.1 grammar is going to be hard
20:37:27 [fantasai]
Tab: Plan to throw lots of tests at it
20:37:48 [fantasai]
Bert: We need to prove the spec, not the implementations here
20:38:04 [fantasai]
Bert: Looks like a big step backwards to replace one page of nice grammar with however many pages of text
20:38:19 [fantasai]
Tab: The one page of nice grammar isn't interpretable by normal people without help from the CSSWG
20:38:49 [fantasai]
sylvaing: Implementers prefer this (the state machine)
20:39:29 [fantasai]
Bert: Context-free grammars were meant to replace this kind of thing
20:39:41 [fantasai]
Tab: Context-free is great for things like properties, where once it's invalid, you're done
20:40:05 [fantasai]
Tab: But doesn't work so well for general total parsing
20:40:27 [fantasai]
Bert: When adding new features, need to know what is valid per grammar
20:40:50 [fantasai]
Tab: Grammar's are great for higher-level things, not so great for parsing
20:42:16 [fantasai]
ACTION TabAtkins: Fill out Changes from CSS 2.1 Core Grammar section, intro etc.
20:42:16 [trackbot]
Sorry, couldn't find user - TabAtkins
20:42:56 [fantasai]
Topic: Case-insensitive/sensitive identifiers
20:42:57 [TabAtkins_]
ACTION Tab: Fill out Changes from CSS 2.1 Core Grammar section, intro etc.
20:42:57 [trackbot]
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 [fantasai]
jdaggett: need to discuss case-insensitivity issue
20:43:38 [fantasai]
fantasai: Don't think it's a parsing issue
20:44:26 [fantasai]
jdaggett: I think some of the arguments made about case-sensitivity are wrong
20:44:37 [fantasai]
ACTION: fantasai and jdaggett to discuss case-sensitivity at the break
20:44:37 [trackbot]
Created ACTION-493 - And jdaggett to discuss case-sensitivity at the break [on Elika Etemad - due 2012-08-20].
20:45:44 [TabAtkins_]
ScribeNick: TabAtkins_
20:45:52 [TabAtkins_]
Topic: CSS Fragmentation
20:46:10 [TabAtkins_]
fantasai: There was a bunch of outstanding edits from Hamburg and in-between.
20:46:18 [TabAtkins_]
fantasai: One was adding recto/verso to the break properties. That's done.
20:46:33 [TabAtkins_]
fantasai: Another was the "Splitting Boxes at Breaks" section.
20:47:14 [TabAtkins_]
fantasai: We'd decided that if the box is block-level with a specified height..
20:47:29 [TabAtkins_]
fantasai: I interpreted "specified height" in the resolution as "specified length or percentage".
20:47:36 [TabAtkins_]
fantasai: We didnt' discuss non-block elements.
20:47:52 [TabAtkins_]
fantasai: I put inline in the "doesn't stretch to the end of the fragment" category.
20:48:04 [TabAtkins_]
dbaron: Limiting the extra-space rule to length or percentage...
20:48:15 [TabAtkins_]
dbaron: If you have min-content, I think you want it there.
20:48:36 [TabAtkins_]
dbaron: You don't want a break to make height:min-content overflow.
20:49:23 [TabAtkins_]
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]
dbaron: That it doesn't consume any of the specified height should apply to all types of heights.
20:49:55 [TabAtkins_]
fantasai: The other case we didnt' discuss was table-cells, grid cells, and flex items.
20:50:10 [TabAtkins_]
fantasai: The reason we decided not to draw the bg was if you were lining up your background with the content.
20:50:31 [TabAtkins_]
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 [TabAtkins_]
fantasai: So I think it makes sense for those to draw to the bottom of the page.
20:51:06 [TabAtkins_]
szilles: I'm hearing use-cases for both solutions.
20:51:16 [TabAtkins_]
szilles: So you'll probably want a property for this later.
20:52:04 [TabAtkins_]
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 [TabAtkins_]
fantasai: I would almost rather have none of them gap, than all of them gap.
20:52:59 [TabAtkins_]
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 [TabAtkins_]
fantasai: [shows some ascii diagrams of the behavior we ended up deciding on for slice/clone for blocks\
20:54:17 [TabAtkins_]
fantasai: So, do we accept the edits?
20:55:38 [TabAtkins_]
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 [dbaron]
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 [TabAtkins_]
szilles: Right, I think everything should use the top or bottom behavior.
20:58:30 [hasni-2pac]
hasni-2pac has joined #css
20:58:48 [TabAtkins_]
fantasai: [explains the ascii examples more thoroughly]
20:59:06 [TabAtkins_]
RESOLVED: Accept fantasai's edits for the breaking/painting rules.
20:59:21 [TabAtkins_]
fantasai: Next is how to deal with the page-break-before/break-before aliasing.
20:59:40 [TabAtkins_]
fantasai: Florian's idea was to treat the page-break-before property as a shorthand for the break-before property.
21:00:19 [TabAtkins_]
fantasai: All the values map to themselves, except page-break-before:always maps to break-before:page.
21:01:20 [jdaggett_]
jdaggett_ has joined #css
21:01:23 [TabAtkins__]
TabAtkins__ has joined #css
21:02:12 [glazou_]
glazou_ has joined #css
21:02:18 [vhardy_]
vhardy_ has joined #css
21:02:28 [tantek_]
tantek_ has joined #css
21:02:41 [TabAtkins__]
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__]
vhardy__ has joined #css
21:03:10 [TabAtkins__]
florian: So I consider the suggestion the best possible rule.
21:03:56 [dbaron]
dbaron has joined #css
21:04:38 [TabAtkins_]
TabAtkins_ has joined #css
21:04:43 [glazou_]
glazou_ has joined #css
21:05:11 [TabAtkins_]
fantasai: [explains why page-break-before:avoid should map to break-before:avoid, rather than break-before:avoid-page]
21:05:39 [TabAtkins_]
vhardy__: Okay. It just seems like we're losing the kind of break.
21:05:53 [jdaggett_]
jdaggett_ has joined #css
21:05:54 [TabAtkins_]
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]
lstorset has joined #css
21:06:23 [fantasai]
21:06:43 [vhardy_]
vhardy_ has joined #css
21:06:48 [fantasai]
Murakami-san explains why avoid should map avoid and not avoid-page
21:07:24 [vhardy__]
vhardy__ has joined #css
21:07:27 [florian]
florian has joined #css
21:07:46 [TabAtkins_]
RESOLVED: Accept the spec's mapping of page-break-* to break-* as a shorthand.
21:08:42 [TabAtkins_]
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 [TabAtkins_]
fantasai: That makes sense to me.
21:09:25 [TabAtkins_]
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 [TabAtkins_]
fantasai: Going all the way to the root if necessary.
21:10:24 [TabAtkins_]
fantasai: The alternative would be to define column breaks to also act like page breaks otherwise.
21:10:34 [TabAtkins_]
fantasai: The difference is how the two interact with regions, and future fragmenters.
21:11:31 [TabAtkins_]
dbaron: So if there's no matching fragmenter context, it just breaks everything?
21:12:35 [TabAtkins_]
dbaron: My intuition would be that nothing breaks if there's no matching fragmentation context.
21:13:08 [TabAtkins_]
dbaron: The other option is that we have a ranked ordering of break types.
21:13:17 [TabAtkins_]
fantasai: Or setting an explicit equivalency.
21:13:47 [TabAtkins_]
szilles: I think the "find the nearest fragmenter" was a positive change.
21:15:11 [TabAtkins_]
TabAtkins_: fantasai, can you justify why you want a column break, if you request a page break and are not paginated?
21:15:34 [TabAtkins_]
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 [TabAtkins_]
plinss: Looking at OpenOffice (and maybe Word), column breaks dont' turn into page breaks in a single-col situation.
21:16:43 [TabAtkins_]
fantasai: I think the way to get the text you guys want is...
21:16:55 [TabAtkins_]
fantasai: If a column break is requested, it'll be satisfied by a page break, but not the other way around.
21:19:30 [TabAtkins_]
[some confusing discussion, conclusion was still the "find nearest matching fragmenter, if there isn't one then no-op"]
21:19:51 [TabAtkins_]
Rossen: Somewhat farfetched, but if you had nesting of different frag types, like columns inside of regions.
21:20:21 [TabAtkins_]
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 [TabAtkins_]
Rossen: And if there's nothing, it doesn't break.
21:21:02 [TabAtkins_]
fantasai: Okay, sounds like a clear resolution.
21:21:24 [TabAtkins_]
RESOLVED: Breaks seek the nearest matching fragmenter, and break everything between. If there is no match, no break occurs.
21:21:59 [TabAtkins_]
fantasai: Next, there are two interpretations of "always": break the nearest fragmenter, or break everything.
21:22:44 [TabAtkins_]
sylvaing: "all" for all of them?
21:22:53 [TabAtkins_]
Bert: Not sure if we need the "break everything" one.
21:23:03 [fantasai]
21:24:07 [TabAtkins_]
dbaron: I like "any" and "all".
21:24:14 [TabAtkins_]
TabAtkins_: What does "always" do, then?
21:24:25 [TabAtkins_]
dbaron: I thought "always" was only for page-break-*.
21:24:38 [TabAtkins_]
dbaron: Do we need break-*:always?
21:25:01 [TabAtkins_]
fantasai: multicol has "always" in it.
21:26:49 [TabAtkins_]
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 [TabAtkins_]
RESOLVED: Add "any" and "all" to break-*, research what to do for "always".
21:29:19 [TabAtkins_]
plinss: any objections to publishing a new WD with these edits?
21:29:31 [dbaron]
break: glass ! in case of emergency;
21:29:33 [fantasai]
ACTION fantasai: define root fragmenting element
21:29:33 [trackbot]
Created ACTION-494 - Define root fragmenting element [on Elika Etemad - due 2012-08-20].
21:29:43 [TabAtkins_]
RESOLVED: Publish a new WD of Break, after the edits resolved on during this session.
21:31:51 [TabAtkins_]
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 [TabAtkins_]
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 [TabAtkins_]
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 [TabAtkins_]
szilles: I prefer B for the simpler behavior - it's the same as normal float behavior.
21:34:17 [TabAtkins_]
dbaron: I don't understand hwo you get the option A behavior.
21:34:38 [TabAtkins_]
dbaron: auto-width floats depend on the width of their containing block and their contents, not surronding floats.
21:34:45 [TabAtkins_]
dbaron: So what makes floats get narrower in this case?
21:35:06 [TabAtkins_]
fantasai: This very overconstrained situation.
21:35:15 [TabAtkins_]
Rossen: But that changes the behavior of floats.
21:36:14 [TabAtkins_]
fantasai: So people seem to prefer B?
21:37:00 [TabAtkins_]
Rossen: [outlines why it makes sense to do option B for varying-width containers]
21:37:43 [TabAtkins_]
florian: I think you're saying that percentage-width floats change their size in the next page?
21:38:06 [TabAtkins_]
szilles: Yes, that's already in the spec.
21:38:36 [TabAtkins_]
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 [TabAtkins_]
dbaron: So here you get into interesting issues where you have a bunch of existing floats...
21:39:08 [TabAtkins_]
dbaron: So if you're in the situation in the option B diagram...
21:40:42 [TabAtkins_]
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_]
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 [TabAtkins_]
dbaron: I think I agree. I'm curious if I implemented that.
21:42:13 [TabAtkins_]
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 [TabAtkins_]
Rossen: I think this might already be included. We can refer to them and extend if there's something missing here.
21:42:50 [fantasai]
Tab: In this case, on the second page here
21:43:01 [fantasai]
Tab: You have a page-break-before the word float on the second line
21:43:10 [fantasai]
Tab: And the next page is extra-wide, what happens there?
21:43:34 [fantasai]
dbaron: More interesting question, what about a new float?
21:43:49 [fantasai]
.... unplaced continuations
21:45:09 [TabAtkins_]
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 [TabAtkins_]
fantasai: Would this depend on the gap/no-gap behavrio difference?
21:45:26 [dbaron]
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 [TabAtkins_]
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 [fantasai]
side discusion of whether forced breaks in floats should affet surrounding contents: no they should not
21:46:22 [fantasai]
21:47:55 [fantasai]
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]
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]
fantasai: if it lands on fill-available, it will vary
21:48:59 [TabAtkins_]
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]
dbaron: min-content and max-content should always measure across all the fragments
21:49:48 [fantasai]
[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 [TabAtkins_]
RESOLVED: Use Option B (float fragments are placed as if they're new independent floats).
21:51:01 [TabAtkins_]
dbaron: I think we need someone to propose an adjustment for the float placement rules.
21:51:50 [TabAtkins_]
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 [TabAtkins_]
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 [TabAtkins_]
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 [TabAtkins_]
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 [TabAtkins_]
florian: I think we agreed to push it.
21:55:17 [tantek]
21:57:19 [SteveZ]
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 [dbaron]
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 [trackbot]
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 [dbaron]
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 [SteveZ]
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 [SteveZ]
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 [TabAtkins_]
<br duration=15m>
22:15:14 [dholbert]
dholbert has joined #css
22:22:56 [fantasai]
Topic: Pseudo-elements
22:23:00 [stearns]
22:23:00 [fantasai]
ScribeNick: fantasai
22:23:22 [fantasai]
ScribeNick: Bert
22:23:22 [molly]
molly has joined #css
22:23:40 [Bert]
Topic: pseudo-elements
22:24:29 [vhardy_]
vhardy_ has joined #css
22:24:38 [arronei_]
topic::pseudo-elements is think is more correct.
22:24:52 [Bert]
Alan: [explains the idea: multiple pseudo-elements on same selector]
22:25:09 [Bert]
... Not just for regions.
22:25:25 [Bert]
... Generated content also. Presentational effects.
22:25:34 [leaverou]
leaverou has joined #css
22:25:47 [Bert]
... Multiple ::before's avoids having to add elements.
22:26:08 [Bert]
fantasai: Good to see somebody workin gon defining pseudo-elements, but
22:26:20 [Bert]
... cascade doesn't work well like this.
22:26:56 [Bert]
... Imagine somebody trying to override he style of a :before, but it is actually the 15th :before...
22:27:12 [Bert]
Alan: It has a :nth-pseudo shortcut.
22:27:27 [Bert]
... That selects all pseudos at one.
22:27:33 [Bert]
... But we can put in an issue.
22:28:22 [Bert]
glazou: Oridinals, if interleaved :after and :before.
22:28:52 [Bert]
dbaron: If content is not none on the 5th :before,the 5th before gets generated.
22:29:23 [Bert]
Alan: If there is nothing in the 1st four, than the 5th is actually the first.
22:29:42 [Bert]
peterl: it doesn't create, only select.
22:29:56 [Bert]
fantasai: What aother use cases?
22:30:20 [Bert]
alan: Example is if you have pseudo for a quote that matches [???]
22:30:39 [Bert]
... If you have two :afters, you can have two styles for those two parts,
22:30:58 [Bert]
dbaron: That doens't sound a case that generated content is for.
22:31:11 [Bert]
[See Mark Twain example in spec]
22:31:41 [Bert]
dbaron: That is bad practice. Imagine you take the style sheet away...
22:31:51 [fantasai]
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 [Bert]
glazou: But it is existing practice.
22:32:17 [Bert]
plinss: Difference between encouraging and allowing it.
22:32:28 [fantasai]
dbaron: Don't think it should be allowed to drive the design of features.
22:32:44 [Bert]
TabAtkins_: Multiple cases where you run out of pseudo elements.
22:33:07 [Bert]
alan: Valid use case. Differentstyles for different added blocks.
22:33:35 [Bert]
plinss: It can come from attributes ort just four diffretn strings.
22:34:01 [Bert]
dbaron: This is way beyond what people shpould uss generated content for.
22:34:09 [fantasai]
fantasai: Might also want to turn some of those into links.
22:34:12 [molly]
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 [Bert]
q+ to suggest templates instead
22:34:55 [Bert]
TabAtkins_: You run out of elements to attach style to.
22:35:07 [Bert]
fantasai: image borders can do that example.
22:35:18 [Bert]
... shouldn't need to know which pseudo style.
22:35:34 [dbaron]
Tab: want to do speech bubble and quotation marks
22:35:41 [Bert]
TabAtkins_: There are well established patterns for useing pseduos for sttyleing.
22:35:47 [dbaron]
dbaron: well, ignoring that the whole business of doing quotation marks with pseudo elements is a disaster...
22:36:14 [Bert]
fantasai: Everytime [scribe forot the rest]
22:36:38 [Bert]
tantek: We had :outside:inside at some point.
22:36:39 [drublic]
drublic has joined #css
22:36:49 [Bert]
fantasai: [missed]
22:36:53 [tantek]
::outside and ::inside - but yeah
22:37:13 [Bert]
alan: multiple style sheets with their own pseidos that *don't* cascade is another use case.
22:37:35 [Bert]
ted: So yu have to know how many pseudos an element has?
22:37:50 [Bert]
florian: If you want two icons, e.g.
22:38:04 [fantasai]
e.g. external link, or PDF link
22:38:06 [fantasai]
or both
22:38:38 [Bert]
ted: nubering the pseufos is not so good for avoiding clashes between styles sheets.
22:39:10 [Bert]
tantek: There are use cases, but indexing mexhanism will lead to compatition (war) betwene designs.
22:39:44 [dbaron]
Bert: Hixie came up with multiple pseudos a long time ago -- doesn't cascade.
22:40:10 [dbaron]
Bert: That's the most important reason for template idea -- template doesn't have numbers, they have names.
22:40:16 [dbaron]
?: how are they ordered
22:40:28 [dbaron]
Bert: visual layout
22:40:54 [dbaron]
glazou: Writing ::before(n) is very easy for authors to write and modify
22:41:00 [Bert]
glazou: all solutions, incluing templates, is more difficult for authors than multiple :befores.
22:41:34 [Bert]
tab: Template cannot create something that allows line breaks between the pseudos.
22:41:55 [TabAtkins_]
Template forces us into, at best, something like inline-block.
22:42:07 [glazou]
22:42:22 [TabAtkins_]
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 [Bert]
glazou: This is sombody who is in favor
22:42:48 [Bert]
fantasai: It only works in simple cases.
22:42:51 [fantasai]
fantasai: It works fine in simple cases where you don't have interactions among multiple sources of styles
22:43:19 [Bert]
glazou: How do you select a created box, or a collection of boxes. We can't currently.
22:44:06 [Bert]
22:45:11 [Bert]
... It is in the proposal: :nth-pseudo
22:45:23 [Bert]
ted: How about pseudos in other modules?
22:45:37 [Bert]
... E.g., overflow regions, as psoposed by dbaron.
22:46:06 [Bert]
... Don;t know how many regions, cannot selects the last-but-one.
22:46:33 [Bert]
Alan: You can selects from the end, :nth-last
22:46:59 [Bert]
TabAtkins_: Fine if there is a fixed number,not if the style can generate more.
22:47:41 [Bert]
alan: could even apply nth-pseudo to regions, to select the nth region, using 'region' as the type.
22:48:17 [Bert]
florian: allows nth line?
22:48:30 [Bert]
glazou: Probably left over from older verison of spec. Not supposed to work.
22:48:57 [Bert]
florian: different priperties apply to different [pseudos. Do also to nth-pseudo?
22:49:02 [Bert]
glazou: Absolutely,
22:49:37 [Bert]
florian: Sounds like nth-after and nth-before might be better, you'll know which properties apply.
22:50:11 [Bert]
glazou: we thought about extending later. We saw a few rtequests from users.
22:50:35 [Bert]
... typically mutliple decorations, borders around an element.
22:50:50 [Bert]
... Need multiple paddings betweme the multiple borders, e.g.
22:51:09 [fantasai]
Bert: I think you should distinguish between what people are trying to do, and what they are requesting.
22:51:25 [fantasai]
Bert: E.g. people want multiple borders, but they request multiple pseudos.
22:51:41 [fantasai]
Rossen: Can you point us to actual examples of this?
22:52:50 [Bert]
alan: users asking for multiple generated content. Not sure if pseduos is always th ebest way for it.
22:53:04 [fantasai]
alan: to draw pictures
22:53:16 [Bert]
TabAtkins_: Many things that are cool to have, later.
22:53:46 [fantasai]
Rossen: As soon as you extend structure into this, it's trying to reinvent HTML in CSS
22:53:47 [Bert]
rossen: adding complxeity into th esolution, adding structure, sounds like implementing HTML inside CSS.
22:54:00 [Bert]
... Why not use HTML?
22:54:22 [Bert]
fantasai: XBL was also suppsoed to solve this.
22:54:33 [Bert]
TabAtkins_: But nobody implemented that.
22:55:04 [Bert]
glazou: We have a way to present all attributes with the same style, but not with different styles.
22:55:13 [Bert]
fantasai: So that is a use case.
22:55:39 [dbaron]
I think including :before and :after in CSS was a mistake.
22:55:45 [Bert]
... But can also make it appear as an element, able to be styled.
22:56:05 [Bert]
... We're also trying to olve the multiple border case, multiple icons case, etc.
22:56:20 [Bert]
... We should try to solve these in a better way.
22:56:35 [Bert]
... This proposal is awkward for all of them.
22:56:46 [Bert]
alan: I think it is the easiest possible solution.,
22:56:59 [Bert]
glazou: Selecting columns, is other exmaple.
22:57:08 [Bert]
florian: There is a pseufo in GCPM for that.
22:57:28 [Bert]
ted: [missed]
22:57:43 [Bert]
vincent: Can already have collission with current single :before pseduo.
22:58:40 [Bert]
steve: The comments on columns are relevant: consider replacing style on a group or on individual parts of he group.
22:58:56 [Bert]
ted: Descendant of the :before?
22:59:12 [Bert]
steve: :before is then a shorthand for the whole collection.
22:59:14 [dbaron]
Steve: ::before becomes a shorthand for the collection of all the ::before(n)
22:59:31 [Bert]
alan: Other issue in spec is object model for pseudos.
23:01:28 [stearns]
23:01:39 [Bert]
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 [sylvaing]
...from a static markup
23:02:18 [Bert]
glazou: You can access them, even if not instatiate.
23:02:37 [Bert]
sylvaing: No, yu cannot currently. How attach event handlers.
23:02:37 [arronei_]
we should stop this pseudo madness ::before it gets out of hand.
23:03:16 [Bert]
glazou: The day we have stuff on the right hand side, don't you think people will want :hover there, too?
23:03:34 [Bert]
sylvaing: Not sure what problem we're solving anymore.
23:03:53 [Bert]
TabAtkins_: Problem is just with OM?
23:04:10 [Bert]
sylvaing: All the things we're adding make pseudos act like elements.
23:04:30 [Bert]
glazou: Yes, all specs do the same.
23:04:43 [Bert]
sylvaing: So we're creating elements, except there is no DOM for them.
23:05:01 [Bert]
dbaron: We're creating new structure, rather than slots into which to pour structure.
23:05:27 [fantasai]
dbaron: Most other pseudos are about styling ranges of what already exists.
23:05:30 [Bert]
... The other pseduos other than :before/after are about things that already exist (first-line, first -letter, column).
23:05:37 [Bert]
... Before after make new content.
23:05:53 [Bert]
... I think before/after were a mistake.
23:06:30 [Bert]
florian: Without the DOM, this solution feels incomplete.
23:07:02 [Bert]
TabAtkins_: People should not expect that a pseduo can be a drop zone.
23:07:23 [Bert]
glazou: We've been asked for this for 14 years.
23:07:33 [Bert]
... Our customers ask for this.
23:07:52 [Bert]
... They know what they need.
23:08:25 [Bert]
plinss: Wether to have pseudo-elements is no longer a question.
23:08:45 [Bert]
dbaron: But theis is a different question. What about accessibility, e.g,
23:09:21 [Bert]
plinss: We had pseudos for scrollbar parts, that's why we added double colon, to make it extensible.
23:09:35 [Bert]
... We're already adding extra structure.
23:10:01 [Bert]
dbaron: Separating content and prsentation. Mostof the examples here are mixing them back up.
23:10:26 [Bert]
plinss: That is not black and white. Sometims tetx is presentational, somtimes images are content.
23:10:55 [Bert]
dbaron: There are guidelines from i18n, a11y, etc.
23:11:08 [Bert]
... Text presented to user should not be in attribute, e.g.
23:11:30 [Bert]
glazou: Wikipedia has content in attrib.
23:11:42 [Bert]
... They said it was too complex too fix.
23:12:18 [Bert]
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 [Bert]
glazou: EPUB is full of attributes with text.
23:12:50 [Bert]
... YOu *have* to render those attributes.
23:13:11 [Bert]
fantasai: A simple transformation language will be a simpler way to solve this.
23:13:41 [Bert]
alan: The lst use case in the draft is not about generated content.
23:13:53 [Bert]
... It creates regions by means of pseudos.
23:14:09 [Bert]
vincent: I'm sensitive to accessibility argument.
23:14:34 [Bert]
... THis case doesn't have tetx in attributes.
23:14:50 [Bert]
dbaron: I think the example can, and ought, to be done in other ways.
23:15:07 [Bert]
... Styleing exisitng content and making content is different.
23:15:20 [Bert]
... Here ypu are stylong, but using a tool that is creating content.
23:15:21 [glazou]
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 [Bert]
alan: This is about redirecting content that already exist,
23:16:28 [Bert]
... 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]
jet has joined #CSS
23:16:50 [Bert]
plinss: I have no objection to creating arbitrary regions. ot sure I like this proposal, though.
23:16:55 [Bert]
... Seems hacky.
23:17:08 [Bert]
Alan: It is meant to avoid having empty elts in the mark-up.
23:17:25 [Bert]
plinss: Yes, agreed, but :before/after seems a hack for this.
23:17:47 [Bert]
TabAtkins_: Looks hacky, but can be written differently.
23:18:13 [Bert]
plinss: I think we like what it is trying to do, not how it does it.
23:18:37 [Bert]
vincent. OK, but how do we go from there?
23:19:19 [Bert]
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 [Bert]
glazou: Antohether type of pseudo?
23:20:07 [Bert]
... We need multiple :before/after, But I udnerstand you don't want to use that for all use cases.
23:20:08 [vhardy_]
23:20:39 [Bert]
... We decided to restrict ourselves to :before/after for immediate needs.
23:20:51 [Bert]
... Web authors are expressing need for more.
23:21:01 [Bert]
plinss: I want to try and get something better,
23:21:35 [Bert]
glazou: Adobe's proptotype is real fun to play with. Can do things couldn;t do before.
23:21:52 [Bert]
... It makes sense to sperate sleetcors and pseudos and extends pseudos.
23:22:03 [Bert]
plinss: OK to make a WD.
23:22:24 [Bert]
... Not currently ready for FPWD though.
23:22:44 [Bert]
vincent: peter, want to be co-editor?
23:22:46 [fantasai]
s/OK to make a WD/OK to make an ED/
23:23:00 [Bert]
plinss: Want to be involved, will see about co-editor.
23:23:21 [Bert]
fantasai: Not OK with FPD, but defer to others for editor's draft,
23:23:41 [Bert]
florian: Even without multiple :befreo/afetr, the rest is still useful.
23:24:08 [Bert]
... I want to work on it.
23:24:29 [Bert]
[discussion about people implementing too soon]
23:24:51 [Bert]
plinss: Fine as an editor's draft.
23:25:07 [Bert]
fantasai: We should point out to people that we have no consensus.
23:25:21 [Bert]
glazou: An editor's draft is a proposal.
23:25:33 [Bert]
tantek: List issues explicitly in the document.
23:25:37 [Bert]
glazou: Sure.
23:26:14 [Bert]
[discussing issues that say "we don't really want this"]
23:26:30 [Bert]
dbaron: Should mention a11y and i18n issues.
23:26:44 [Bert]
.. And ask whether this is more power than we want in CSS.
23:26:52 [dbaron]
fantasai: and the cascade issues should be mentioned.
23:27:07 [Bert]
fantasai: And is should mention the trouble with cascading.
23:27:28 [Bert]
RESOLVED: make editor's draft with these isseus listed.
23:27:41 [Bert]
s/is should/it should/
23:27:55 [Bert]
Topic: region overflow
23:28:57 [Rossen]
23:29:03 [florian]
23:29:04 [dbaron]
23:29:48 [Bert]
dbaron: When an elt has overflow,
23:30:03 [Bert]
... if it were paginated, it would break here,
23:30:17 [Bert]
... we say we make another box as a sibliong of the first box.
23:30:36 [Bert]
... That one may also be broken, until we have all content.
23:30:45 [Bert]
... With auto height, it doens't do anything.
23:31:02 [Bert]
... But if you set fixed height, you'l get multiple boxes.
23:31:14 [Bert]
... Interesting question is to style the different boxes.
23:31:31 [Bert]
florian: Multicol has behavior to add columns to the side.
23:31:46 [Bert]
... At least you can see them, not always the best way to style it.
23:32:02 [Bert]
... Might instead want to add nother multicol box below it.
23:32:27 [Bert]
dbaron: [lookin at example 1]
23:32:46 [Bert]
... In example 2, you can style the regions separately.
23:33:26 [Bert]
... Let's look at the examples. Inherit style from regions into the content.
23:33:43 [Bert]
... E.g.. a larger font for the first region.
23:34:37 [Bert]
... Example 4 has different :visited styles in the diff. regions.
23:34:48 [Bert]
glazou: THis is uch better than @rules.
23:35:10 [Bert]
steve: Which @rules?
23:35:16 [Bert]
glazou: Like regions.
23:35:39 [Bert]
dbaron: Which props ypu can use in the regions is a bit complicated.
23:35:56 [Bert]
... Example 5 is maybe more realistic use case.
23:36:04 [Bert]
... I added a property 'max-lines'
23:36:17 [Bert]
... You want pagination after a certain # of lines.
23:36:36 [Bert]
jdaggett: What if it has height:auto?
23:36:58 [Bert]
dbaron: Depends on whether height constrains more than max-lines.
23:37:28 [Bert]
glazou: You can make the same argument about cascading here as with multilple psuedos.
23:37:42 [Bert]
dbaron: But you can kill this with a sinlge 'overflow' property.
23:37:52 [Bert]
fantasai: Thge ability to reset the whole thing is important.
23:38:09 [Bert]
glazou: Both proposals have that.
23:38:30 [Bert]
dbaron: I'd like to use the same name in the overflow and in the name of the pseudo.
23:38:31 [jdaggett]
jdaggett: s/height:auto/height is set?/
23:38:38 [Bert]
... That's why i don't like "repeat".
23:38:51 [Bert]
... I came up with "piece" and "part"
23:38:58 [Bert]
fantasai: How about "copy"?
23:39:05 [Bert]
glazou: They are not copies.
23:39:35 [Bert]
steve: The words don't ahave the same function in the two places.
23:39:59 [Bert]
fantasai: Fragment can be both a noun and a verb :-)
23:40:16 [dbaron]
dbaron: Fine to use noun in both places
23:40:21 [Bert]
SteveZ: "Fragment" can, yes.
23:40:48 [Bert]
alan: We can put an issue that we don't know the name yet.
23:41:23 [Bert]
vincent: I think we change the name before we publicize it more, though.
23:41:52 [Bert]
dbaron: prefer part over fragment, but OK with fragment.
23:42:13 [Bert]
glazou: content property applies only if region exist?
23:42:24 [Bert]
dbaron: Probabl 'content' doesn't apply.
23:42:59 [Bert]
TabAtkins_: About stuff to the right of the pseudo-elt.
23:43:08 [Bert]
... Make the '::' a combinator?
23:43:33 [Bert]
... There are few current pseudos that you'd need to special case.
23:43:45 [Bert]
... But they already have spacial case in that they allow a single ':'
23:44:38 [Bert]
fantasai: a ::before vs a::before
23:44:58 [Bert]
... if '::' becomes a combinator, then they would be the same.
23:45:23 [Bert]
plinss: Or treat the whole pseudo-elt as a kind of combinator.
23:45:55 [Bert]
glazou: Yes, allowing the space needs a lot of chnages to the specs.
23:46:00 [Bert]
steve: rathole?
23:46:20 [Bert]
vincent: 'max-line' is like 'max-width'?
23:46:31 [Bert]
... limiting the siz eand the overflow are different things.
23:46:54 [Bert]
florian: Yes, it is in this spec just becaue t needs a host.
23:47:17 [Bert]
dbaron: It is not processed the same way as hieht, it is processed when you detetmrine breaks.
23:47:48 [Bert]
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 [Bert]
ted: 'min-lines'?
23:48:26 [Bert]
dbaron: Why would you want that?
23:49:16 [Bert]
steve: problem with givinbg height a value in lines maybe that it depends on layout?
23:49:34 [Bert]
dbaron: A little scaed, but it might work...
23:49:50 [Bert]
plinss: And 'max-width: 3lines'?
23:50:05 [Bert]
TabAtkins_: Would be meaningless in horizontal writing modes.
23:50:41 [Bert]
plinss: having a unit I like, but scary.
23:51:09 [Bert]
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 [Bert]
... 'foo#f1' is more specific than 'foo:nth-region' and so shouldn't it win?
23:52:11 [Bert]
steve: Did we have a similar issue with [??]
23:52:34 [Bert]
dbaron: I want some specificity for these, same as pseduo-class, maybe.
23:52:44 [lstorset]
s/??/region styling
23:53:20 [Bert]
florian: Other issue is related to multicol, does this apply to columns?
23:53:34 [Bert]
dbaron: I think nth-region applies to columns.
23:53:47 [Bert]
... It would apply anywhere where you do breaking.
23:54:22 [Bert]
... No, actually, it would not be put on the multicol element itself
23:54:45 [Bert]
plinss: Doesn't matter why something breaks.
23:55:05 [Bert]
rossen: Any restriction son what it applies to? CAn break anything?
23:55:15 [Bert]
dbaron: table parts may be problemtatic.
23:55:41 [Bert]
rossen: Create extra table cells... create extra rows... awkward.
23:55:54 [Bert]
fantasai: "you get what you asked for"? :-)
23:56:10 [Bert]
Rossen: At least somethign to consider.
23:56:27 [Bert]
dbaron: People suggested this should become an overflow module.
23:56:42 [Bert]
... overflow-x/y in this context also need to be specified.
23:57:08 [Bert]
florian: Yes, thet interact poorly currently,
23:57:27 [fantasai]
fantasai: good reason to address them all together in the same place
23:57:37 [Bert]
alan: does 'break-before' apply?
23:58:07 [Bert]
steve: 'break: always (or 'all') would do it.
23:58:38 [Bert]
florian: Does 'break-*: region' apply?
23:59:00 [Bert]
... I think I'm OK with using the same keyword.
23:59:16 [Bert]
steve: Example is multiple coliumns, which contain regions.
00:00:21 [Bert]
glazou: we have several proposals for nth-*. So I think nth-pseudo(type) is better.
00:00:41 [Bert]
dbaron: Do't think the word "pseudo" should be in the name.
00:01:00 [Bert]
glazou: We can glue all proposals together.
00:01:30 [arronei_]
I agree with dbaron I don't think "pseudo" should be in the name either
00:01:35 [Bert]
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 [Bert]
dbaron: I'm remnded of first gradient proposal, with different arguments diepending on type argument.
00:02:56 [Bert]
[discussion confused about whether it is about the word "pseudo" or about the concept of "nth" with a param]
00:03:39 [Bert]
steve: it's the same thing every time: the nth of a type.
00:03:50 [Bert]
florian: Not exactly the same meaingin on all cases.
00:04:14 [Bert]
fantasai: but you can put the type after a dash, why put it in parenthees?
00:04:49 [jet]
jet has joined #CSS
00:05:41 [Bert]
steve: gradients had differtnet params in different types. This is just one param.
00:06:09 [Bert]
Tab: YEs, but for future extensions safer to prevent psssibility of different params.
00:06:32 [Bert]
florian: nth-region is also shorter, that's enough of a reason.
00:07:23 [Bert]
plinss: *:before:nth(3)
00:07:47 [Bert]
... ::before:hover
00:08:18 [Bert]
... Why invent a mechanism. We already have pseudo-classes.
00:09:37 [Bert]
glazou: ::first-letter is ::letter:nth(1) ?
00:09:50 [Bert]
steve: Cannot necessarily apply it to everything.
00:10:08 [Bert]
plinss: :first-line would just be an alias.
00:10:41 [Bert]
dbaron: Boustrophedon: ::lines(2n+1)
00:10:59 [Bert]
s/dbaron: Boustrophedon: ::lines(2n+1)//
00:11:22 [plinss]
actually that should be ::line:nth(2n+1)
00:12:34 [Bert]
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 [Bert]
dbaron: Can set height: auto.
00:12:50 [Bert]
florian: Not quite he same thing.
00:13:05 [Bert]
dbaron: My worry is about the first fragment.
00:13:20 [Bert]
... You only use the fragment styles *if* the elt id fragmented.
00:13:43 [Bert]
... If you turn off overflow on the first fragment, suddently you don't have overflow anymore...
00:14:08 [Bert]
TabAtkins_: Or don't start counting until the second fragment.
00:14:34 [Bert]
dbaron: Doubles the cost of selector matching.
00:15:01 [Bert]
... So either don't matche sleectors unless you have the special overflow value, or
00:15:16 [Bert]
... don't apply frgament styles until ypu reach the second.
00:15:59 [Bert]
plinss: 'overflow: fragment' and it doesn't create fragments, do the properties apply?
00:16:28 [Bert]
... As soon as you set 'overflow: fragment' all styles apply, whether or not you have more than one fragment.
00:17:04 [Bert]
... All of the boxes of an elt are considered fragments, if it fragments for any reason.
00:17:23 [Bert]
dbaron: That was not how is speced it.
00:17:44 [Bert]
... Mine was only if you also specify 'overflow: fragment'
00:18:03 [Bert]
fantasai: Say you want a fragment of a given height.
00:18:17 [Bert]
... [draws on white board]
00:18:56 [Bert]
... and now imagine I wan borders on all fragments.
00:19:22 [Bert]
dbaron: I had to write extra style rules for paginated mode.
00:19:48 [dbaron]
s/extra style rules/fancier selectors, like :nth-region(n+2)/
00:20:17 [Bert]
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 [Bert]
plinss: Same issue in multicol.
00:22:27 [Bert]
steve: If a multicol element overflows in a paged environment, where does the next column go?
00:23:06 [Bert]
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 [Bert]
00:23:25 [Bert]
steve: Now I set 'overflow: fragment'
00:23:38 [Bert]
florian: It should act the same.
00:24:17 [Bert]
... Current wordking in multicol and in this proposal doesn't do that, but it should.
00:26:36 [Bert]
... Current does work if
00:26:57 [vhardy__]
vhardy__ has joined #css
00:26:58 [Bert]
... elt has 'columns' and 'overflow fragment'
00:27:40 [Bert]
... I think the 'overflow-style: paged-*' should be pulled into this spec, too.
00:28:26 [Bert]
... you can style the pages, but more limited; cannot position them, e.g.
00:28:52 [Bert]
dbaron: Some thing you might want to apply to paginated overflow do not make sense here.
00:29:07 [Bert]
... E.g., scroll two pages at once.
00:29:33 [Bert]
plinss: When you print, does it degrade well?
00:29:46 [Bert]
fantasai: Stack of pages?
00:30:11 [Bert]
dbaron: 'overflow:scroll' not defined for print either.
00:30:23 [Bert]
plinss: Dynamic presentation vs static presentation.
00:30:37 [Bert]
... Define how it degrades. Common model.
00:31:14 [Bert]
fantasai: One example of overflow 'paged' when printed [draws picture],
00:31:32 [Bert]
... inside page and outside page.
00:31:54 [Bert]
SteveZ: Better done with media queries?
00:32:06 [Bert]
dbaron: *If* the author provides media queries, yes.
00:32:30 [dbaron]
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 [Bert]
plinss: If you haven't anticipated a certain environment, it shoudl still behave reasonably.
00:33:07 [Bert]
... browsers should do something rational even if autghor didn't provide media query.
00:33:23 [Bert]
steve: This is auto-generation for a single stream.
00:33:34 [Bert]
... Doens't handle merging two streams.
00:33:41 [Bert]
... Page templates are about that.
00:33:52 [Bert]
... They do this, but do other things as well.
00:34:22 [Bert]
... They allow to select the next contained based on what content to position.
00:34:34 [Bert]
... So this doesn't replace page templates.
00:34:47 [Bert]
florian: I think alan convinced me of that.
00:35:25 [Bert]
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 [Bert]
dbaron: I thought fragmentation spec would do that.
00:35:38 [Bert]
fantasai: doesn
00:35:52 [Bert]
..' t cover everythinh.
00:36:24 [fantasai]
fantasai: Fragmentation covers how you break the flow across fragmentainers. Doesn't say how you size them.
00:36:41 [Bert]
alan: e.g., two regions in the same row, and one region has a forced break.
00:37:34 [Bert]
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 [Bert]
... Either dependencies or allow gaps.
00:38:34 [Bert]
... No need to resolve all that now. Just keep it in mind.
00:39:45 [Bert]
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 [Bert]
dbaron: The set of properties is restricted. More restricted in what applies to content than what applies to the region itself.
00:41:08 [Bert]
florian: Say we have a flexbox for first few elements and than the overflow is displayed differently.
00:41:23 [Bert]
00:41:48 [fantasai]
fantasai^: Maybe want to change display-outside, but don't think so for display-inside
00:42:27 [Bert]
vincent: difficult to implement when size depends on content, e.g., when diff. font size in diff. regions. Need 2nd pass.
00:42:56 [Bert]
... I don't remember all the cases, but there were interferences.
00:43:11 [Bert]
... It seems the same applies to 'overflow: fragment'
00:43:51 [Bert]
florian: Can we discuss 'overflow-x/y' and why it is a problem in combination with this?
00:44:43 [vhardy_]
vhardy_ has joined #css
00:44:54 [Bert]
... We implemented to ignore overflow-x if o- says 'paged-*' and vice-versa.
00:45:22 [Bert]
Bert: I tried to overflow-x/y up and never managed to, for much the same reasons.
00:45:33 [Bert]
dbaron: We had a discussion maybe 8 or 9 years ago.
00:45:51 [Bert]
... We concluded that all combinations mixed, except 'visible'
00:46:33 [Bert]
rossen: I think we had it speced, and IE9 implemented taht, I think.
00:47:22 [Bert]
florian: overflow is a shothand, one question is what the longhand is for some of the values.
00:48:44 [Bert]
... I may want to overflow pages only in vertical direction.
00:49:37 [Bert]
Rossen: I remember lookkng at some code for marquee with that question.
00:49:37 [fantasai]
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]
fantasai: Should we make background-repeat: repeat-x/y match that, then?
00:50:03 [molly]
molly has joined #css
00:50:26 [Bert]
florian: And then add writing modes... it just doesn't make sense.
00:50:43 [Bert]
... I think there is a link saying all that somwhere.
00:50:45 [fantasai]
florian^: overflow-x/y is really messed up
00:50:58 [florian]
00:51:44 [Bert]
florian: When we have reworked overflow, we don't actually need 'overflow-style' anymore.
00:52:25 [Bert]
tantek: We worked it all out and the result made less sense with logical directions, at least in UIs.
00:52:44 [Bert]
florian: Some edge cases are not elegant.
00:53:02 [Bert]
tantek: Edge cases are often not elegant.
00:53:50 [Bert]
florian: We had to do strange things with overflow-x/y outsidee the cascade.
00:54:02 [Bert]
.. So I'd like to see if we can't make something better.
00:54:11 [Bert]
s/.. /... /
00:55:00 [Bert]
tantek: The simpel answer is if you set 'paged' on one, then the other is lso paged.
00:55:09 [fantasai]
florian: If you put overflow-x: paged; overflow-y: fragment; what happens?
00:55:36 [Bert]
Rossen: We did what most other did. Visible trumped all.
00:55:43 [fantasai]
no, that's wrong
00:55:43 [Bert]
dbaron: We do 'hidden'
00:55:57 [Bert]
Rossen: Have to figure out which one wins.
00:55:58 [fantasai]
Rosen: if either was not-visible, visible became set to 'auto'
00:56:31 [Bert]
... With fragmentation added, specs needs to call it out.
00:56:32 [fantasai]
dbaron: we turn some values into hidden, and others into auto
00:56:36 [Zakim]
Zakim has left #css
00:56:45 [Bert]
dbaron: We turn some into hidden and some into auto.
00:57:09 [Bert]
rossen: We did some analysis and most implementations were similar.
00:57:44 [Bert]
... It makes sense to have 'visible' in one direction and hidden in the other and that shouldn't turn into auto.
00:57:57 [dbaron]
really we're just turning visible into auto
00:58:06 [dbaron]
we're turning the pre-2004 overflow:hidden into hidden
00:58:09 [Bert]
dbaron: Essentially wer are turning 'visible' into 'auto'.
00:58:56 [Bert]
florian: The (prefixed) marquee in webkit doesn't use overflow-style, but overflow.
00:59:56 [Bert]
... 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 [Bert]
fantasai: Maybe the value in the block direction should always win?
01:01:06 [Bert]
dbaron: That's reasonable, but we do something different for 'visible' currently.
01:01:44 [Bert]
florian: It is not exactly that. Example: [draws]
01:02:42 [fantasai]
Vincent asks about what we do with dbaron's draft
01:02:42 [Bert]
vincent: did we agree to publish dbaron's draft?
01:03:02 [Bert]
dbaron: Yes,as editor's draft. I want to name it css3-overflow.
01:03:12 [Bert]
florian: [drawing]
01:03:56 [Bert]
... last line on page has an image sticking out below. In paged mode, that overflow is just hidden.
01:04:18 [Bert]
fantasai: We add pages for abs pos elements.
01:04:29 [fantasai]
fantasai: you have to; some websites abspos the entire thing
01:04:33 [fantasai]
01:04:36 [Bert]
Rossen: The exception in our implementation is with mixed directions.
01:05:00 [Bert]
... Fragment in orthogonal diretcion, to not lose any content.
01:05:18 [dbaron]
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 [Bert]
fantasai: [draws page with long text sticking out on the left]
01:06:38 [glazou]
<br until="tomorrow **9am**" />
01:06:40 [Bert]
... We automatically trigger multicol to display that overflowng text.
01:08:32 [Bert]
[end of meeting]
01:47:27 [vhardy_]
vhardy_ has joined #css
02:03:53 [cabanier]
cabanier has joined #css
02:10:07 [Liam]
Liam has joined #css
02:12:59 [cabanier1]
cabanier1 has joined #css
02:37:58 [arronei_]
arronei_ has joined #css
02:45:11 [isherman]
isherman has joined #css
03:20:33 [tantek]
tantek has joined #css
03:58:21 [krit]
krit has joined #css
04:14:03 [shepazu]
shepazu has joined #css
05:25:22 [tantek]
tantek has joined #css
05:27:47 [tantek]
tantek has joined #css
05:55:14 [glazou]
glazou has joined #css
06:07:30 [Koji]
Koji has joined #css
06:12:16 [florian]
florian has joined #css
06:23:00 [drublic]
drublic has joined #css
06:42:05 [tantek]
tantek has joined #css
06:46:55 [arronei_]
arronei_ has joined #css
06:52:01 [cabanier]
cabanier has joined #css
07:08:24 [Ms2ger]
Ms2ger has joined #css
08:41:05 [drublic]
drublic has joined #css
08:43:28 [SimonSapin]
SimonSapin has joined #css
08:59:52 [drublic_]
drublic_ has joined #css
09:02:28 [drublic]
drublic has joined #css
09:49:27 [drublic]
drublic has joined #css
11:24:26 [decadance]
decadance has joined #css
11:31:31 [jet]
jet has joined #CSS
12:02:48 [jet]
jet has joined #CSS
12:27:10 [jet]
jet has joined #CSS
12:46:37 [myakura]
myakura has joined #css
12:52:45 [jet]
jet has joined #CSS
12:54:34 [drublic_]
drublic_ has joined #css
12:54:50 [leaverou]
leaverou has joined #css
13:03:21 [drublic]
drublic has joined #css
13:20:53 [leaverou]
leaverou has joined #css
13:42:52 [jet]
jet has joined #CSS
13:57:48 [leaverou]
leaverou has joined #css
14:00:45 [jet]
jet has joined #CSS
14:05:12 [jet]
jet has joined #CSS
14:06:25 [ksweeney]
ksweeney has joined #css
14:06:54 [ksweeney]
ksweeney has left #css
14:08:19 [shepazu]
shepazu has joined #css
14:26:17 [leaverou]
leaverou has joined #css
14:55:25 [jet]
jet has joined #CSS
15:23:47 [arronei_]
arronei_ has joined #css
15:35:44 [tantek]
tantek has joined #css
15:44:57 [glenn]
glenn has joined #css
15:47:21 [glazou]
glazou has joined #css
15:47:57 [glazou]
rrsagent, this meeting spans midnight
15:48:37 [Rossen]
Rossen has joined #css
15:50:08 [dbaron]
dbaron has joined #css
15:50:17 [florian]
florian has joined #css
15:51:30 [lstorset]
lstorset has joined #css
15:59:55 [TabAtkins_]
TabAtkins_ has joined #css
16:00:22 [Molly]
Molly has joined #css
16:03:36 [Rossen]
Rossen has joined #css
16:04:28 [SteveZ]
SteveZ has joined #css
16:04:47 [cabanier]
cabanier has joined #css
16:07:18 [TabAtkins_]
ScribeNick: TabAtkins_
16:07:27 [TabAtkins_]
Topic: Future meetings
16:07:42 [TabAtkins_]
dbaron: TPAc is this year, but I think that's all sorted out.
16:07:57 [TabAtkins_]
szilles: Money commitments are there, room hasn't been arranged yet.
16:08:05 [TabAtkins_]
szilles: This is August, it's France, need I say more?
16:08:31 [TabAtkins_]
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 [TabAtkins_]
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 [TabAtkins_]
Molly: How flexible are you about the date?
16:09:55 [TabAtkins_]
Molly: I'll figure out in the next week what the best dates will be, and give you a few choices.
16:10:36 [TabAtkins_]
sylvaing: Early March is fine, but late March is SXSW.
16:10:40 [TabAtkins_]
glazou: I cant' do early march.
16:10:52 [TabAtkins_]
szilles: Mar 16-23 is no good for me.
16:11:18 [TabAtkins_]
florian: end of feb or early march is the best for me.
16:11:34 [TabAtkins_]
Molly: I feel that the early Feb is probably the danger zone.
16:11:59 [TabAtkins_]
Molly: I'm going to look at the week starting Feb 4 or 6.
16:12:11 [TabAtkins_]
szilles: The Gem Show is the 14-17.
16:12:19 [TabAtkins_]
Molly: The week before is when the wholesalers are around.
16:14:01 [TabAtkins_]
Molly: People are possibly okay with Sundays, yes?
16:14:09 [TabAtkins_]
[several]: Yeah, that's fine.
16:14:09 [sylvaing]
SxSW is 3/8-3/17 so Interactive should be 3/8-3/11
16:14:17 [TabAtkins_]
dbaron: So, we said we'd meet in Japan in May.
16:14:28 [TabAtkins_]
dbaron: Since then, the AC meeting was announced as June 9-11 in Japan.
16:14:36 [tantek]
tantek has joined #css
16:14:46 [TabAtkins_]
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 [TabAtkins_]
dbaron: The previous week works fine for me.
16:16:23 [TabAtkins_]
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]
Koji has joined #css
16:17:34 [TabAtkins_]
florian: For the third meeting, perhaps Europe.
16:17:56 [TabAtkins_]
florian: I can't speak for Opera at that point, but we can see.
16:18:16 [TabAtkins_]
TabAtkins_: I can see what G might be able to do in Europe, too.
16:18:45 [TabAtkins_]
dbaron: We may be able to do London or Paris, as well. Depends on when the construction is done.
16:19:31 [TabAtkins_]
jdaggett: I think we should wait to do dates for when Hakon is here, as he often has fall commitments.
16:20:08 [TabAtkins_]
[discussion about being too close to TPAC, maybe hit late August or early Sep]
16:21:07 [TabAtkins_]
glazou: I have a conflict in all of August.
16:23:35 [TabAtkins_]
Topic: CSSOM
16:24:01 [TabAtkins_]
glenn: Update on editting work...
16:24:14 [TabAtkins_]
glenn: I transitioned the format to a preprocessor which I use to generate the docs from IDL.
16:24:27 [TabAtkins_]
glenn: So I'm starting to work through the buglist and some of the new items appearnign on the mailing list.
16:24:47 [TabAtkins_]
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 [TabAtkins_]
glenn: For the items that people asked to discuss here...
16:25:23 [TabAtkins_]
glenn: There was a questioan bout what cssText should return for various rules, such as the contents of a @media rule.
16:25:30 [TabAtkins_]
glenn: Should it be pretty-printed or not?
16:25:49 [TabAtkins_]
florian: Right now, all impls break lines and indent things inside of @media.
16:25:54 [glenn]
16:26:05 [TabAtkins_]
glenn: One thing I'm doing is a link of incoming tests.
16:26:24 [TabAtkins_]
glenn: There are about 130 tests right nwo, and I'm actively expanding those to cover all the interfaces.
16:26:38 [TabAtkins_]
glenn: I'll put one in to test the media behavior you're describing.
16:27:09 [TabAtkins_]
florian: Though, now that we're getting nested @media, the indentation is not interop.
16:27:51 [TabAtkins_]
florian: Opera does proper increasing indentation, but Firefox doesn't - they're all 2-space in.
16:28:08 [TabAtkins_]
florian: Unfortunately, authors depend on silly details of the serialization, so interop is often important here.
16:28:28 [TabAtkins_]
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 [TabAtkins_]
jdaggett: So I'm not sure one particular type of whitespace is better than another.
16:29:19 [TabAtkins_]
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 [TabAtkins_]
glenn: Will we have exceptions for certain rules, or will this be a generic rule for all the parts of CSS?
16:30:23 [TabAtkins_]
florian: Not sure. It seems easy enough to be consistent, though.
16:30:47 [TabAtkins_]
glenn: Yesterday we were takling about preserving whtiespace and comments in @supports.
16:31:09 [TabAtkins_]
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]
miketaylr has joined #css
16:31:38 [TabAtkins_]
florian: I think we should only do exact preservation in @supports condition, and just reserialize otherwise.
16:31:44 [jdaggett]
jdaggett has joined #css
16:32:00 [Molly]
16:32:03 [TabAtkins_]
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 [TabAtkins_]
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]
Zakim has joined #css
16:33:52 [TabAtkins_]
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 [TabAtkins_]
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 [TabAtkins_]
glazou: Testing is not a target for CSS.
16:35:47 [TabAtkins_]
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 [TabAtkins_]
florian: Opera also does the indentation on @keyframes.
16:37:50 [TabAtkins_]
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 [TabAtkins_]
florian: Our policy seems to be that at-rules that contain rules are indented, while ones that contain descriptors are not.
16:39:10 [TabAtkins_]
glazou: What about groups of selectors? Many authors put newlines after commas in selectors.
16:39:20 [TabAtkins_]
florian: No one does anything like that for now - selectors are just on one page.
16:39:32 [vhardy_]
vhardy_ has joined #css
16:39:41 [hober]
16:40:06 [vhardy__]
vhardy__ has joined #css
16:41:02 [TabAtkins_]
glazou: Is it naive to ask for a pretty-printer built in natively?
16:41:08 [TabAtkins_]
[some discussion about it]
16:41:42 [TabAtkins_]
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 [TabAtkins_]
dbaron: I don't think it's really necessary at all. This is not something that's commonly used.
16:42:21 [TabAtkins_]
glazou: Would you be okay with me and Florian investigating how to serialize rules across CSS?
16:42:43 [TabAtkins_]
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 [TabAtkins_]
glenn: I hope to finish the value stuff this week.
16:44:33 [TabAtkins_]
glazou: One thing I noticed that is missing a cssText is the Stylesheet object. We should fix that.
16:44:53 [TabAtkins_]
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 [TabAtkins_]
s/some things/some cssText attributes/
16:45:40 [TabAtkins_]
dbaron: Every once in a while, someone will submit a webkit patch making one of their setters work.
16:46:17 [TabAtkins_]
florian: Do you know why they might have been made readonly?
16:46:46 [TabAtkins_]
dbaron: A combination of just not bothering to do it, or assuming that the spec meant to make things readonly.
16:48:00 [TabAtkins_]
glenn: Do you have any places where you think it should be readonly?
16:48:26 [TabAtkins_]
dbaron: For example, on @media - do authors really want to do this?
16:49:53 [TabAtkins_]
TabAtkins_: I think that it's about as useful as innerHTML, which is allowed everywhere.
16:50:18 [TabAtkins_]
dbaron: Looks like Firefox only makes it mutable in *one* instance - on CSSStyleDeclaration that doesn't come from getComputedStyle.
16:50:40 [dbaron]
dbaron: what happens when you set mediaRule.cssText = "@keyframes foo { ... }" ???
16:51:03 [dbaron]
dbaron: The spec needs more than the lack of the word "readonly" for this to be implementable.
16:51:36 [TabAtkins_]
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 [TabAtkins_]
Topic: global CSS object
16:54:00 [TabAtkins_]
glazou: Any issues with that?
16:54:52 [TabAtkins_]
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 [TabAtkins_]
Topic: @font-face OM definition
16:56:09 [TabAtkins_]
glenn: Since John is doing @font-face in Fonts, should I remove those definitions from CSSOM?
16:56:41 [TabAtkins_]
jdaggett: I didn't redefined @font-face, I just added @font-features
16:57:09 [TabAtkins_]
glenn: Okay, my mistake. So should I add some guidance about defining new at-rules in OM?
16:57:14 [TabAtkins_]
[several]: YES
16:58:16 [TabAtkins_]
glenn: What about coordinating the constants for new rule types?
16:58:47 [TabAtkins_]
TabAtkins_: There's a wiki page about that on the csswg wiki, under Planning.
16:58:57 [TabAtkins_]
glenn: Would you mind an informative note pointing to that page?
16:59:00 [TabAtkins_]
TabAtkins_: No, that's great.
16:59:03 [TabAtkins_]
Topic: Regions.
16:59:13 [TabAtkins_]
stearns: We've been going through feedback on Regions.
16:59:26 [TabAtkins_]
stearns: The feedback on the OM has been very useful. The ED has gone through a lot of revisions.
16:59:38 [TabAtkins_]
stearns: So I'd like to publish a new WD to reflect those updates.
16:59:50 [TabAtkins_]
RESOLVED: Publish a new WD of Regions.
17:00:34 [TabAtkins_]
florian: One thing about regions...
17:01:14 [TabAtkins_]
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 [TabAtkins_]
jdaggett: Perhaps an issue in the spec about it.
17:01:45 [TabAtkins_]
stearns: We have somep atches in WebKit already about region styling.
17:01:59 [TabAtkins_]
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 [TabAtkins_]
stearns: But I'd like to have that shake out before I make changes to the spec.
17:02:33 [TabAtkins_]
stearns: But I'll add an issue on the @region syntax if there isn't already one.
17:03:09 [TabAtkins_]
Topic: Exclusions
17:03:23 [TabAtkins_]
Rossen: We've made a lot of editorial changes to the spec, such as updating a lot of images.
17:03:34 [Rossen]
17:03:40 [TabAtkins_]
Rossen: One discussion we tried to revive was "Issue 1" in the spec, which was put in by dbaron.
17:03:48 [TabAtkins_]
Rossen: [reads the issue]
17:05:52 [TabAtkins_]
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 [TabAtkins_]
Rossen: So if you want to do abspos exclusions, you're allowed to.
17:06:20 [TabAtkins_]
Rossen: I don't see any reason to make an exception here and disallow one type of positioning.
17:06:49 [TabAtkins_]
Rossen: I'd like to show a demo of exclusions used in grid, with no abspos.
17:08:19 [TabAtkins_]
Rossen: [shows demo]
17:10:20 [krit]
krit has joined #css
17:12:05 [arronei_]
arronei_ has joined #css
17:13:48 [glazou]
florian, don't play your Håkon :-)
17:14:00 [TabAtkins_]
dbaron: I'd like to explain why this demo doesnt' work well.
17:14:17 [TabAtkins_]
dbaron: First, unless you explicitly handle paging, you'll have to scroll up and down for these multicol things.
17:15:46 [TabAtkins_]
dbaron: Now, if you produce more content, how is this exclusion paginated?
17:16:01 [TabAtkins_]
TabAtkins_: I'ts just put in a cell in the grid, so that depends on how grids are paginated.
17:16:24 [TabAtkins_]
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 [TabAtkins_]
Rossen: These questions seem to be about page templates in general, not about exclusions at all.
17:17:32 [florian]
17:17:42 [florian]
florian has left #css
17:17:45 [florian]
florian has joined #css
17:17:49 [florian]
17:19:14 [TabAtkins_]
Rossen: The placement of exclusions is driven by the templating system.
17:19:32 [TabAtkins_]
Rossen: Like a bunch of grids that are placed one after the other for content that flows through them.
17:20:28 [TabAtkins_]
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 [TabAtkins_]
szilles: I don't see a connection between what's being said here.
17:20:51 [TabAtkins_]
szilles: David is seeing a document with a bunch of static declarations putting things in various places.
17:20:55 [stearns]
17:21:12 [TabAtkins_]
szilles: He's wondering where these should go as pages vary or disappear entirely.
17:21:35 [TabAtkins_]
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 [TabAtkins_]
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 [glazou]
Zakim, ack florian
17:22:05 [Zakim]
I see stearns on the speaker queue
17:22:10 [TabAtkins_]
florian: Yes, this seems to be the difference in approach.
17:22:18 [TabAtkins_]
florian: We want to allow JS, but not rely on it.
17:22:21 [TabAtkins_]
florian: So if that's th emodel, that's a problem.
17:22:39 [TabAtkins_]
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 [TabAtkins_]
florian: For floats as we have them so far, there's a collision system built into the model.
17:23:11 [TabAtkins_]
florian: So you can't make an exclusions model that doesn't have a collision system.
17:23:26 [TabAtkins_]
florian: Your model is more expressive - you can do *lots* of different things with it.
17:23:42 [TabAtkins_]
florian: But by not combining it with a collision model, you lose the safety of floats.
17:24:00 [TabAtkins_]
florian: You're saying that people will deal with it by using something else. But they might not do that.
17:24:18 [smfr]
smfr has joined #css
17:24:36 [TabAtkins_]
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 [glazou]
Zakim, ack stearns
17:24:39 [Zakim]
I see no one on the speaker queue
17:24:46 [TabAtkins_]
stearns: Two points - text wrapping is meant for occasions when things collide.
17:24:59 [TabAtkins_]
stearns: Floats are allowed to collide witht he inline content, but text wraps around them.
17:25:21 [TabAtkins_]
stearns: Exclusions should be orthogonal to collision handling. You're *trying* to create a collision.
17:26:00 [TabAtkins_]
TabAtkins_: He's talking about multiple exclusions sitting on the same point and colliding with each other.
17:26:07 [TabAtkins_]
stearns: I think that's sometimes desirable.
17:26:33 [TabAtkins_]
stearns: Back to the beginnign example, if you have two fo these exclusions on a page and that was unintended,
17:26:38 [TabAtkins_]
stearns: If they're floats, you get float stacking behavior.
17:26:52 [TabAtkins_]
stearns: In most layout modes I've had experience with, float stacking is an error. Nobody wants that to occur.
17:26:56 [dbaron]
17:27:01 [TabAtkins_]
stearns: What you get out of float stacking is not anything a designer would actually want.
17:27:19 [TabAtkins_]
stearns: So I think we need some additional controls for handling how things get arranged when a collision occurs.
17:27:40 [TabAtkins_]
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 [TabAtkins_]
dbaron: Like "if I don't ahve space, go to the next page".
17:28:09 [TabAtkins_]
stearns: That would be great. But I think it should be orthogonal to exclusions.
17:28:28 [TabAtkins_]
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 [TabAtkins_]
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 [TabAtkins_]
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 [TabAtkins_]
stearns: I think that 99% of the time, you'll have a single exclusion, so conflicts won't happen.
17:30:39 [vhardy_]
vhardy_ has joined #css
17:30:41 [TabAtkins_]
florian: I'm worried that it's just too easy to do this kind of thing with bad-behaving abspos.
17:31:15 [TabAtkins_]
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 [TabAtkins_]
[argument about usefulness of abspos]
17:32:23 [stearns]
17:32:50 [TabAtkins_]
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 [TabAtkins_]
Rossen: Floats are an extremely document-centric tool that's intended to work in a single flat flow of textual content.
17:33:57 [TabAtkins_]
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 [TabAtkins_]
[argument about running into things by default, or avoiding by default]
17:36:00 [TabAtkins_]
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 [TabAtkins_]
glazou: I feel that you're afraid of people abusing or just inexpertly using features.
17:37:29 [TabAtkins_]
17:37:42 [TabAtkins_]
glazou: Whatever we do, users will find ways to use it badly and good.
17:38:13 [TabAtkins_]
florian: We shouldn't try to prevent bad behavior - that's impossible. We should make good behavior the default, though.
17:38:27 [sylvaing]
it's entirely possible that there is no 'ideal' default here
17:38:58 [dbaron]
Tab: Vincent, their point is that it doesn't talk about positioning -- that's *why* it gets bad behavior by default.
17:39:59 [TabAtkins_]
florian: You're seeing the complete independence of layout modes as a feature, I'm seeing this as a bug.
17:40:25 [dbaron]
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 [dbaron]
stearns: The simplest case possible is a single exclusion.
17:41:45 [dbaron]
stearns: would like to discuss on mailing list
17:41:51 [TabAtkins_]
szilles: I think they want graceful degradation under normal circumstances on the web.
17:42:39 [TabAtkins_]
[more chaos]
17:42:40 [dbaron]
Sylvain: We've had this discussion in 3 cities now.
17:42:57 [dbaron]
dbaron: What's new this time?
17:43:58 [dbaron]
Florian: Extend floats to cover more use cases, rather than ...
17:44:07 [dbaron]
glazou: This is not being minuted.
17:44:16 [dbaron]
Tab: This same discussion has been minuted twice already.
17:44:20 [dbaron]
glazou: This discussion has to be minuted.
17:44:22 [vhardy_]
17:44:29 [dbaron]
ack dbaron
17:44:30 [fantasai]
twice is an understatement, I'm pretty sure it's more than that...
17:45:01 [dbaron]
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 [dbaron]
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 [dbaron]
Steve: It's not proven to me that it introduces the problem.
17:45:32 [dbaron]
ack vhardy_
17:45:58 [dbaron]
vincent: the discussion we haven't been able to resolve is that ... exclusions & absolute positioning
17:46:02 [dbaron]
Florian: doesn't say that
17:46:18 [dbaron]
vincent: here exclusions has a model such that you can use it with other positioning schemes
17:46:31 [dbaron]
vincent: The other option is to say that exclusions don't work with that positioning scheme.
17:46:48 [dbaron]
vincent: Specification takes care to make a generic model. The repeated thing that says it's bad
17:46:58 [dbaron]
vincent: The issue is an incorrect characterization of the problem.
17:47:06 [dbaron]
vincent: I'd be ok with a specific technical issue the spec has
17:47:09 [dbaron]
17:47:34 [dbaron]
vincent: ... not with generic issues that the spec
17:48:10 [florian]
not with generic issues about the spec relying on abspos because that's not true
17:48:12 [glazou]
vincent: but not with saying the spec relies on abspos because it's not the case
17:48:37 [TabAtkins_]
17:48:55 [TabAtkins_]
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 [TabAtkins_]
stearns: Can we put that in the issue?
17:49:43 [TabAtkins_]
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 [TabAtkins_]
stearns: There's a discussion on the mailing list where florian said something like this.
17:50:32 [TabAtkins_]
stearns: I said that I'd be fine with exchanging the current issue text with what florian provided.
17:50:54 [TabAtkins_]
stearns: If dbaron could respond and say that's okay, we'd be great.
17:51:23 [TabAtkins_]
szilles: I can add a property that says "avoid collisions", and define what it does.
17:51:36 [vhardy_]
17:51:37 [TabAtkins_]
dbaron: It's really not that simple.
17:51:43 [TabAtkins_]
szilles: That's what XSL did.
17:51:50 [TabAtkins_]
ack TabAtkins_
17:52:41 [TabAtkins__]
TabAtkins__ has joined #css
17:53:13 [dbaron]
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 [dbaron]
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 [dbaron]
Florian: Even though I proposed that I'm not sure it's enough.
17:53:43 [glazou]
tantek: +1
17:53:50 [dbaron]
Florian: ... go in the direction of making the current exclusion model less bad.
17:54:07 [dbaron]
Florian: If we can add sufficient ..., then I think the exclusion model could survive.
17:54:16 [dbaron]
Florian: If it turns out we can't enough, then we may have to look at another approach.
17:56:40 [jet]
jet has joined #CSS
18:05:12 [glazou]
krit, around 1:15pm local time
18:05:23 [krit]
glazou: great thanks!
18:10:11 [drublic]
drublic has joined #css
18:18:20 [glazou]
ScribeNick: tantek
18:18:22 [tantek]
Zakim, I am the scribe
18:18:22 [Zakim]
I don't understand 'I am the scribe', tantek
18:18:41 [Molly]
Molly has joined #css
18:18:50 [tantek]
rossen: it would be great if we can reword the current issue to state the technical problem
18:19:09 [tantek]
rossen: exclusions as defined do not provide mechanism for avoiding exclusion to exclusion collisions if/when they are abs pos'd
18:19:22 [tantek]
florian: that is narrower than what I meant to say
18:19:41 [tantek]
florian: we need to prove that a collision handling system compatible with exclusions is possible
18:19:48 [tantek]
florian: the best way to do that is to design one
18:19:56 [drublic]
drublic has joined #css
18:19:58 [tantek]
florian: whether it should be optional is a different question
18:20:22 [tantek]
florian: missing bits: collision handling, preventing things from disappearing off the page
18:20:28 [tantek]
rossen: so changing how abs pos works?
18:20:32 [vhardy_]
vhardy_ has joined #css
18:20:52 [tantek]
florian: what the objectors want to see, is the addition of extra mechanisms to handle those missing bits
18:21:03 [tantek]
… that apply to all layout schemes
18:21:19 [tantek]
… that can be used to workaround the collisions and graceful degradation issues
18:21:24 [tantek]
rossen: could you summarize as an issue?
18:22:07 [tantek]
ACTION Florian: summarize the issue of missing mechanism(s) to handle collision handling, preventing things from disappearing off the page
18:22:07 [trackbot]
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 [tantek]
vincent: would like illustrations of things that have been characterized as bad things
18:22:42 [tantek]
florian: I will give some examples
18:23:05 [tantek]
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 [tantek]
ACTION Florian: come up with examples illustrating the issues on exclusions as noted in previous action 496
18:23:46 [trackbot]
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 [tantek]
Florian: to move forward I have a modest proposal for collision handling
18:24:34 [tantek]
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 [tantek]
florian: proposing new property, let's call it 'collision'
18:24:52 [tantek]
florian: … auto | allow | avoid
18:25:03 [tantek]
… auto computes to allow to preserve existing behavior
18:25:24 [tantek]
… 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 [tantek]
… how it is moved out of the way - up to discussion
18:25:41 [tantek]
… e.g. if there is room to the right, move it to the right, otherwise move it down
18:25:56 [tantek]
… could also have another property 'collision-mode'
18:26:05 [tantek]
… to switch between different kinds of clearance systems
18:26:20 [tantek]
… for now just need a way to say let things collide, or avoid the collision
18:26:27 [lstorset]
lstorset has joined #css
18:26:43 [tantek]
vincent: do you foresee this for all positioning schemes?
18:26:48 [tantek]
florian: yes
18:27:02 [tantek]
vincent: e.g. also for grid?
18:27:11 [tantek]
vincent: a 2x3 grid
18:27:15 [tantek]
florian: in general yes
18:27:22 [tantek]
… property should be available to all layout modes
18:27:38 [tantek]
… if there are layout modes where we don't understand what 'avoid' means, we can make it compute to 'allow'
18:27:43 [tantek]
… for example for floats
18:27:48 [tantek]
… auto would compute to 'avoid'
18:27:53 [tantek]
… if you turn it to allow
18:28:03 [tantek]
… then you could have something like this (goes to whiteboard)
18:30:05 [tantek]
vincent: this may introduce behaviors in all other schemes
18:30:17 [tantek]
florian: I'm going to have auto compute to whatever existing schemes do for each
18:30:29 [tantek]
… e.g. on floats to 'avoid', on abs pos to 'allow'
18:30:45 [tantek]
… on top of that I would add
18:30:50 [tantek]
… because we are introducing exclusions now
18:30:58 [tantek]
… because they are likely to increase use of abs pos
18:31:02 [tantek]
… we have a chance of fixing it there
18:31:10 [tantek]
… on abs pos to which exclusions is applied
18:31:16 [tantek]
… auto should compute to 'avoid'
18:31:31 [tantek]
vincent: why are exclusions encouraging use of abs pos?
18:31:48 [tantek]
florian: i can answer, but it has been answered already
18:31:51 [tantek]
… a bunch of times
18:32:20 [tantek]
vincent: it's a different question
18:32:27 [tantek]
florian: it's the same, we've answered it a bunch of times
18:32:33 [tantek]
… it's maybe not answered well
18:32:40 [tantek]
fantasai: we keep having this same question/discussion
18:33:10 [tantek]
vincent: why do you think exclusions are encouraging the use of abs pos?
18:33:22 [tantek]
florian: i've answered this, but i would like to time answer it better.
18:33:30 [tantek]
zilles: vincent, why is the answer important?
18:33:45 [tantek]
peter: given exclusions, people will use abs pos more. i see that as a good thing.
18:33:57 [tantek]
peter: i have a question for you (vincent)
18:34:03 [tantek]
correction for florian
18:34:08 [fantasai]
18:34:24 [fantasai]
vincent, search for "But exclusions make abspos more attractive by avoiding"
18:34:54 [tantek]
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 [tantek]
florian: this is a small but significant misunderstanding
18:35:27 [tantek]
… when the collision property computes to 'avoid', it avoids other things that have 'avoid'
18:35:37 [tantek]
e.g. if you have 2 abs pos *both* with 'avoid' they will avoid each other
18:35:40 [tantek]
… but not others
18:35:45 [drublic]
drublic has joined #css
18:35:53 [tantek]
rossen: if they're on top of another exclusion?
18:36:01 [tantek]
florian: if you want a collision...
18:36:09 [tantek]
rossen: how do you avoid one but not the other
18:36:17 [tantek]
… you are giving me only a binary choice
18:36:22 [tantek]
… I want to avoid some but not others
18:36:34 [tantek]
tabatkins: what's the use case for it?
18:36:43 [tantek]
rossen: 15 or so examples in the wiki
18:36:52 [tantek]
stearns: www-style list post from apple
18:37:10 [tantek]
florian: you have several examples where exclusions are supposed to be on top of each other, but avoid some other
18:37:15 [dbaron]
So far, I don't like this 'collision' proposal all that much, but I'd like to think about it more.
18:37:30 [tantek]
florian: i don't think you have such things in the examples
18:37:44 [tantek]
zilles: you have a notion of grouping which acts as an entity and an exclusion goes into the group
18:37:53 [tantek]
… that would allow you to define an appropriate method of the exclusion process
18:38:10 [tantek]
florian: if it's really important we can do it, but i don't think it is necessary
18:38:49 [tantek]
florian: this is most useful on abs pos which have exclusions turned on
18:38:55 [tantek]
(in response to a q from vincent)
18:39:03 [tantek]
florian: the whole point I designed this
18:39:07 [tantek]
… is to try to save exclusions
18:39:13 [tantek]
… from the folks that say it won't work
18:39:39 [tantek]
vincent: are you proposing to work on the exclusions spec?
18:39:56 [tantek]
florian: I'm interested in working on everything, not sure I can commit the time.
18:40:04 [tantek]
… I am putting this out there, hoping folks find it interesting
18:40:11 [tantek]
… not promising I can carry it forward (time)
18:40:24 [tantek]
zilles: this is a proposal that you believe might lead to a suitable graceful degradation
18:40:42 [tantek]
florian: this is one piece of a solution to make exclusions acceptable, not sure it is sufficient
18:41:17 [tantek]
… this is useful, otherwise half the group will object to exclusions
18:41:34 [tantek]
molly: i can see this being very logical from the author perspective, useful in the scenario you described
18:41:57 [tantek]
… would be useful on a global thing
18:42:04 [tantek]
… any time you might have a collision
18:42:07 [tantek]
… to have that choice
18:42:11 [tantek]
… what would be the default be?
18:42:19 [tantek]
florian: for abs pos, allow, for floats, avoid
18:42:25 [tantek]
… just have to work out the layout modes one by one
18:42:48 [tantek]
… it may be tricky where collisions seem impossible
18:42:51 [tantek]
… e.g. in flexbox
18:43:09 [tantek]
… so what should we do?
18:43:17 [Bert]
q+ to suggest using grid templates (of course :-) ), i.e., replacing abspos instead of trying to enhance it...
18:43:20 [tantek]
… I think we can work it out for layout modes where collisions are *possible*
18:43:31 [tantek]
… and we can use 'auto' to preserve the existing behavior
18:43:35 [tantek]
Molly: would be useful
18:43:44 [tantek]
Peter: this is scary when layout modes intersect
18:44:00 [tantek]
… flex box, abs pos on top of it with avoid, what moves?
18:44:13 [tantek]
florian: with abs pos and float, we can move floats out of the way
18:44:20 [tantek]
… with flexbox there might not be an answer
18:44:32 [tantek]
… we may have to just say that with flexbox it computes to 'allow'
18:44:53 [tantek]
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 [tantek]
florian: respect document order, don't move the first one.
18:45:09 [tantek]
… the 2nd one moves out of the way
18:45:19 [tantek]
… if we don't find an avoidance behavior for flexbox they'll avoid
18:45:30 [tantek]
CORRECTION: they'll overlap
18:45:39 [tantek]
… if we do find an avoidance behavior, they'll avoid
18:45:47 [tantek]
zilles: at the risk of complicating things
18:45:52 [tantek]
… in grid, the default is that they overlay
18:45:57 [tantek]
… e.g. two things in one grid cell
18:46:05 [tantek]
… Bert's templates had the items stacking
18:46:17 [tantek]
… there's at least one option of saying avoid on things in a grid cell
18:46:20 [tantek]
… we could make them avoid
18:46:30 [tantek]
bert: that's a way to define exclusion, and then that's the grid
18:46:51 [tantek]
… either use grid-column and grid-row to put it there, it will overlap
18:47:00 [tantek]
… or the flow property and it will not overlap
18:47:35 [tantek]
(references previous a grid diagram on the whiteboard a a a … b … c c … )
18:47:43 [tantek]
but it's not an extension of abs pos
18:47:50 [tantek]
… it's an alternative way of doing the same thing.
18:48:23 [Bert]
18:48:28 [tantek]
florian repeats statement about defining for all modes.
18:48:36 [Bert]
18:49:13 [tantek]
molly: I think you're solving what will become a design problem for designers
18:49:15 [tantek]
… no comment on syntax
18:49:16 [vhardy_]
18:49:21 [tantek]
… but makes sense and would be teachable
18:49:45 [tantek]
Florian: do the people who object to exclusions feel better if something like this is in place?
18:49:51 [tantek]
Florian: just Tab?
18:49:59 [tantek]
Florian: I will try to write something up
18:50:46 [tantek]
florian: where should it go?
18:50:58 [tantek]
rossen: would prefer in positioning
18:51:02 [tantek]
… CSS3 Positioning
18:51:27 [arronei_]
It works for me in CSS Positioning.
18:51:38 [tantek]
rossen: to me this makes sense to go with positioning.
18:51:45 [arronei_]
Rossen you and I can put all this in there
18:51:52 [tantek]
molly: I also see this as a relevant approach to add control
18:52:00 [tantek]
rossen: even if they're not exclusions
18:52:02 [tantek]
molly: yeah
18:52:10 [tantek]
florian: I want to make it work universally
18:52:47 [tantek]
Florian's diagram from that he drew on the whiteboard:
18:53:36 [tantek]
florian: you can give me an action item
18:53:53 [tantek]
ACTION Florian: write a draft proposal for the 'collision' property with values: auto | avoid | allow
18:53:54 [trackbot]
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 [tantek]
18:54:54 [tantek]
18:55:10 [tantek]
section 4.3
18:55:18 [vhardy__]
vhardy__ has joined #css
18:55:25 [tantek]
of css4 image values and replace content module
18:55:31 [tantek]
18:55:37 [tantek]
regarding responsive images
18:56:07 [tantek]
shows example 10
18:56:27 [tantek]
TabAtkins: describes the example
18:56:39 [tantek]
… 1x, 2x, 600dpi
18:57:01 [tantek]
daniel: why not use media queries?
18:57:20 [tantek]
TabAtkins__: defining connection speed, and when you want to download something is VERY difficult
18:57:31 [tantek]
.. even just doing 2 modes low/high is difficult.
18:57:40 [tantek]
Florian: allows the browser to only download one
18:57:51 [tantek]
TabAtkins__: can also result in perverse behavior
18:58:24 [tantek]
… 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 [tantek]
hober: mqs are about the display
18:58:47 [tantek]
florian: if we're dealing with bandwidth, there's no way to do with mqs
18:59:04 [tantek]
… OTOH dealing with bandwidth is so hard, that not convinced browser may be able to do it anyway
18:59:12 [tantek]
TabAtkins__: quality of implementation
18:59:20 [tantek]
… browser can do better
18:59:31 [tantek]
florian: if no one does better then this was pointless
18:59:43 [tantek]
… would be nice if browsers did something with bandwidth though
18:59:50 [tantek]
vincent: src-set?
18:59:54 [hober]
See also "Why a scale factor and not a full-blown media query" in
18:59:55 [tantek]
TabAtkins__: this is the css version of src-set
19:00:02 [tantek]
TabAtkins__: 3 issues
19:00:17 [tantek]
… 1. inconsistency with src-set
19:00:22 [tantek]
… suggestion: be consistent
19:00:37 [tantek]
hober: agreed
19:00:48 [tantek]
TabAtkins__: I do have one bit I'd like to keep
19:00:55 [tantek]
… you can specify a fallback color at end
19:01:02 [tantek]
… useful if browser can't download any image
19:01:12 [tantek]
… or on such a bad connection, browser decides to not download
19:01:16 [tantek]
… and just use color
19:01:21 [tantek]
… but we should drop other fallbacks.
19:01:30 [tantek]
hober: this is nice
19:01:43 [tantek]
vincent: i have a question
19:01:53 [tantek]
… user agent is presented with list of possible things, hints about resolution
19:01:58 [tantek]
… what if i have vector image for fallback
19:02:01 [tantek]
… but doesn't have hinting
19:02:08 [tantek]
… sometimes for icons you want hinting
19:02:19 [tantek]
… in cases like that am I still allowed to make those trade-offs?
19:02:27 [tantek]
… vector is high resolution but has benefit of being tiny
19:02:32 [tantek]
… would that be possible?
19:02:44 [tantek]
TabAtkins__: so on a highres device use SVG, on lowres use icon?
19:02:50 [tantek]
florian: and ....
19:02:55 [tantek]
TabAtkins__: I think you can do that
19:03:06 [tantek]
… with 2 diff resolution descriptors
19:03:18 [tantek]
… one very high resolution, and one very low bandwidth
19:03:32 [tantek]
florian: syntax is not ideal, but it is possible
19:03:56 [tantek]
fantasai: vincent's point/scenario above is a good one to note
19:04:08 [tantek]
TabAtkins__: don't adjust the resolution if you choose the image
19:04:18 [tantek]
… this is for a high res device, but nothing special has to be done to it.
19:04:51 [tantek]
Action TabAtkins: to address issue of where to put an SVG image for high resolution and low bandwidth in image-set.
19:04:51 [trackbot]
Sorry, couldn't find user - TabAtkins
19:05:03 [tantek]
Action Tab: address issue of where to put an SVG image for high resolution and low bandwidth in image-set.
19:05:03 [trackbot]
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 [tantek]
vincent: in the version of image-set and src-set, there was more than just resolution, e.g. width/height
19:05:42 [tantek]
TabAtkins__: the reason is that src-set in HTML also allows width/height
19:05:48 [tantek]
… that doesn't show up in image-set
19:05:52 [tantek]
… because they are just MQs
19:05:59 [tantek]
… you can do those easily in CSS
19:06:07 [tantek]
… but you can't in HTML, that's why they're in src-set
19:06:20 [tantek]
Florian: the question is whether you can use full MQ syntax in HTML
19:06:40 [tantek]
… some don't want to, hence those features in the HTML version separate from MQs.
19:06:50 [tantek]
vincent: another issue was co-location of rules in style sheets
19:06:57 [tantek]
… e.g. your image resource in one place
19:07:02 [tantek]
… various conditions under which it would be used
19:07:07 [tantek]
… are you considering that now?
19:07:14 [tantek]
TabAtkins__: I remember seeing that suggestion
19:07:20 [tantek]
… this is not the right place to address that
19:07:29 [tantek]
… if we want to address MQs move conditions too far
19:07:35 [tantek]
… away from properties
19:07:43 [tantek]
… then we should address that by allowing nesting MQs
19:07:50 [tantek]
… not just for image functionality.
19:08:16 [tantek]
Peter: I like aligning with src-set, but I see the fallback behavior as useful.
19:08:27 [tantek]
Hober: purpose of the image function to do the decode fall back thing
19:08:31 [tantek]
… they're composable.
19:08:36 [tantek]
Peter: combining them will get ugly
19:08:45 [tantek]
Hober: combining them is not a common use-case
19:08:55 [vhardy_]
vhardy_ has joined #css
19:09:01 [tantek]
Peter: what will happen is someone point to one version then a high resolution
19:09:10 [tantek]
… and print version will get lost / 404
19:09:28 [tantek]
TabAtkins__: my use-case for this is being able to send down just one image
19:09:35 [tantek]
… rather than having to download multiple versions
19:09:45 [tantek]
… extra latency can be very harmful to page behavior
19:10:06 [tantek]
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 [tantek]
TabAtkins__: but that causes the bad behavior
19:10:24 [tantek]
florian: you're choosing between slow display and no display
19:10:37 [tantek]
dbaron: the other question is when do authors see that things are broken?
19:10:49 [tantek]
… e.g. if it goes and downloads a different one, then authors won't notice first problem.
19:11:05 [tantek]
Peter: then it gets back to philosophy debate of how things should fail gracefully or not
19:11:13 [tantek]
… whether you should have a fail-early mode for authors to check their pages
19:11:23 [tantek]
… in general browsers tend to do the right thing for users
19:11:39 [tantek]
Florian: how about we keep the fallback behavior and ask src-set to add it
19:11:49 [tantek]
florian: there is no downside for them here that's not here for us
19:12:11 [tantek]
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 [tantek]
hober: having a combination allows the author to explicitly choose what they want to do in those scenarios.
19:12:36 [tantek]
fantasai: then you have to repeat. e.g.
19:12:51 [tantek]
… combinatorial explosion of image sets within image sets
19:13:32 [tantek]
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 [tantek]
fantasai: you have to repeat the entire list
19:13:53 [tantek]
TabAtkins__: the alternate way is, here is a fallback image if you can't use the one in the image-set
19:14:03 [tantek]
florian: unless the fallback is the one that failed to load
19:14:11 [tantek]
… then you need a fallback for the fallback
19:14:19 [tantek]
peter: the other problem is different fallback behaviors
19:14:31 [tantek]
… e.g. if browser picks medium one, and it fails, which one should it fallback to?
19:14:35 [tantek]
hober: the author should choose
19:14:52 [tantek]
peter: doesn't know what the browser is seeing
19:14:54 [tantek]
florian: add MQs on top of that then
19:14:59 [tantek]
… this is going to be a mess
19:15:09 [tantek]
hober: does anyone want to implement the crazy fallback situation in this case/
19:15:10 [tantek]
19:15:26 [tantek]
fantasai: it's just like having image but browser gets to pick the order
19:15:47 [tantek]
florian: we can try to align, and then make src-set align, and then if they refuse we can revisit
19:15:55 [tantek]
florian: it doesn't slow down the main use case
19:16:12 [tantek]
TabAtkins__: it doesn't slow down the everything works case, we care about the recovery behavior
19:16:22 [tantek]
… whether to do more connections automatically
19:16:31 [tantek]
… or have the author make that choice explicitly
19:16:45 [tantek]
TabAtkins__: most people on mobile connections don't want to download more connections
19:16:54 [tantek]
Hober: point is to avoid extra connections
19:17:00 [tantek]
Peter: no, point is to pick the right image
19:17:12 [tantek]
florian: downloading both to figure out which one to use is a waste of time
19:17:19 [tantek]
… either you look like crap or you dont'
19:17:25 [Bert]
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 [tantek]
peter: on a retina display, if high res version fails
19:17:43 [tantek]
… then I'm going to fallback with lower res version
19:17:48 [tantek]
… going to wind up with smaller data usage
19:18:17 [tantek]
florian: I think we should ask src-set to get the fallback behavior as well
19:18:20 [tantek]
TabAtkins__: I'm fine with that
19:18:38 [tantek]
… asking HTML about that
19:18:59 [tantek]
Bert: I'm wondering given all the other things we have to talk about
19:19:04 [tantek]
… should we really be discussing this?
19:19:08 [tantek]
… we can just use SVG
19:19:20 [tantek]
TabAtkins__: it has nothing to do with resolution negotiation
19:19:27 [tantek]
Bert: SVG uses SMIL
19:19:32 [tantek]
… switch statement
19:19:41 [tantek]
Florian: does not take bandwidth into account
19:19:48 [tantek]
Bert: lots of work on this
19:19:56 [tantek]
… why are we doing it at all?
19:20:05 [tantek]
florian: HTML is solving it for content, we need it for css
19:20:14 [tantek]
bert: should it be solved independent?
19:20:22 [tantek]
19:20:24 [tantek]
2 of 3
19:20:30 [tantek]
TabAtkins__: the ex unit
19:20:38 [tantek]
… it is a synonym for dppx unit
19:20:44 [tantek]
… should it use resolution unit
19:20:46 [tantek]
… or ...
19:21:07 [tantek]
TabAtkins__: (summarizes issue)
19:21:17 [tantek]
Peter: I don't think we should have the 'x' unit
19:21:21 [tantek]
s/ex/x above
19:21:35 [tantek]
Peter: I don't want a synonym
19:21:44 [tantek]
Hober: x just describes a scale factor
19:21:51 [tantek]
florian: HTML has the x unit
19:22:01 [tantek]
… we have the resolution thing already and not care about the x
19:22:11 [tantek]
hober: the resolution units are terrible and we shouldn't propagate them further
19:22:47 [tantek]
TabAtkins__ and hober argue about dpi vs dppx
19:22:47 [Bert]
(Re bandwidth: the SWITCH element does take bandwidth into account, via the systemBitrate attribute.)
19:23:54 [tantek]
florian: I think using resolution here is fine, I don't think we need 'x'
19:24:06 [tantek]
TabAtkins__: dppx is the worst name for a unit
19:24:30 [tantek]
… ddpx is an easy typo to make
19:24:33 [tantek]
… it's done a lot
19:24:50 [tantek]
fantasai: is it too late to change now? we have a CR
19:24:52 [tantek]
… we have implementations
19:24:58 [tantek]
TabAtkins__: dpi or dpcm?
19:25:06 [tantek]
zilles: it's not going to please half of the people
19:25:24 [tantek]
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]
jet has joined #CSS
19:25:36 [tantek]
Vincent: question - one is resolution vs length?
19:25:45 [tantek]
TabAtkins__: no, dppx is dots per pixel. not a length.
19:26:01 [dbaron]
I actually think x as a synonym for dppx is pretty reasonable.
19:26:02 [tantek]
florian: just use resolution here, in addition if you want 'x' to be a synonym, let's discuss elsewhere
19:26:13 [tantek]
… if we introduce 'x' i want it everywhere
19:26:17 [tantek]
TabAtkins__: that's the proposal
19:26:19 [tantek]
19:26:21 [tantek]
3 of 3
19:26:41 [tantek]
actually "ISSUE 1" in current draft of spec (URL?)
19:26:53 [tantek]
TabAtkins__: image-set inside itself is an issue
19:26:57 [tantek]
… nesting
19:27:11 [tantek]
… we can either disallow it
19:27:19 [hober]
image-set(image-set(foo 1x, bar 2x) 2x, baz 1x)
19:27:23 [hober]
(and you choose foo)
19:27:26 [tantek]
Tabatkins: but then you have to search arbitrarily deep
19:27:51 [tantek]
fantasai: i suggest disallowing that example
19:27:57 [tantek]
hober: am ok with disallowing
19:28:03 [tantek]
… but still doable
19:28:07 [tantek]
TabAtkins__: am fine with disallowing
19:28:27 [tantek]
molly: when we start looking at syntax of this nature, designers will freak out
19:28:37 [tantek]
… I can see it turning into a horrible problem
19:28:47 [tantek]
florian: someone writes a blog post … gets copy pasted everywhere
19:28:58 [tantek]
Molly: i'm concerned with the syntax
19:29:25 [tantek]
… I just want to advocate always keeping syntax in CSS as human as possible
19:29:33 [tantek]
… the nesting starts to look confusing
19:29:44 [tantek]
TabAtkins__: agreed in general, nesting functions is usually confusing
19:29:52 [tantek]
19:48:12 [drublic]
drublic has joined #css
19:51:04 [Koji]
Koji has joined #css
19:56:34 [vhardy_]
vhardy_ has joined #css
19:58:39 [mmielke]
mmielke has joined #css
19:59:39 [drublic]
drublic has joined #css
20:06:21 [drublic]
drublic has joined #css
20:27:46 [pcupp]
pcupp has joined #css
20:27:51 [myakura]
myakura has joined #css
20:30:09 [vhardy_]
vhardy_ has joined #css
20:33:33 [vhardy_]
vhardy_ has joined #css
20:36:10 [ksweeney1]
ksweeney1 has joined #css
20:36:32 [ksweeney1]
ksweeney1 has left #css
20:41:26 [fantasai]
pcupp: still gathering people from the lunch break afaict
20:41:34 [fantasai]
pcupp: will let you know once we restart
20:41:54 [krit]
krit has joined #css
20:46:03 [pcupp]
fantasai: could you send us the phone number to join the discussion?
20:46:36 [TabAtkins_]
TabAtkins_ has joined #css
20:48:22 [tantek]
pcupp - do you have skype?
20:48:45 [sylvaing]
pcupp, yes we'll use Skype
20:48:57 [sylvaing]
(it's a Microsoft product now - allegedly)
20:49:54 [fantasai]
ScribeNick: fantasai
20:49:54 [tantek]
scribenick fantasai
20:50:38 [fantasai]
fantasai: Should do Grid Layout, b/c pcupp is waiting
20:51:31 [TabAtkins__]
TabAtkins__ has joined #css
20:51:59 [fantasai]
sylvaing is setting up Skype
20:52:29 [sylvaing]
pcupp, call w3c-csswg
20:52:31 [fantasai]
discussing element() while waiting for technical stuff
20:52:50 [tantek]
still in css4-images
20:52:55 [tantek]
section 4.4
20:53:02 [fantasai]
Tab: Right now syntax is limited to ID selector
20:53:32 [fantasai]
Tab: Bit limiting -- means you have to attach an ID to the element
20:53:40 [fantasai]
Tab: Some thoughts on how to extend this
20:54:04 [fantasai]
Tab: firstly, arbitrary selectors. Represent first such element in the document
20:54:15 [fantasai]
dbaron: Seems potentially expensive
20:54:25 [dbaron]
for dynamic updates
20:54:59 [fantasai]
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 [pcupp]
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 [fantasai]
Tab: ok, I'm ok with that
20:55:35 [fantasai]
Tab: Secondary one, should be able to point to SVG paint servers
20:55:36 [sylvaing]
pcupp, no no phone. and skype sound will be way better (yes, really)
20:56:00 [fantasai]
Tab: Problem is you have to literally embed SVG into the HTML
20:56:06 [glazou]
at next ftf, we will discuss speedos instead of pseudos
20:56:11 [fantasai]
Tab: If you want to use across style shets, have to duplicate the SVG in every document
20:56:19 [fantasai]
Tab: would be nice to point at an externa SVG document
20:56:36 [fantasai]
dbaron: Does that do anything that an SVG rect with fill property wouldn't do?
20:56:40 [florian]
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]
Molly has joined #css
20:57:42 [fantasai]
Tab: I guess not..
20:57:54 [fantasai]
fantaai: Would that work for all fills, including patterns etc.
20:57:59 [fantasai]
dbaron: Think so
20:58:27 [fantasai]
fantasai: So why do we want to point to paint servers if we can just point to SVG?
20:59:05 [fantasai]
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 [fantasai]
dbaron: Not sure it adds any complexity to what we're doing in any case
20:59:48 [fantasai]
Tab: How do we point to something not in the document?
20:59:58 [fantasai]
Tab: Use case of creating a canvas element in script, using it in various other places
21:00:08 [fantasai]
Tab: Right now have to put the canvas in the document with display: none
21:00:12 [fantasai]
Tab: Ideally can use it via script
21:00:19 [fantasai]
Tab: Mozilla can do that currently, not sure it's ideal
21:00:33 [fantasai]
Tab: It aliases an ID to point to a particular image element (which may or may not be in a document)
21:00:51 [fantasai]
Tab: In a previous draft I had this take either ident or ID selector
21:00:57 [fantasai]
Tab: But that conflicted with wanting an arbitrary selector
21:01:09 [fantasai]
Tab: If we don't end up wanting arbitrary selectors...
21:01:22 [fantasai]
Florian: Haven't found another way to select arbitrary pages etc.
21:01:28 [fantasai]
Tab: If we don't need URLs, we can just use the string for that
21:01:43 [fantasai]
dbaron: could also just have two function names
21:01:53 [fantasai]
Tab: Seems a little bit messy, but not opposed
21:02:36 [fantasai]
fantasai: Also have element() name conflict with gcpm
21:02:38 [fantasai]
as an issue
21:02:50 [fantasai]
Tab: issue on how to make an element not in the document to be available
21:02:54 [fantasai]
Tab: FF does a name-mapping
21:03:04 [fantasai]
Tab: Another option is to just have a map, hanging off of the document
21:03:15 [fantasai]
Tab: document.CSSElementMap() to make a map
21:03:29 [fantasai]
Tab: don't know if any real benefit to one or another
21:04:09 [smfr]
webkit already has a kind of map for -webkit-canvas
21:04:13 [fantasai]
side discussion on selector matching of multiple elements with same ID
21:04:17 [smfr]
document.getCanvasContext() or something
21:04:50 [fantasai]
fantasai: one of the main use cases for this originally was reflections. How does this solve reflections?
21:05:20 [fantasai]
Tab: You would give the element an ID, and then create a rule for that element
21:05:40 [fantasai]
fantasai: But I can't say "I want these 5 icons to do reflections"
21:05:47 [fantasai]
Tab: Yeah, you'd have to handle each one individually
21:06:00 [fantasai]
dbaron: There've been lots of interesting demos of this functionality, but don't remember how reflections were handled
21:06:40 [smfr]
maybe you need a special selector for "the element the style is applied to"
21:06:54 [fantasai]
Wouldn't that be :scope?
21:07:00 [fantasai]
or :context, whatever it's called
21:07:06 [fantasai]
glazou: The idea is to use an IDREF
21:07:55 [fantasai]
glazou: selector:after { content: element(attr(id)); } or somesuch
21:08:31 [fantasai]
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 [smfr]
sucks to have to add IDs to everything that needs to be reflected
21:08:48 [fantasai]
Molly: The more it looks like programming, the harder it is for visual designers to follow
21:09:24 [fantasai]
fantasai: I think we need to start threads on www-style for all of these
21:09:42 [fantasai]
Tab: It appears from mailing list conversation that element is rendered as a stacking context
21:09:53 [fantasai]
fantasai: real or pseudo?
21:09:55 [fantasai]
Tab: real
21:10:28 [fantasai]
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 [fantasai]
Tab: Need ppl working on rendering engines to comment
21:10:45 [fantasai]
Tab: people like smfr
21:10:49 [sylvaing]
smfr, skype w3c-csswg?
21:11:07 [fantasai]
ACTION: TabAtkins start threads for each issue and track them all
21:11:07 [trackbot]
Sorry, couldn't find user - TabAtkins
21:11:08 [smfr]
don't have skype set up
21:11:14 [pcupp]
21:11:36 [fantasai]
Topic: Grid Layout
21:12:58 [smfr]
oh, right, ick, you'd have to avoid infinite reflections…..
21:13:17 [fantasai]
Tab requests fpwd of css4-images
21:13:31 [fantasai]
szilles: Having a trouble figuring out FPWD criteria here
21:14:04 [fantasai]
szilles: We're not terribly consistent about that.
21:14:30 [krit]
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]
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 [krit]
Therefore element() should support any IRI like SVG does with fill and stroke already
21:15:20 [fantasai]
szilles: So it has sufficient content that the scope is reasonably clear
21:15:36 [fantasai]
Florian: And the draft is understandable to people outside the WG
21:16:20 [fantasai]
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 [fantasai]
jdaggett: I would add 4. It's enough of a priority that we should be doing it now.
21:16:51 [fantasai]
jdaggett: Think we should be waiting on things that are lower priority.
21:17:39 [dbaron]
(To be clear, this is a discussion about our general requirements for FPWD.)
21:18:02 [fantasai]
RESOLVED: Publish css4-images FPWD
21:18:13 [fantasai]
RESOLVED: Principles 1-3 for publishing FWPD. No consensus on 4.
21:19:20 [fantasai]
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_]
arronei_ has joined #css
21:19:57 [fantasai]
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]
dbaron (before Bert): People criticize us for not getting things done; yet we spend time on whatever anyone brings up.
21:20:33 [fantasai]
plinss: If you feel that group is not managing priorities well, that's a separate discussion.
21:21:02 [fantasai]
Topic: Grid Layout
21:21:50 [fantasai]
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 [pcupp]
can you hear us?
21:22:16 [fantasai]
pcupp: If everyon e looking at wiki link
21:22:25 [fantasai]
pcupp: First topic is [dropped connection]
21:22:47 [fantasai]
pcupp: In hamburg we didn't really talk about why dropping named lines
21:22:55 [fantasai]
pcupp: just said general consensus among editors
21:23:01 [fantasai]
pcupp: Wrote out rationale here
21:23:22 [fantasai]
plinss: Named lines are powerful and useful
21:23:26 [fantasai]
plinss: would object to dropping them
21:24:12 [fantasai]
plinss: Think named lines are very important to grids
21:24:16 [dbaron]
.... . .-.. .-.. ---
21:24:27 [fantasai]
plinss: look at historical usage, have classes of lines, types of lines, naming them is quite important
21:24:38 [fantasai]
plinss: if you want layouts that can adapt quickly without redefining everything from scratch
21:24:49 [fantasai]
plinss: with named lines can just move the lines around and everything just works
21:24:53 [fantasai]
fantasai: We have that with templates.
21:25:08 [fantasai]
Molly: Has everyone read Mark Boulton's blog post on grid issues?
21:25:13 [fantasai]
several: yes
21:25:23 [fantasai]
Molly: Would like to keep language similar to what language designers use
21:25:34 [fantasai]
Molly: discuss takeaways
21:25:34 [Koji]
Koji has joined #css
21:25:40 [fantasai]
pcupp: Two comments
21:26:06 [fantasai]
pcupp: Wrt plinss, agree with fantasai that points made about named lines aliasing capabilities are handled by template
21:26:17 [Molly]
URL for article:
21:26:23 [fantasai]
pcupp: Template syntax is preferred by editors, including Bert and fantasai
21:26:41 [fantasai]
pcupp: 2nd point from Mark Boulton's post, Bert has a good response to that
21:26:54 [fantasai]
pcupp: In his model, grid sizes are fixed, and content adapts on top of that
21:27:05 [fantasai]
pcupp: But in our grid, the rows and columns can adapt to their contents
21:27:27 [fantasai]
pcupp: Similar to tables, but with more predictable sizing and better placement capabilities
21:27:43 [fantasai]
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 [fantasai]
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 [fantasai]
pcupp: Grid that we have addresses more scenarios and I think the template syntax is sufficient aliasing mechanism for that grid
21:28:25 [fantasai]
Molly: I was just concerned with the nomenclature
21:28:34 [fantasai]
Molly: more we have of that, better it is for authors
21:28:42 [fantasai]
pcupp: Wrt nomenclature, we have a bugzilla issue on that
21:28:55 [fantasai]
pcupp: e.g. we have column-gap and column-rule for gutters
21:29:00 [fantasai]
pcupp: There would be a discrepency there
21:29:13 [fantasai]
pcupp: Is it more important to call them gutters, or snap to what's already used in multi-column?
21:30:05 [fantasai]
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]
fantasai: was to change "grid area" to "grid field"
21:30:33 [fantasai]
szilles: There are a number of variable-size designs in print design as well, printing onto different pages/cards/etc.
21:30:51 [fantasai]
plinss: There's a long history of grids in print publishing, don't think we should lose that.
21:31:01 [fantasai]
pcupp: I'm not proposing that there isn't such a thing as a grid line
21:31:08 [fantasai]
pcupp: I'm saying that we don't need to give those things names
21:31:18 [fantasai]
pcupp: Because as an aliasing syntax, I think it's poorer than the template syntax
21:31:28 [fantasai]
plinss: You currently specify that you can only have one name existing once
21:31:38 [fantasai]
plinss: Think we should be able to reuse same name over and over across the grid
21:31:58 [fantasai]
plinss: e.g. class lines into "left line" and "right line", and have multiple of these
21:32:09 [fantasai]
plinss: If something gets bumped out of the way, snaps to next line of same class
21:32:15 [fantasai]
plinss: Especially vertically, that's done quite commonly
21:32:26 [fantasai]
plinss: Can avoid collisions and have things snap to lines
21:32:34 [fantasai]
plinss: e.g. snap headlines to a headline line
21:32:39 [fantasai]
plinss: you can't do that without giving an identifier
21:32:53 [fantasai]
jdaggett: Are you saying that you want that feature specced out in this module?
21:32:58 [pcupp]
we just dropped
21:33:00 [fantasai]
plinss: I want that capability in this spec
21:33:02 [pcupp]
hang on
21:33:05 [pcupp]
21:33:59 [fantasai]
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]
fantasai: named lines as they are right now aren't about a snap-to-grid modle
21:34:21 [fantasai]
fantasai: The current model is about positioning into specific slots into the grid
21:34:30 [fantasai]
fantasai: and named lines are a really awkward way to do that.
21:34:44 [fantasai]
pcupp: ...
21:34:53 [fantasai]
pcupp: Not clear why current grid would preclude a snapping feature
21:35:54 [fantasai]
fantasai: I agree we should have snap-to-grid, but that's not what this module is about
21:36:12 [fantasai]
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 [fantasai]
plinss: I don't what to have two different kinds of grids
21:36:33 [fantasai]
plinss: My proposal is that this grid system do what grids historically have done
21:36:38 [fantasai]
plinss: and think named lines is an important feature
21:36:51 [fantasai]
plinss: think snapping-to-grid feature should be an easy extension of this grid
21:37:04 [fantasai]
Bert: There are different traditions
21:37:12 [fantasai]
Bert: I've seen grids, but not named lines
21:37:48 [fantasai]
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 [fantasai]
plinss: They're not named because the designer is laying things out manually
21:38:18 [pcupp]
we dropped again
21:38:23 [fantasai]
Tab: How is this different from template positioning?
21:38:26 [fantasai]
plinss: Can't have repetition
21:38:39 [fantasai]
plinss: say I have text flow through multiple boxes
21:38:57 [fantasai]
plinss: want image to snap to nearest available image line, which is different than text-snapping lines
21:38:57 [pcupp]
21:39:10 [fantasai]
plinss: This is how grids have historically been used
21:39:21 [fantasai]
szilles: Peter's model doesn't have cells, it has lines.
21:39:26 [fantasai]
plinss: I want a model that doesn't have cells.
21:39:47 [fantasai]
pcupp: Can you have lines that are positioned by content in your model?
21:39:57 [fantasai]
plinss: Historically they have not been used that way.
21:40:09 [fantasai]
plinss: But could.
21:40:16 [fantasai]
plinss: Algorithm is complex, but not that complex.
21:40:25 [fantasai]
pcupp: In algorithm right now, size influences other elements
21:40:42 [fantasai]
pcupp: When you introduce snapping-to-grid feature, then depending on where the item is position it may span more lines
21:40:49 [fantasai]
pcupp: but the lines depend on the sizes of contents inside
21:40:52 [fantasai]
pcupp: so get a cycle
21:41:01 [fantasai]
pcupp: If you have a fixed grid, can have content stretch over it
21:41:08 [fantasai]
pcupp: But doesn't create relationships among contents
21:41:24 [fantasai]
pcupp: e.g. item in here is as wide as all other items in the column
21:41:32 [fantasai]
pcupp: Right now grid track sizes can be driven by content
21:41:45 [fantasai]
pcupp: So grid flexes to fit the content, rather than items flexing to fit the grid
21:41:50 [fantasai]
pcupp: I don't think you can combine these two models.
21:41:59 [fantasai]
plinss: I don't have a mathematical proof of the opposite either
21:42:25 [fantasai]
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 [fantasai]
szilles: no, they're not cells
21:42:37 [fantasai]
szilles: ... offest it to the next line
21:42:46 [fantasai]
szilles: Straight line in sequence of cells
21:42:54 [fantasai]
plinss: Have cells that are overlapping
21:43:04 [fantasai]
plinss: Because going to arbitrary lines for different things
21:43:14 [pcupp]
dropped again
21:43:17 [Zakim]
Zakim has left #css
21:43:19 [pcupp]
21:44:07 [fantasai]
fantasai: So... afaict nobody wants the named lines as they are in the spec now.
21:44:13 [fantasai]
fantasai: We have a desire for a snap-to-grid model.
21:44:17 [fantasai]
plinss: disagree with that
21:44:25 [fantasai]
plinss: I like the named lines as they are in the spec.
21:44:30 [fantasai]
fantasai and Tab think they're horrible
21:44:46 [fantasai]
pcupp: Let's walk thorugh current named lines
21:45:22 [stearns]
link again, in case anyone needs it:
21:49:48 [fantasai]
pcupp: First thing that's a little unnatural is template syntax using idents
21:49:57 [fantasai]
pcupp: whereas named lines use strings
21:50:05 [fantasai]
pcupp: This is due to syntactic collisions
21:50:08 [fantasai]
szilles: asks about collisions
21:50:08 [fantasai]
fantasai explains there are two points of collision for named lines:
21:50:08 [fantasai]
with template slots, and within the grid track syntax with size keywords
21:50:08 [fantasai]
pcupp: named lines is 4x as long as the alternative syntax we proposed,
21:50:08 [fantasai]
pcupp: because you need 4 lines, but only one area
21:50:15 [pcupp]
does anyone have a cell phone that we could call?
21:50:21 [plinss]
zakim, room for 3?
21:50:48 [pcupp]
we dropped again
21:51:09 [Zakim]
Zakim has joined #css
21:51:09 [fantasai]
we're attempting to get you back online somehow :)
21:51:16 [plinss]
zakim, room for 3?
21:51:18 [Zakim]
ok, plinss; conference Team_(css)21:51Z scheduled with code 26632 (CONF2) for 60 minutes until 2251Z
21:52:28 [Zakim]
Team_(css)21:51Z has now started
21:52:34 [Zakim]
21:52:48 [fantasai]
pcupp: is that problem clear?
21:54:04 [fantasai]
szilles: I just want to move the lines
21:54:24 [fantasai]
plinss: I'm going to move all the lines, and keep things stuck to the lines
21:54:41 [fantasai]
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 [fantasai]
d slot
21:54:57 [fantasai]
szilles: You're focused on creating cells, that's not what plinss is asking for
21:55:05 [fantasai]
pcupp: I just want to put an item into the grid
21:55:31 [fantasai]
discussion of whether overlap is desired
21:55:45 [fantasai]
szilles: You want your figures to bleed into the gutters, but not the text
21:55:52 [fantasai]
pcupp: The grid definitely allows overlapping
21:56:01 [fantasai]
pcupp: The template syntax doesn't allowed named areas to overlap one another
21:56:09 [fantasai]
plinss: You lose that by losing named lines
21:56:18 [fantasai]
pcupp: Seems pretty specialized
21:56:20 [fantasai]
use case
21:56:26 [fantasai]
Bert: I've never seen that
21:56:34 [fantasai]
plinss: I'm talking about boxes wrapping around each other
21:56:37 [fantasai]
Bert: yes, exclusions
21:56:44 [fantasai]
Bert: They don't overlap, they wrap around
21:56:51 [fantasai]
Molly: Wouldn't that be deconstructing the grid?
21:57:12 [fantasai]
Molly: Maybe this is part of the problem. They're thinking about cells too.
21:57:22 [fantasai]
Molly: It's part also of the table legacy
21:57:36 [fantasai]
szilles shows a picture of a grid layout
21:58:00 [fantasai]
one tall box along the left side, intersecting a long horizontal box in the bottom third of the page
21:58:16 [fantasai]
Bert: That's not named lines. That's a specific layout for a particular poster.
21:58:25 [fantasai]
Bert: You're not aligning images to one line and text to another
21:58:37 [fantasai]
Bert: You can do that with the grid, too, but not necessarily the default.
21:58:55 [fantasai]
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 [fantasai]
plinss: You get the other cases by naming the lines, and thinking of it in terms of lines rather than cells.
21:59:14 [fantasai]
plinss: It's an entirely different mental model.
21:59:42 [fantasai]
plinss: We have a whole bunch of different layout systems that use boxes
21:59:48 [fantasai]
plinss: flexbox, tables, floats
21:59:56 [fantasai]
fantasai: But none of those do 2D alignment. Grid does
22:00:00 [fantasai]
plinss: 2D flexbox
22:00:05 [fantasai]
fantasai: That's what Grid Layout is.
22:00:46 [fantasai]
plinss: Haven't we all used vector drawing program?
22:00:58 [fantasai]
plinss: First thing you do is drag out guide lines, and start laying things out to those lines.
22:01:08 [fantasai]
Tab: Alternative is that main thing grid layout tries to do
22:01:19 [fantasai]
Tab: is take the table-based layout concepts and make them not shitty
22:01:23 [fantasai]
Tab: These are two different use cases
22:01:33 [fantasai]
Tab: You can't just say "put named lines into grid"
22:02:05 [fantasai]
Tab: question is whether named lines should be in this grid module
22:02:11 [fantasai]
Tab: The way they are defined now, no.
22:02:50 [fantasai]
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 [fantasai]
Tab: named lines doesn't if it
22:03:02 [fantasai]
s/if it/fit in/
22:03:14 [fantasai]
Tab: we should go and see if we can add a snap-to-grid model
22:03:48 [fantasai]
Tab: Make grid layout work nicely with snap-to-grid
22:04:08 [fantasai]
Florian: Do we need to rename what is currently called grid to something else?
22:04:13 [fantasai]
sylvaing: No, we do that at Last Call.
22:04:18 [krit]
krit has joined #css
22:04:30 [fantasai]
jdaggett: The spec right now is called Grid Layout, we had another one called Grid.
22:04:40 [fantasai]
jdaggett: That was more of a graphic designers view of grid layout
22:05:20 [fantasai]
fantasai: That model was abspos with grid coordinates, had all the collision problems of abspos, didn't have snap-to-grid
22:05:50 [fantasai]
plinss: You need exclusions and you need collison model.
22:05:57 [fantasai]
pcupp: So, where are we now?
22:06:20 [fantasai]
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 [fantasai]
szilles: Certainly common overlap between the two
22:06:37 [fantasai]
szilles: Haven't established whether it's impossible to do them all in the same model
22:06:50 [fantasai]
plinss: I think we can do this in one model
22:07:09 [fantasai]
jdaggett: We need a concrete action item on someone to write up the functionality that you think is required.
22:07:18 [fantasai]
jdaggett: Having this discussion over again is counter-productive.
22:07:21 [fantasai]
pcupp: Agre
22:07:22 [fantasai]
22:07:34 [fantasai]
jdaggett: I'm not objecting to what you're proposing, but we need a proposal that's in more concrete form
22:08:30 [fantasai]
sylvaing: Can we pull what's in the spec out?
22:08:38 [fantasai]
sylvaing: and put an issue to design something new?
22:08:58 [fantasai]
plinss: Been asking for grid people to understand the model I want
22:09:07 [fantasai]
plinss: If we pull the named lines then it'll go the wrong way
22:09:19 [fantasai]
Tab: I don't think you want to patch what you want onto the current named lines
22:09:30 [fantasai]
plinss: I think what we want is going to be different than what we have
22:09:35 [fantasai]
plinss: Otherwise we'll fork the spec
22:09:59 [fantasai]
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 [fantasai]
Tab: Nobody's helped by the thing that's in the spe cright now.
22:10:30 [fantasai]
szilles: as long as I can only define cells between adjacent lines
22:10:48 [fantasai]
szilles: If I can define cells that can span lines, then I can get what I want
22:10:54 [fantasai]
several: You can already do that.
22:11:38 [fantasai]
pcupp: wrt maintainability, it's easier to renumber than to come up with four names per box
22:12:12 [fantasai]
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 [Molly]
22:12:36 [fantasai]
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 [fantasai]
Tab explains how grid template slot names can be used as coordinates
22:14:10 [fantasai]
plinss: If we want to add what plinss wants, it's something completely different from this
22:14:41 [fantasai]
Molly: The problem here is a lot bigger than maybe we even imagine
22:14:54 [fantasai]
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 [fantasai]
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 [Bert]
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 [fantasai]
Tab: So you're saying we shoudl rename the spec
22:17:03 [fantasai]
sylvaing: The grid model here is familiar to anyone who understand tables. Don't understand why that's bad
22:17:08 [fantasai]
jdaggett: model is not as familiar as you think
22:17:26 [fantasai]
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 [fantasai]
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 [fantasai]
sylvaing: Different designers are comfortable with different models
22:18:46 [fantasai]
sylvaing: We need both
22:19:02 [fantasai]
plinss: I believe we can have a unified grid model.
22:19:19 [fantasai]
plinss: That has the functionality page designers want, but allows you to address things the way the spec defines it.
22:19:31 [fantasai]
plinss: I want this unified grid model. I don't want Yet Another layout system
22:19:34 [fantasai]
Florian: How to get there?
22:19:55 [fantasai]
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 [fantasai]
plinss: If we yank it now, we've gone down the path of the application grid
22:20:26 [fantasai]
Florian: Maybe the solution you want will replace what's there, maybe add to it
22:20:40 [fantasai]
jdaggett: Let's mark the spec with a big red issue, mark it as under discussion
22:21:31 [fantasai]
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 [fantasai]
Tab: I would not tell our implementers to implement grid lines as they are in the spec
22:22:11 [fantasai]
Tab: Leaving it in leave the spec in a weird state that we have something we *know* we don't want
22:22:42 [fantasai]
jdaggett: I think Tab's arguing that we shouldn't put things in our specs that we know are complete rubbish.
22:23:42 [fantasai]
Tab: I doubt the correct solution is an evolution of the current spec
22:24:27 [fantasai]
Florian^: Should leave work in progress in the spec so people can build on it
22:24:52 [fantasai]
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 [fantasai]
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 [fantasai]
jdaggett: Can we wrap this up with an action item?
22:26:20 [fantasai]
jdaggett: I'd like an action on Peter and Steve to come up with a concrete proposal.
22:27:02 [fantasai]
ACTION szilles and plinss to describe a line-based layout grid unified model of everything
22:27:02 [trackbot]
Sorry, couldn't find user - szilles
22:27:12 [fantasai]
ACTION pcupp Add note Florian proposes to the spec
22:27:13 [trackbot]
Created ACTION-500 - Add note Florian proposes to the spec [on Phil Cupp - due 2012-08-21].
22:27:45 [stearns]
pcupp: we tried to bring this into the model and failed. we need you to show us the way
22:28:13 [fantasai]
ACTION plinss draft note Florian proposes and send it to pcupp
22:28:14 [trackbot]
Created ACTION-501 - Draft note Florian proposes and send it to pcupp [on Peter Linss - due 2012-08-21].
22:28:28 [myakura]
myakura has joined #css
22:56:00 [Zakim]
disconnecting the lone participant, glazou, in Team_(css)21:51Z
22:56:02 [Zakim]
Team_(css)21:51Z has ended
22:56:02 [Zakim]
Attendees were glazou
22:57:12 [myakura]
myakura has joined #css
22:57:16 [drublic]
drublic has joined #css
23:00:03 [fantasai]
pcupp: Next item...
23:00:15 [fantasai]
pcupp: I have another thing describing anonymous grid items and how we create them
23:00:21 [fantasai]
pcupp: There are some images there that help show this
23:00:31 [fantasai]
pcupp: Current behavior in spec mirrors Flexbox behavior
23:00:45 [fantasai]
pcupp: All children of grid are grid items, loose text is wrapped in anon grid item
23:01:07 [fantasai]
pcupp: A complaint is that these items all stack on top of each other in the first cel
23:01:17 [fantasai]
pcupp: If you turn on auto-flow, you'll get separate grid items that flow into boxes
23:01:28 [fantasai]
pcupp: What we recently discussed on a last telecon, talked about what if we did something different
23:01:38 [fantasai]
pcupp: What if we wrapped all the contents of grid element into one anonymous grid item
23:01:51 [fantasai]
pcupp: and pulled actual grid items out of the flow of the anon one and positioned them
23:02:10 [fantasai]
pcupp: Default grid item could be auto-positioned, or put in 1-1
23:02:16 [fantasai]
pcupp: and so you get third image
23:02:32 [fantasai]
pcupp: Introduced one more idea, what if you use this ocncept of everything in anon item
23:02:46 [fantasai]
pcupp: and allow descendants with grid-pos properties to be pulled out of the flow, not just direct children
23:02:55 [fantasai]
pcupp: fantasai pointed out a point recently, wrt markup
23:03:00 [fantasai]
pcupp: e.g. form elements inside list items
23:03:09 [fantasai]
pcupp: say you wanted labels in 1st column, inputs in 2nd column
23:03:22 [fantasai]
pcupp: what do we do with this remaining markup? does it collapse down to nothing?
23:03:33 [fantasai]
pcupp: With descendants pulled into grid, have this issue
23:03:45 [fantasai]
pcupp: Then the conversation on www-style, fantasai proposed we could deal with this by a new 'display: subgrid'
23:03:57 [fantasai]
pcupp: Then some discussion of pursuing subgrid, or deferring it
23:04:19 [fantasai]
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 [fantasai]
23:04:54 [fantasai]
Tab: I support wrap everything in anonymous grid cell and pull things out
23:05:11 [fantasai]
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 [fantasai]
Tab: goes into anon grid cell
23:05:24 [fantasai]
pcupp: How do we keep it from displaying
23:05:42 [fantasai]
Tab: make anon cell display: none by default
23:05:47 [fantasai]
fantasai: We try not to have things disappear by default
23:06:01 [fantasai]
fantasai: try to have things show up by default
23:06:05 [dbaron]
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 [fantasai]
Tab: Template had default slot concept
23:06:23 [fantasai]
Tab: Could even have that be the default template
23:06:57 [dbaron]
fantasai: Pulling things out into the ancestor and having grid stuff all float together seems like a good idea.
23:07:08 [Molly]
Molly has joined #css
23:07:23 [fantasai]
fantasai: we have a grid-auto-flow property that would let us switch into auto placement
23:07:49 [dbaron]
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 [dbaron]
fantasai: You want several layers of descendants to participatein the same grid and align together.
23:08:16 [dbaron]
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 [dbaron]
fantasai: So my concern with deferring it
23:08:42 [dbaron]
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 [dbaron]
fantasai: ... but I'm concerned that we can't.
23:09:01 [dbaron]
fantasai: Bert brought up -- mail on www-style
23:09:37 [dbaron]
fantasai: <fieldset> <ul> <li> <label> <input> </li> <li> <label> <input> </li> </ul>
23:09:46 [dbaron]
fantasai: you might want to have label and input and put borders around it
23:09:52 [dbaron]
fantasai: [draws]
23:10:06 [dbaron]
fantasai: want to align the labels and the inputs
23:10:22 [dbaron]
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 [dbaron]
fantasai: so this seems like a sensible common use case for ui grids -- to style intermediary list-item
23:10:50 [dbaron]
Peter: When you use the term sub-grid, you mean children or descendant elements, not grids within grids?
23:11:10 [dbaron]
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 [dbaron]
fantasai: but coordinates are scoped and margins and padding are subtracted out
23:11:29 [dbaron]
Steve: Is it a way of changing what the items are?
23:11:36 [dbaron]
fantasai: I should pull up my email...
23:11:50 [dbaron]
Phil: IN fantasai's proposal, she's saying the grid lines are permeating the descendants with display:subgrid
23:11:58 [fantasai]
23:12:08 [dbaron]
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 [dbaron]
Phil: ??? to account for margin / border / padding on ancestor elements by pretending they have larger margin
23:12:32 [dbaron]
Phil: Has great potential, I like the ... .
23:12:52 [dbaron]
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 [dbaron]
23:13:12 [dbaron]
Phil: I don't know why we couldn't add this in a later level of grid.
23:13:21 [dbaron]
Phil: And people need to be able to author markup with subgrid in mind today.
23:13:39 [dbaron]
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 [dbaron]
Tab: Example markup in wiki: this kind of thing is very reasonable.
23:14:00 [dbaron]
Tab: The correct way to mark up html that puts the signifcant parts as not children of the grid
23:14:12 [dbaron]
Phil: But in this example I created it to illustrate a problem that exists due to markup structure.
23:14:22 [dbaron]
Phil: But I could have collected labels annd inputs as children of grid.
23:14:36 [dbaron]
Peter: What you would have lost is how these things behave on a client that doesn't support grids
23:14:40 [dbaron]
Tab: or a client without CSS at all?
23:14:52 [dbaron]
Florian: You write the markup because it's the correct way to mark it up, then style it.
23:15:10 [dbaron]
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 [dbaron]
Tab: Having to flatten all children seems like too much.
23:15:35 [dbaron]
Tab: Case of figure -- pulling out img and figcaption -- can't do that without losing markup connection from <figure>.
23:16:07 [dbaron]
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 [dbaron]
fantasai: This isn't an issue about creating pseudo-elements, since it's something that the markup has or should have.
23:16:42 [dbaron]
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 [dbaron]
fantasai: But you need to put margins on 3 sides of both things... could get hairy with arbitrary children.
23:17:05 [dbaron]
Tab: Subgrids good for this kind of case
23:17:36 [dbaron]
fantasai: Subgrids work: if I want to position item into a grid... look at children and see how many cells spanning ...
23:17:42 [dbaron]
fantasai: [draws]
23:17:56 [dbaron]
fantasai: take up this many slots in the parent grid
23:18:15 [dbaron]
fantasai: From children's perspective, this is the numbering system, but for parent and numbering system *this* is the positioning system.
23:18:37 [dbaron]
fantasai: children affect sizing of parent grid, except extra margin added to items to account for subgrid's margin/border/padding
23:18:46 [dbaron]
fantasai: That's the idea, and it would solve this problem.
23:18:55 [dbaron]
Bert: I don't understand how it solves this problem.
23:19:12 [dbaron]
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 [dbaron]
fantasai: the items in the subgrid participate in the parent grid, so [points at drawing]
23:20:00 [dbaron]
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 [dbaron]
fantasai: The children would then need to know the grid position of its parent
23:20:19 [dbaron]
Peter: So its grid coordinate system is relative to its parent
23:20:26 [dbaron]
Steve: consttraining th erange of auto fill
23:20:40 [dbaron]
Steve: In some sense you're making grid items out of the children, but there's more to it than that.
23:21:11 [dbaron]
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 [dbaron]
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 [dbaron]
Steve: I'm unclear how the border gets done
23:22:09 [dbaron]
fantasai: you just put a border on the li -- it's there
23:22:11 [dbaron]
Steve: ah, ok
23:22:24 [dbaron]
Phil: So if everybody understands that -- back to the original question
23:22:32 [dbaron]
Phil: So Tab wants to see it in level 1.
23:22:43 [dbaron]
Phil: The more we try to solve in level 1 the further it is from being stable
23:22:55 [dbaron]
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 [dbaron]
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 [dbaron]
Tab: ... there are required or recommended markup patterns in HTML that prevent you from flattening children
23:23:46 [dbaron]
Phil: [missed]
23:24:01 [dbaron]
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 [dbaron]
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 [dbaron]
fantasai: I'm not sure I'm comfortable with that
23:25:42 [dbaron]
Phil: I'm not sure what that solution is; could take an action item
23:25:49 [dbaron]
Phil: I'd prefer not to tie that to level 1 at all.
23:26:08 [dbaron]
fantasai: Not sure if I full-on object to that, but afraid people will do bad things to their markup.
23:26:19 [dbaron]
Tab: subgrid or descendants being pulled in?
23:26:29 [dbaron]
fantasai: pulling good; concern is about subgrid
23:26:47 [dbaron]
fantasai: Concern about people doing weird things to their markup to make alignment happen, impact a11y etc, bad markup practices.
23:27:05 [dbaron]
Phil: To be clear, I was talking about pulling descendants as a whole.
23:27:29 [dbaron]
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 [dbaron]
fantasai: Could create a positioned-grid value required to pull descendants and turn it on that way
23:27:53 [dbaron]
tab: I'm concerned about contortion of markup patterns
23:28:18 [dbaron]
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 [dbaron]
fantasai: I think they both will
23:28:31 [dbaron]
Phil: What about flexbox?
23:28:41 [dbaron]
fantasai: We didn't have use cases for pulling descendants into the main flexbox
23:28:46 [dbaron]
23:29:04 [dbaron]
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 [dbaron]
fantasai: because of the laignment across both dimensions
23:29:13 [dbaron]
23:29:31 [dbaron]
Phil: ok, so we're resolved to continue pursuing descendant solution, but not requiring subgrids as part of that solution?
23:29:34 [dbaron]
Tab: That's what I want?
23:29:39 [dbaron]
fantasai: I want to hear from other people
23:29:41 [dbaron]
23:29:42 [myakura]
myakura has joined #css
23:29:56 [dbaron]
Steve: Weak approx to subgrid called honor-descendants
23:30:13 [dbaron]
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 [dbaron]
Tab: That solves problem of stray grid positioning
23:30:34 [dbaron]
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 [dbaron]
Steve: I thought I'm turning it on so I didn't have to flatten.
23:30:45 [dbaron]
Steve: Treat my children as being me.
23:30:50 [dbaron]
Tab: So you're saying do that right now?
23:31:00 [dbaron]
Steve: I'm saying to do that right now is a way of doing the descendants thing.
23:31:22 [dbaron]
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 [dbaron]
Bert: why need a property at all?
23:31:41 [dbaron]
Florian: We only need it if we introduce it later, and thus it needs to be opt-in
23:31:46 [dbaron]
Bert: but the default should be on
23:31:48 [dbaron]
Tab, Florian: yes
23:31:54 [dbaron]
Steve: But it doesn't interact with subgrids?
23:32:17 [dbaron]
Tab: We can patch this by saying that if a particular descendant wants to escape out -- still future-friendly for subgrid.
23:32:43 [dbaron]
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 [dbaron]
fantasai: Fact that we can't handle that right now without really being hacky
23:33:01 [dbaron]
Bert: As long as you don't want image borders...normal borders you can do.
23:33:09 [dbaron]
Bert: 3 borders on left cell and 3 borders on right cell
23:33:17 [dbaron]
fantasai: label inside there... input has its own borders
23:33:28 [dbaron]
Tab: People could hack it into working just with CSS
23:33:39 [dbaron]
Tab: What are you concerned people will do to their markup to help that.
23:33:42 [dbaron]
23:33:53 [dbaron]
fantasai: Not sure, but I think it would be pretty ugly.
23:34:32 [dbaron]
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 [dbaron]
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 [dbaron]
Bert: I think it will be difficult to design because of subtracting margins.
23:35:05 [dbaron]
fantasai: If you didn't want the space then you wouldn't put any padding there
23:35:24 [dbaron]
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 [dbaron]
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 [fantasai]
23:37:10 [fantasai]
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 [fantasai]
dbaron: And then it will ine up
23:37:21 [fantasai]
dbaron: But if you do put margin/padding/border, we honor them
23:37:41 [dbaron]
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 [dbaron]
Tab: That's the actual functionality of subgrids.
23:38:00 [dbaron]
Steve: If you don't put margins on the li, then it lines up.
23:38:02 [dbaron]
Tab: yes.
23:38:15 [dbaron]
Steve: You have the option of getting more indent.
23:38:49 [dbaron]
fantasai: I think we should resolve on doing descendants going up into grid, mark subgrid as something to think about.
23:39:32 [fantasai]
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 [dbaron]
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 [dbaron]
Tab: Oh, key it to something else like position:grid?
23:40:18 [dbaron]
Phil: I think I like the row-or-column-is-non-auto.
23:40:34 [dbaron]
Phil: Sorry, I think we'd need to introduce new value like none for grid-row or grid-column
23:40:50 [dbaron]
Tab: You want most of your descendants to not do anything special
23:40:53 [dbaron]
fantasai: Initial value would be none.
23:41:22 [dbaron]
Phil: For chlidren of grid, in anonymous default grid item, would need to give them grid-row/column: auto
23:41:43 [dbaron]
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 [dbaron]
Tab: alternative is to make nonen compute to auto for children of grid
23:41:55 [dbaron]
varous: no
23:42:07 [dbaron]
23:42:10 [dbaron]
23:42:28 [fantasai]
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]
fantasai: so we need to think about that
23:43:06 [dbaron]
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 [dbaron]
fantasai: I don't think we want to do that.
23:43:20 [dbaron]
Tab: I just think we may want to allow you to throw away the content.
23:43:33 [dbaron]
Tab: I'd prefer if it didn't make anything disappear until you actually position some children.
23:43:37 [dbaron]
Tab: need to make sure that works properly
23:43:53 [dbaron]
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 [dbaron]
Bert: We might want to have something that throws away everything except things that really want to be displayed.
23:44:14 [dbaron]
Bert: useful for collapsing lists
23:44:24 [dbaron]
fantasai: visibility:collapse but done right?
23:44:46 [dbaron]
Phil: Next issue is the shorthand naming.
23:44:54 [dbaron]
Phil: We added a bunch of new shorthands into latest ED.
23:45:32 [dbaron]
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 [dbaron]
Phil: Some suggestion of grid-row-tracks and grid-column-tracks instead
23:45:46 [dbaron]
Phil: suggestions?
23:46:01 [dbaron]
Tab: I agree with renaming -- grid-row vs. grid-rows was bad.
23:46:07 [dbaron]
Tab: Not super-happy with grid-definition-rows
23:46:31 [dbaron]
Phil: Recommended process for resolving on names?
23:46:42 [Bert]
q+ to suggest grid-columns and grid rows for definitions, grid-area for positioning.
23:46:43 [dbaron]
fantasai: Brainstorm for a bit, straw poll. If nothing good, try again later?
23:46:53 [dbaron]
ack Bert
23:46:53 [Zakim]
Bert, you wanted to suggest grid-columns and grid rows for definitions, grid-area for positioning.
23:47:05 [dbaron]
Bert: grid-columns and grid rows for definitions, grid-area for positioning
23:47:16 [dbaron]
Tab: I think grid-area is shorthand for all 4 at once
23:47:24 [dbaron]
Bert: Could say there are no individual property and just use shorthand.
23:47:35 [dbaron]
fantasai: I think there are use cases for longhand, esp. with auto positioning.
23:47:45 [dbaron]
Tab: [rapidly-described use case combinatorics]
23:47:53 [dbaron]
Bert: They always have an x and a y position anyway.
23:48:00 [dbaron]
Tab: I think it's useful to do x and y separately.
23:48:04 [fantasai]
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 [dbaron]
Steve: Instead of putting extra word in the definition, put it in the use?
23:48:19 [dbaron]
fantasai: Problem with that is that it's the one you're going to type the most.
23:48:23 [dbaron]
Bert: I think that's not the case.
23:48:32 [dbaron]
Bert: I think you're going to use the positioning less than the definition.
23:48:44 [dbaron]
Bert: Most grids will not be used with positioned elements not elements that are flowing.
23:48:51 [dbaron]
Bert: So you don't need explicit x and y wery often.
23:48:55 [dbaron]
Tab: Don't know about this.
23:49:18 [dbaron]
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 [dbaron]
fantasai: Another position was grid-template-rows/columns/slots for the template.
23:49:50 [dbaron]
Bert: I like shorthand shorter: grid not grid-template.
23:49:59 [dbaron]
Tab: Nice ideas, make sure they get pulled into brainstorming thread.
23:50:08 [dbaron]
Phil: There was a side discussion during break, with tab fantasai peter steve bert.
23:50:25 [dbaron]
Phil: Did you settle on something? Did you decide to remove named lines?
23:50:50 [dbaron]
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 [dbaron]
Steve: Consensus that syntax improvement was needed.
23:51:16 [dbaron]
Tab: One of us should put together beter syntax for name dlines
23:51:45 [dbaron]
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 [dbaron]
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 [dbaron]
Phil: ok, I think I heard those
23:52:31 [dbaron]
Tab: Useful part: can we remove the current syntax because we're going to do better and soon?
23:52:44 [dbaron]
Steve: If we can come up with something in aweek we'd certainly put the new syntax in.
23:52:57 [dbaron]
[Tab still wants the old syntax out, but gives in]
23:53:06 [dbaron]
Phil: I'm just going to wrap up with status:
23:53:15 [dbaron]
Phil: ... updates recently to grid. Template property now taking identifiers.
23:53:28 [dbaron]
Phil: ... automatic placement algorithm updated based on discussion with fantasai -- forward only, no backfilling
23:53:32 [dbaron]
Phil: ... new shorthands just mention
23:53:43 [dbaron]
Phil: ... next steps: editors work on descendant piece, work on gutters
23:53:57 [dbaron]
Phil: ... not sure if this was implied -- we also plan to pull in column/row-rule with column/row-gap
23:54:05 [dbaron]
Phil: ... and issues in bugzilla we'll start working on.
23:55:09 [fantasai]
23:55:20 [fantasai]
Discussion of what to discuss
23:55:29 [fantasai]
jdaggett: We would like to not ship this prefixed.
23:55:37 [fantasai]
Tab: Neither do we
23:55:58 [fantasai]
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 [fantasai]
Florian: Can we decide on what we're talking about first?
23:57:11 [fantasai]
discussion of scheduling constraints
23:58:25 [fantasai]
and how long to discuss prefixes
23:59:14 [fantasai]
Topic: Variables
23:59:19 [fantasai]
Tab: I can do variables in half hour!
00:00:53 [fantasai]
Tab spends half an hour erasing the board.
00:00:55 [fantasai]
00:01:06 [fantasai]
Tab: Question is what features to preserve in the draft and how to call them
00:01:12 [fantasai]
Tab: Right now variables are created witha property
00:01:16 [fantasai]
Tab: Few different ways to handle this
00:01:33 [fantasai]
Tab: Right now they're declared as property declarations.
00:01:38 [fantasai]
Tab: property name options
00:01:39 [fantasai]
00:01:41 [fantasai]
00:01:42 [fantasai]
00:01:44 [fantasai]
00:01:48 [fantasai]
Tab: 3 ways to use a variable
00:01:54 [fantasai]
Tab: prop: $foo
00:02:12 [fantasai]
Tab: prop: var(foo [, fallback])
00:02:18 [fantasai]
Tab: use var function with optional fallback
00:02:29 [fantasai]
Tab: Option to do something when var isn't defined or is invalid, very useful functionality
00:02:34 [fantasai]
Tab: other function is parent-var()
00:02:43 [fantasai]
Tab: which does the same thing, but checks the variable value on your parent
00:02:52 [fantasai]
Tab: Less than 1 week ago would suggest moving to $foo
00:03:04 [fantasai]
Tab: Now I don't, because I think there's some interesting solutions
00:03:14 [fantasai]
Tab: partially due to dbaron's selector idea and some conversations with fantasai
00:03:37 [fantasai]
Tab: So think we should not go with $foo syntax
00:03:56 [fantasai]
Tab: I want to do something like SASS's extend, or what dbaron proposed, which needs a very compact thing
00:04:03 [fantasai]
Tab: This why I don't want to use that syntax right now
00:04:12 [fantasai]
Tab: I want to leave us with these two functions var() and parent-var(), as written
00:04:25 [fantasai]
Tab: and keep what's there for var declarations
00:04:31 [fantasai]
Tab: maybe one of the other options suggestion
00:04:35 [fantasai]
Florian: I'm happy with this proposal
00:04:45 [fantasai]
jdaggett: When you're using the variable, what's the syntax
00:04:56 [fantasai]
Florian: That was the way initially proposed to the group
00:05:01 [fantasai]
Rossen: it's good
00:05:33 [fantasai]
fantasai: I think it's good that the basic use is consistent with the more complex uses
00:05:46 [fantasai]
jdaggett: I don't like the syntax, but $foo keeps the stylesheet a lot more tight
00:05:56 [fantasai]
Molly: People are already familiar with $foo
00:06:02 [fantasai]
jdaggett: It also causes confusion because it's a shell variable
00:06:10 [fantasai]
jdaggett: But having compact notation is important
00:06:16 [fantasai]
Tab: I think that's a decent argument against it
00:06:27 [fantasai]
Tab: Because in preprocessors, it behaves very differently
00:06:34 [fantasai]
Tab: In SASS etc. they are pretty much macros
00:06:48 [fantasai]
Tab: They're global variables, can do replacement anywhere for anything
00:07:01 [fantasai]
Tab: I think we want something similar to what SASS etc. do, but this isn't that
00:07:14 [fantasai]
Florian: Our variables are different, so we shouldn't match their syntax
00:07:24 [fantasai]
Tantek: Heard request from jdaggett for fully-written-out examples
00:07:28 [fantasai]
Tab: i nthe spec
00:08:05 [fantasai]
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 [fantasai]
Tab: That's still the case
00:08:14 [fantasai]
glazou: So why don't we use $foo
00:08:19 [fantasai]
Tab: First of all, they can't match us entirely.
00:08:27 [fantasai]
Tab: They can only do so in restricted cases, would be very confusing
00:08:39 [fantasai]
Tab: You can't do it without severe hacking
00:08:57 [fantasai]
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]
fantasai: Because we use the cascade and inheritance, and they do simple string substitution
00:09:47 [fantasai]
plinss: That only saves us collision with SASS. Doesn't save us the confusion in minds of authors.
00:10:09 [fantasai]
Florian: None of the existing languages that use $foo for denote variables ...
00:10:22 [fantasai]
glazou: We still need a way to express parent-var, and with $ you can't
00:10:32 [fantasai]
Tab: I want to reserve our use of $ for something similar
00:10:52 [fantasai]
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 [fantasai]
Florian: I think we're going to take some flames for it, but we should go this way
00:11:42 [fantasai]
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 [fantasai]
Tantek: I'd rather have that debate there than here.
00:12:05 [fantasai]
Tantek: Let's go with your judgement, and if authoring community has unified force against that, they we can reconsider.
00:12:14 [fantasai]
szilles: Besides, you can always use SASS to replace the $foos.
00:12:48 [fantasai]
fantasai: I agree with Molly that we need a very clear blog post explaining why we are deciding this way
00:13:16 [fantasai]
jdaggett: I think it is important to talk about thie inheritance model
00:13:31 [fantasai]
jdaggett: It needs to be in the forefront that this is not a macro replacement mechanism.
00:13:34 [fantasai]
Tab: Cool
00:13:44 [fantasai]
Tab: In the FPWD, all we had was var-foo and var(foo)
00:13:52 [fantasai]
Tab: We couldn't specify fallback, and didn't have parent-var()
00:13:59 [fantasai]
Tab: Are these acceptable in Level 1
00:14:13 [fantasai]
Tab: They could be deferred, but are sufficiently simple and useful that could be part of Level 1
00:14:33 [fantasai]
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 [fantasai]
jdaggett: In particular I don't like parent-var(), because it feels like an experiment
00:14:55 [fantasai]
jdaggett: The things it's useful for, might be better ways to do it.
00:15:08 [fantasai]
jdaggett: I think there's going to be little pockets of places where it will be difficult to get interop
00:15:26 [fantasai]
jdaggett: I'm not saying I oppose the feature, but for Level 1, get the simplest functionality out there
00:15:35 [fantasai]
Tab: I'm ok with deferring parent-var(), but really want to keep fallback
00:15:55 [fantasai]
glazou: How about add a note explaining parent-var(), as "in the future we may consider this"
00:16:15 [fantasai]
dbaron: So, I sortof have mixed feelings about this
00:16:23 [fantasai]
s/this/dropping parent-var/
00:16:30 [fantasai]
dbaron: on onehand, I'm not crazy about the name parent-var()
00:16:40 [fantasai]
dbaron: On the other hand, it seems trivial to implement once you have all the rest
00:16:49 [fantasai]
dbaron: Although maybe I'm missing something
00:16:54 [fantasai]
glazou: I think you're right it is very simple
00:17:06 [fantasai]
glazou: I think web authors using variables will need more, parent-var() is only the first step
00:17:17 [fantasai]
Tab: On one hand I have several use cases really awesome for parent-var in the spec
00:17:27 [fantasai]
jdaggett: There may be many example,s but maybe that's not the right set
00:17:36 [fantasai]
jdaggett: If we stake a claim on parent-var, everything else has to fit in
00:17:48 [fantasai]
glazou: If it's simple to implement, can do Level 2 in a snap
00:18:01 [fantasai]
Tab: ... grab property value from the parent and use the value in your stuff
00:18:08 [fantasai]
dbaron: that's a can of worms
00:18:28 [fantasai]
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 [fantasai]
Tantek: Provide the use cases for other possibilities
00:18:48 [fantasai]
Tantek: I think we should include it based on commentary that has been made
00:18:55 [fantasai]
jdaggett: Keep in mind this is not prefixed
00:19:08 [fantasai]
tantek: 2nd, we have a notion of variables in one place, which is the font-size
00:19:17 [fantasai]
tantek: You can refer to font-size of yourself or parent in a few places
00:19:33 [fantasai]
tantek: Nobody's come and said "I want font size of grandparent"
00:19:39 [fantasai]
dbaron: we have rem now
00:19:51 [fantasai]
Tantek: but probably safe to go with just parent-var
00:19:57 [fantasai]
Florian: I say we go with L1 without parent
00:20:05 [fantasai]
Florian: Then make a L2 quickly that just has parent
00:20:34 [fantasai]
Florian: have the discussion about parent-var there
00:20:39 [fantasai]
tantek: ...
00:20:47 [fantasai]
jdaggett: This is going to spread like wildfire once it's implemented
00:21:17 [fantasai]
Tab: I'm fine with this. Fine with doing small drafts that advance quickly.
00:21:32 [fantasai]
glazou: Tantek, I would agree with you if it was going to take awhile, but this is small and fast
00:22:26 [fantasai]
RESOLVED: Syntax of variables settled on var-foo and var(foo)
00:22:46 [fantasai]
ACTION: TabAtkins, fantasai, and glazou to write blog post explaining why not using $
00:22:46 [trackbot]
Sorry, couldn't find user - TabAtkins,
00:23:00 [fantasai]
RESOLVED: Include fallback in Level 1
00:23:10 [fantasai]
RESOLVED: Defer fallback to Level 2
00:23:46 [fantasai]
RESOLVED: Accept Variables L2 with parent-var() as work item
00:24:07 [dbaron]
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 [fantasai]
jdaggett: I want that sentence changed. He knows which sentence.
00:25:52 [fantasai]
RESOLVED: Publish WD of CSS Variables providing sentence jdagget objects to is removed.
00:27:17 [fantasai]
plinss: Who is building a test suite for Variables?
00:27:24 [fantasai]
jdaggett: dbaron has already started
00:27:39 [fantasai]
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 [fantasai]
s/Defer fallback/Defer parent-var/
00:30:19 [fantasai]
Meeting closed.
00:30:49 [dbaron]
$ hg ci -m"Switch syntax from $test to var(test)." .
00:30:56 [dbaron]
summary: Switch syntax from to var(test).
00:43:57 [tantek]
tantek has joined #css
00:47:51 [jdaggett]
jdaggett has joined #css
01:03:43 [pcupp]
pcupp has joined #css
01:30:20 [myakura]
myakura has joined #css
01:45:20 [arronei_]
arronei_ has joined #css
01:53:02 [glenn]
glenn has joined #css
02:10:07 [jet]
jet has joined #CSS
02:27:39 [pcupp]
pcupp has joined #css
02:38:38 [jet]
jet has left #CSS
02:46:34 [jet]
jet has joined #CSS
02:53:42 [glenn]
glenn has joined #css
03:05:46 [tantek]
tantek has joined #css
03:23:15 [leaverou]
leaverou has joined #css
03:27:49 [shepazu]
shepazu has joined #css
03:30:50 [myakura]
myakura has joined #css
03:54:18 [glenn]
glenn has joined #css
04:38:29 [arronei_]
arronei_ has joined #css
04:45:26 [tantek]
tantek has joined #css
04:49:15 [miketaylr]
miketaylr has joined #css
04:54:58 [glenn]
glenn has joined #css
05:31:08 [myakura]
myakura has joined #css
05:40:46 [dbaron]
dbaron has joined #css
06:07:41 [drublic]
drublic has joined #css
06:50:01 [glenn]
glenn has joined #css
06:50:19 [Ms2ger]
Ms2ger has joined #css
07:03:12 [tantek]
tantek has joined #css
07:31:34 [myakura]
myakura has joined #css
07:57:49 [drublic]
drublic has joined #css
08:49:21 [glenn]
glenn has joined #css
09:00:06 [jarek]
jarek has joined #css
09:05:07 [macpherson_]
macpherson_ has joined #css
09:15:43 [macpherson__]
macpherson__ has joined #css
09:17:59 [macpherson_]
macpherson_ has joined #css
09:28:39 [macpherson__]
macpherson__ has joined #css
09:32:02 [myakura]
myakura has joined #css
09:50:06 [glenn]
glenn has joined #css
09:53:36 [myakura]
myakura has joined #css
10:50:44 [glenn]
glenn has joined #css
11:06:20 [leaverou]
leaverou has joined #css
11:12:05 [decadance]
decadance has joined #css
11:51:23 [glenn]
glenn has joined #css
12:28:40 [Zakim]
Zakim has left #css
12:29:19 [shepazu]
shepazu has joined #css
12:39:10 [leaverou]
leaverou has joined #css
12:52:03 [glenn]
glenn has joined #css
13:26:11 [myakura]
myakura has joined #css
13:52:43 [glenn]
glenn has joined #css
14:00:57 [jet]
jet has joined #CSS
14:05:06 [arronei_]
arronei_ has joined #css
14:10:26 [miketaylr]
miketaylr has joined #css
14:11:38 [miketaylr]
miketaylr has joined #css
14:21:36 [jet_]
jet_ has joined #CSS
14:46:01 [jet]
jet has joined #CSS
14:46:47 [glenn]
glenn has joined #css
14:47:29 [tantek]
tantek has joined #css
15:03:52 [krit]
krit has joined #css
15:23:28 [jet_]
jet_ has joined #CSS
15:32:26 [jet]
jet has joined #CSS
15:42:21 [dbaron]
dbaron has joined #css
15:51:04 [florian]
florian has joined #css
15:52:51 [glazou]
glazou has joined #css
15:53:01 [Zakim]
Zakim has joined #css
15:53:21 [glazou]
RRSAgent, make logs public
15:53:29 [glazou]
rrsagent, this meeting spans midnight
15:55:32 [glenn]
glenn has joined #css
15:56:46 [lstorset]
lstorset has joined #css
15:59:19 [SteveZ]
SteveZ has joined #css
16:00:31 [TabAtkins_]
TabAtkins_ has joined #css
16:01:47 [cabanier]
cabanier has joined #css
16:10:01 [TabAtkins_]
ScribeNick: TabAtkins_
16:10:42 [TabAtkins_]
Topic: Prefixing Policy
16:10:46 [glazou]
Topic: Prefixes
16:11:13 [TabAtkins_]
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 [TabAtkins_]
dbaron: Because the right solution may not involve prefixes.
16:11:28 [TabAtkins_]
Topic: Experimental Features Policy
16:11:35 [TabAtkins_]
florian: Two rpoblems with the current policy.
16:11:42 [TabAtkins_]
florian: There's no clear good way for authors to use it.
16:11:50 [TabAtkins_]
florian: And not even just clear - I think there's no good way at all.
16:12:05 [TabAtkins_]
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 [TabAtkins_]
florian: This matches most author's workflow.
16:12:20 [TabAtkins_]
sylvaing: Until we renamed things.
16:12:28 [TabAtkins_]
florian: Yeah, but if we dont' change things, that works.
16:12:41 [TabAtkins_]
tantek: I think your first statement was flawed.
16:12:58 [TabAtkins_]
tantek: I think that "making it work" isn't necessarily something the WG should be committing to, if it's experimental.
16:13:17 [TabAtkins_]
florian: There is no good way to use these, so people use them in bad ways.
16:13:35 [TabAtkins_]
glenn: Modernizr helps make this less painful, right?
16:13:47 [TabAtkins_]
tantek: This is why I think that David's way of reframing the problem is useful.
16:14:03 [TabAtkins_]
florian: the things that we consider "experimetnal" are being used.
16:14:24 [TabAtkins_]
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 [TabAtkins_]
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 [TabAtkins_]
glazou: "Now you can do border-foo!"
16:15:19 [fantasai]
sylvaing: Authors are using it because it's in production releases
16:15:33 [TabAtkins_]
florian: This is true, but I think we should be careful about drawing conclusions from it.
16:15:38 [tantek]
tantek has joined #css
16:15:56 [TabAtkins_]
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 [TabAtkins_]
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]
krit has joined #css
16:17:11 [TabAtkins_]
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 [fantasai]
sylvaing^: Is it really experimental if we have multiple browsers shipping interoperable implementations?
16:17:34 [TabAtkins_]
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 [TabAtkins_]
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 [TabAtkins_]
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 [TabAtkins_]
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 [TabAtkins_]
tantek: I think that problem has been previously characterized as "once you'veleaked it to the web".
16:19:40 [TabAtkins_]
hober: canvas, for instance.
16:19:46 [TabAtkins_]
tantek: Once you've leaked it, you can't take it back.
16:19:58 [TabAtkins_]
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 [TabAtkins_]
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 [TabAtkins_]
hober: So I think it'll prove difficult to use a different mechanism for the two cases.
16:20:51 [TabAtkins_]
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 [TabAtkins_]
florian: If you later think you should expose it to the web, you can flip that switch later.
16:21:28 [TabAtkins_]
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 [TabAtkins_]
florian: They should probably be prefixed, to avoid accident collisions with WG stuff.
16:22:12 [TabAtkins_]
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 [hober]
Of course, vendor-prefixed properties get created for several different purposes. see
16:22:49 [TabAtkins_]
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 [TabAtkins_]
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 [TabAtkins_]
dbaron: There are plenty of vendor-prefixed things that haven't taken off.
16:23:43 [TabAtkins_]
glazou: Sure, but these are the no-question things. Others, vendors may at least consider it.
16:23:57 [TabAtkins_]
tantek: What do you mean by "things for ms word dont' eventually hit the web"?
16:24:08 [TabAtkins_]
glazou: The -mso- stuff never even considered to hit the web.
16:24:26 [TabAtkins_]
tantek: You can find tons of mso prefixes on the web.
16:24:38 [TabAtkins_]
glazou: Yes, but no one ever implemented them, or even intended to.
16:24:58 [TabAtkins_]
florian: I think you're not disagreeing with me - if you create mso or itunes things, and you initially isolate them...
16:25:16 [TabAtkins_]
florian: If someone else realizes they're not specialized and would be generally useful, someone can bring them to the WG.
16:25:25 [TabAtkins_]
glazou: *If* someone brings them to the WG. People don't do that.
16:25:51 [TabAtkins_]
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]
karl has joined #css
16:26:33 [dbaron]
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 [TabAtkins_]
sylvaing: Can't do it.
16:26:52 [TabAtkins_]
glazou: It's a problem of strategy.
16:27:20 [karl]
RRSAgent, pointer?
16:27:20 [RRSAgent]
16:27:22 [TabAtkins_]
sylvaing: People have public bits they don't want to expose.
16:27:53 [TabAtkins_]
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]
Rossen has joined #css
16:28:09 [TabAtkins_]
leif: The WG can bring things up on their own, yes.
16:28:28 [fantasai]
sylvaing^: It's a matter of corporate disclosure
16:29:07 [TabAtkins_]
sylvaing: Sometimes it's not even mentioned. There are things in W8 that aren't even mentioned - just using CSS.
16:29:19 [TabAtkins_]
jdaggett: Some of these are proprietary proeprties - not really intended to be part of CSS.
16:29:27 [TabAtkins_]
jdaggett: And that's part of the problem. Authors dont' see that distinction.
16:29:53 [TabAtkins_]
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 [sylvaing]
s/mentioned/submitted yet
16:30:33 [TabAtkins_]
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 [TabAtkins_]
florian: For the ones not intended for the web at all, I say just dont' expose them at all.
16:31:06 [TabAtkins_]
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 [TabAtkins_]
florian: This is similar to iTunes, and other types of things.
16:31:38 [TabAtkins_]
florian: So what happens when you actually expose things to the web.
16:32:42 [TabAtkins_]
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 [TabAtkins_]
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 [TabAtkins_]
szilles: So I think you're saying that we own the unprefixed space, and anyone else must prefix.
16:33:46 [TabAtkins_]
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 [TabAtkins_]
florian: But for the things that *aren't* meant for the web, don't expose them, and prefix them.
16:34:35 [TabAtkins_]
glazou: Again, I think the idea to "don't expose them to the web" is unworkable. More apps move to webapps.
16:34:50 [TabAtkins_]
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 [TabAtkins_]
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 [TabAtkins_]
glazou: When I'm downloading a random epub file from the web, should it or not render epub properties?
16:36:03 [TabAtkins_]
florian: If you can recognize it as epub...
16:36:13 [TabAtkins_]
glazou: There's no difference between epub and a random html file.
16:36:40 [jdaggett]
jdaggett has joined #css
16:36:41 [TabAtkins_]
hober: I think it's unreasonable to expect epub authors to have a different workflow than regular html workflows.
16:37:08 [TabAtkins_]
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 [TabAtkins_]
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 [TabAtkins_]
jdaggett: You're advocating a bad idea.
16:37:52 [TabAtkins_]
glazou: Not advocating - describing.
16:38:27 [TabAtkins_]
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 [TabAtkins_]
szilles: Browsers aren't the only thing that can display web content.
16:38:46 [TabAtkins_]
szilles: They may accept different things than what the browser accepts.
16:38:58 [TabAtkins_]
szilles: If those other things become popular enough, there may be pressure to adopt what they do.
16:39:17 [TabAtkins_]
szilles: So I'm hearing daniel say that it's a market force that we cant' do anything about.
16:39:37 [TabAtkins_]
sylvaing: In W8, we try to have a clean separation between web and app.
16:39:55 [TabAtkins_]
sylvaing: But quickly, the Facebooks and Netflixes of the world, just build an app with a web container.
16:40:10 [TabAtkins_]
sylvaing: And quickly they want the full set of things that apps can do.
16:40:29 [Koji]
Koji has joined #css
16:40:32 [TabAtkins_]
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 [TabAtkins_]
jdaggett: I think the epub process is a perfect example of how we should not try and act.
16:41:03 [TabAtkins_]
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 [TabAtkins_]
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 [TabAtkins_]
tantek: Before epub we had chtml, though that's an example of something that died.
16:42:03 [TabAtkins_]
tantek: Other groups will try to extend.
16:42:15 [TabAtkins_]
tantek: We can try to outcompete them, or we can get outcompeted.
16:42:30 [TabAtkins_]
glazou: Epub is a nice extensions because they have public documents detailing everything.
16:42:46 [TabAtkins_]
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 [TabAtkins_]
glazou: yes, it's a good case.
16:42:57 [TabAtkins_]
glazou: It's not the best thing to do, but they tried to do good.
16:43:18 [TabAtkins_]
dbaron: They had a schedule, and no intention of putting in enough resources to meet that schedule properly.
16:43:29 [TabAtkins_]
szilles: I think it's important that such experiments are identified as such.
16:43:50 [TabAtkins_]
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 [TabAtkins_]
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 [TabAtkins_]
jdaggett: It isn't just a matterof slow and burearcratic, as tantek puts it - it's just a damned hard problem.
16:45:01 [TabAtkins_]
glazou: It can be fast and agile and not disclosed because of competitive reasons.
16:45:18 [TabAtkins_]
tantek: Often burearcracy and process has gotten in our way historically.
16:45:24 [TabAtkins_]
tantek: We're aware of and trying to fix that problem.
16:45:59 [TabAtkins_]
jdaggett: Prioritization si crucial.
16:46:17 [TabAtkins_]
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 [TabAtkins_]
florian: I think it magnifies the problem - it's not a root cuase.
16:46:53 [TabAtkins_]
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 [TabAtkins_]
szilles: How we label is a red herring.
16:47:12 [smfr]
smfr has joined #css
16:47:13 [TabAtkins_]
plinss: It alleviates some of the pressure.
16:47:27 [TabAtkins_]
plinss: There's no disagreement in the group that thigns come up that we need to work on more aggressively.
16:47:54 [TabAtkins_]
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 [TabAtkins_]
tantek: People brought up a bunch of examples.
16:48:21 [TabAtkins_]
fantasai: Examples: text-size-adjust was not disclosed and became super-popular
16:48:38 [TabAtkins_]
fantasai: border-radius, microsoft's grid layout proposal...
16:48:50 [TabAtkins_]
fantasai: Looking at different ones of these, you'll make different suggestions about what's best.
16:49:01 [TabAtkins_]
fantasai: border-radius - why have prefixes? We all did the same.
16:49:18 [TabAtkins_]
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 [TabAtkins_]
fantasai: So we shouldn't focus on justone of these problems, we should look at all of them.
16:49:36 [TabAtkins_]
fantasai: Like T&A is more of a border-radius case.
16:49:51 [TabAtkins_]
tantek: More general examples.
16:49:59 [TabAtkins_]
tantek: There was the UI example - UI of iTunes or Firefox.
16:50:20 [TabAtkins_]
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 [TabAtkins_]
florian: So rather than get the details more, let's talk about solutions and see if it turns out good.
16:50:43 [TabAtkins_]
fantasai: Starting proposal!
16:50:45 [TabAtkins_]
fantasai: Section A.
16:50:58 [TabAtkins_]
fantasai: If it's not web-ready, ship it prefixed and don't expose it to the web.
16:51:04 [TabAtkins_]
Section B.
16:51:13 [TabAtkins_]
fantasai: For standards-track features, ship only in non-release builds.
16:51:29 [TabAtkins_]
fantasai: ...unprefixed.
16:51:59 [TabAtkins_]
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 [TabAtkins_]
dbaron: The way another browser "ships a release" is by breaking these rules in the first place.
16:53:04 [TabAtkins_]
fantasai: If three browsers total implement (non-shipping) and we have interop and think it's a good idea, everyone ship.
16:53:40 [TabAtkins_]
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 [TabAtkins_]
glazou: This does not solve the text-size-adjust problem.
16:54:37 [TabAtkins_]
szilles: What problem does this solve?
16:54:56 [TabAtkins_]
TabAtkins_: The bit where we have multiple prefixed versions living for a while and making authors lives hard.
16:55:21 [TabAtkins_]
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 [TabAtkins_]
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 [tantek]
16:56:24 [plinss]
ack tantek
16:56:30 [TabAtkins_]
tantek: Response to steve - what we ahve seen with T&A&transforms, these exampels have disproven your statement.
16:56:43 [TabAtkins_]
tantek: In practice, we have not needed a testsuite to get itnerop, as evidenced by author adoption.
16:56:58 [TabAtkins_]
tantek: if they weren't "sufficiently interoperable", authors wouldn't be using them so much.
16:57:03 [TabAtkins_]
tantek: This is a pretty strong bar.
16:57:23 [TabAtkins_]
glazou: "perceived interop", not "interop".
16:57:37 [TabAtkins_]
szilles: My concern is that, left to the vendors to declare interop, this won't work.
16:57:49 [TabAtkins_]
szilles: Marketing departments have a strong idea to do that.
16:58:06 [TabAtkins_]
plinss: I don't think anyone is suggesting that a single vendor declaring interop is sufficient.
16:58:33 [TabAtkins_]
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 [TabAtkins_]
dbaron: But we did that with TTA, and the group said no the first time.
16:59:03 [TabAtkins_]
florian: When we asked the group "can we release TTA", we were aiming for a different level of interop.
16:59:05 [dbaron]
hmmm, maybe I'm misremembering and thinking of something else
16:59:19 [TabAtkins_]
florian: We were asking for full interop. We're now not shooting for that - we want "sufficient interop".
16:59:19 [tantek]
dbaron - no you're remembering correctly
16:59:28 [fantasai]
no, the first time we decided not to unprefix, largely because MS did not want to
16:59:29 [tantek]
we asked to unprefix TTA in Paris in February and were told no
16:59:40 [tantek]
I'm sure we can look that up in the minutes
16:59:40 [fantasai]
and then when they decided to unprefix, that gave us consensus in the WG
16:59:55 [TabAtkins_]
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 [TabAtkins_]
glazou: I'm seeing two cases.
17:00:17 [TabAtkins_]
glazou: I don't think that this process is the difficult one.
17:00:42 [TabAtkins_]
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 [TabAtkins_]
florian: If text-size-adjust was released under this process, it would not be in a webkit prefix.
17:01:24 [TabAtkins_]
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 [TabAtkins_]
florian: This system doesn't prevent the bad things from happening, but it untaints them.
17:01:53 [TabAtkins_]
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 [TabAtkins_]
florian: But at least we're not stuck witht he webkit prefix name that everyone has to support.
17:02:12 [TabAtkins_]
florian: It's not fantastic, but it's an improvement.
17:02:31 [TabAtkins_]
tantek: There's a bunch of different problems ehre.
17:02:47 [TabAtkins_]
tantek: I like the proposal as developed. It doesnt solve all the problems, but it soles all of them.
17:02:58 [dbaron]
17:03:07 [TabAtkins_]
florian: I think it doesn't solve all of them, but it solves some of them better than the current world.
17:03:38 [TabAtkins_]
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 [tantek]
s/soles all of them/solves some of them well enough/
17:04:08 [TabAtkins_]
szilles: Or everyoen will follow the bad design.
17:04:23 [TabAtkins_]
TabAtkins_: The reality is that everyone follows the bad design *and* puts a webkit prefix on it.
17:04:38 [TabAtkins_]
szilles: But it prevents us from doing better under a better name.
17:04:54 [tantek]
"if it works, the author will use the unprefixed version because it's shorter typing"
17:04:59 [tantek]
17:05:21 [TabAtkins_]
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 [TabAtkins_]
glazou: A corollaorya of that is that purely proprietary things shouldnt' use a prefix.
17:05:58 [TabAtkins_]
dbaron: I don't think we should try to come up with a master plan for the future.
17:06:04 [TabAtkins_]
dbaron: We should be figuring out how to adjust what we're doing.
17:06:13 [TabAtkins_]
dbaron: And I think it will require continued adjustment in the future.
17:06:16 [dbaron]
ack dbaron
17:06:18 [TabAtkins_]
dbaron: We won't do it all today.
17:06:28 [Ms2ger]
17:06:28 [TabAtkins_]
dbaron: I think a few directions in which we should be adjusting things...
17:06:34 [TabAtkins_]
dbaron: (1) ship less prefixed stuff on the web
17:06:41 [TabAtkins_]
dbaron: (2) unprefix things faster when we get interop
17:07:02 [TabAtkins_]
florian: I think we need to acknowledge that not everyone will follow the policy.
17:07:14 [TabAtkins_]
florian: This will happen, so our policy shoudl just not make things worse when this happens.
17:07:37 [TabAtkins_]
hober: Note that dbaron's #2 is something we can do right now withotu changing policies.
17:07:40 [tantek]
"when we get interop" - what level of interop? authors vs. test suites
17:07:52 [TabAtkins_]
fantasai: Actually, the current policy is just the "legacy content" excuse.
17:07:57 [TabAtkins_]
fantasai: That's what we used for TTA.
17:08:21 [tantek]
TabAtkins: for the one issue of let's unprefix faster, let's formally adopt Elika's stated proposal (from dbaron)
17:08:31 [tantek]
szilles: I can live with that
17:09:04 [TabAtkins_]
glenn: That's reminiscent of the knowledge that Maciej required for CR-exit.
17:09:09 [tantek]
17:09:12 [TabAtkins_]
glenn: For HTML.
17:09:29 [TabAtkins_]
szilles: I like that it's not individual manufacturers making that decision.
17:09:47 [TabAtkins_]
tantek: One thing I'llr aise is that one recent RFC deprecated the use of x-.
17:09:56 [hober]
glenn was referring to this email:
17:09:58 [TabAtkins_]
tantek: But they drew a strong line between vendor-specific and experimental features.
17:10:06 [TabAtkins_]
tantek: They think that using x- for vendor-specific still works.
17:10:15 [TabAtkins_]
tantek: But not for experimental, because in the end everyone implemented it anyway.
17:10:23 [TabAtkins_]
tantek: So let's consider that work and analysis done by IETF.
17:11:06 [TabAtkins_]
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_]
TabAtkins_: So are there standing objections to fantasai's proposal?
17:12:27 [mmielke]
mmielke has joined #css
17:12:30 [TabAtkins_]
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 [TabAtkins_]
17:13:10 [TabAtkins_]
glazou: We'll post to email, and formally resolve in a few days if there are no objections.
17:13:39 [TabAtkins_]
Topic: Fonts
17:15:25 [glenn]
s/Maciej required for/Maciej suggests for permissive version of/
17:15:28 [dbaron]
17:15:34 [TabAtkins_]
jdaggett: I wanted to talk about default font features.
17:15:39 [TabAtkins_]
jdaggett: We talked aboutit a bit on the call.
17:15:52 [TabAtkins_]
jdaggett: People seemed comfortable, but there were some concerns fromMS developers.
17:15:54 [dbaron]
also, was my earlier proposal on experimental features
17:15:59 [TabAtkins_]
jdaggett: So we'll quickly review.
17:16:18 [TabAtkins_]
jdaggett: [shows demo]
17:16:28 [dbaron]
alternate link for that is!topic/[1-25]
17:16:31 [TabAtkins_]
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 [TabAtkins_]
florian: The default is influence by data coming fromthe font?
17:16:52 [TabAtkins_]
jdaggett: No, there is a set of features that are declared as "default" in the OT spec.
17:17:25 [TabAtkins_]
jdaggett: Because FF is turning these on by default, the fourth line and the second line match.
17:17:52 [TabAtkins_]
jdaggett: However, if we go over to Chrome, the default case is different from the random-feature case.
17:18:10 [TabAtkins_]
jdaggett: The internal reason for this is that there's a different rendering path with differetn defaults.
17:18:21 [TabAtkins_]
jdaggett: I'm saying that the default case should be the same as the random-feature case.
17:18:33 [TabAtkins_]
jdaggett: So that turning on a random feature shouldn't also turn on random other features.
17:18:55 [TabAtkins_]
jdaggett: [shows comparative screenshot]
17:19:08 [TabAtkins_]
jdaggett: What this shhows is language-sensitive features.
17:19:26 [TabAtkins_]
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 [TabAtkins_]
jdaggett: This is specified with a language tag. This gets sent downt ot he font engine, and that handles things correctly.
17:19:53 [TabAtkins_]
jdaggett: In IE10, this works correctly, but it's not yet implemented in webkit.
17:20:03 [TabAtkins_]
jdaggett: But weird behavior in IE10 for another feature.
17:20:11 [TabAtkins_]
jdaggett: In serbian, this glyph should be a localized alternate.
17:20:32 [TabAtkins_]
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 [TabAtkins_]
glenn: So the algorithm used by the UA to enable the OT advanced tables is different in different brwosers.
17:21:08 [TabAtkins_]
jdaggett: Yes, but I'm saying there shouldn't be side-effects from random features.
17:21:30 [TabAtkins_]
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 [glenn]
17:21:44 [TabAtkins_]
sylvaing: (1) there is no font-feature-settings - what features are on by default? That's a difference.
17:21:59 [TabAtkins_]
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 [TabAtkins_]
jdaggett: If we go to the OT spec...
17:22:20 [TabAtkins_]
jdaggett: It's a bit scattered.
17:22:28 [TabAtkins_]
jdaggett: These are the default features,a cross scripts.
17:22:36 [TabAtkins_]
jdaggett: Some specific scripts have extra features by default.
17:22:38 [dbaron]
17:22:49 [TabAtkins_]
jdaggett: [describes the table]
17:23:14 [dbaron]
17:23:24 [TabAtkins_]
jdaggett: [shows tone marks using one fo the default OT features]
17:23:45 [TabAtkins_]
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 [TabAtkins_]
sylvaing: Do you have a ref to the OT spec?
17:24:18 [TabAtkins_]
jdaggett: In CSS3 Fonts, section 7, there are several links in the text.
17:24:32 [TabAtkins_]
szilles: Which spec? ISO or MS?
17:24:35 [TabAtkins_]
jdaggett: Loosely-defined.
17:24:43 [TabAtkins_]
jdaggett: ISO is a file-format spec - it doesn't cover layout.
17:24:51 [TabAtkins_]
jdaggett: So we have to be a bit looser about what we consdier "the spec".
17:24:55 [glenn]
17:24:59 [TabAtkins_]
jdaggett: Hopefully they'll be more rigorous in the future.
17:25:16 [glenn]
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]
miketaylr has joined #css
17:26:43 [TabAtkins_]
sylvaing: Our default rendering is consistent across the windows platform
17:26:54 [TabAtkins_]
jdaggett: So if you could review this list and suggest changes, would be great.
17:27:00 [TabAtkins_]
jdaggett: I think we're covered here.
17:27:14 [TabAtkins_]
florian: If I'm following you right, there are three ways of doing this.
17:27:18 [glenn]
17:27:22 [TabAtkins_]
florian: One is the Chrome/MS way, which is not ideal.
17:27:30 [TabAtkins_]
florian: Another is the Firefox, which may require an extra switch.
17:27:32 [TabAtkins_]
jdaggett: Let me finish.
17:27:45 [TabAtkins_]
jdaggett: The features in the list in red are those which can be controlled.
17:27:54 [TabAtkins_]
jdaggett: ...via font-variant-ligatures.
17:28:09 [TabAtkins_]
jdaggett: I've put in a "none" value to font-variant-ligatures which turns off all defaults.
17:28:36 [TabAtkins_]
jdaggett: That will not disable the requried features.
17:28:47 [TabAtkins_]
jdaggett: These are usually specialized features that are *needed* for correct rendering of various things.
17:29:11 [TabAtkins_]
glenn: How would someone shut down the rlig feature?
17:29:19 [TabAtkins_]
jdaggett: font-feature-settings: rlig 0;. It's possible.
17:29:59 [TabAtkins_]
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 [TabAtkins_]
jdaggett: There are some perforamnce considerations.
17:30:23 [TabAtkins_]
jdaggett: As the glyph composition shows, some of these are already handled in an ad-hoc way.
17:30:27 [krit]
krit has joined #css
17:30:36 [TabAtkins_]
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 [TabAtkins_]
jdaggett: It just means there's a little additional logic before taking the fast path.
17:31:09 [TabAtkins_]
jdaggett: So I think we should resolve that the "none" value resolves the issue.
17:32:26 [TabAtkins_]
Bert: Is "none" the same as setting "no-*" for all the others?
17:32:54 [TabAtkins_]
jdaggett: Yes.
17:33:19 [TabAtkins_]
sylvaing: What about an "auto" value that is a default?
17:33:29 [TabAtkins_]
jdaggett: I'm keeping "normal" as the default.
17:33:42 [TabAtkins_]
jdaggett: kerning has "auto", because that's more prevalent and can be controlled by browser vendors.
17:34:13 [TabAtkins_]
RESOLVED: Accept font-variant-ligatures as written: "normal" is initial value, and "none" is added which turns off those features.
17:34:34 [TabAtkins_]
plinss: My only concern is that "normal" seems underdefined.
17:34:41 [TabAtkins_]
jdaggett: There's a section that defines the common defaults.
17:34:51 [TabAtkins_]
glenn: Could you put those common defaults for this feature in this section?
17:34:53 [TabAtkins_]
jdaggett: Oh, sure.
17:35:24 [TabAtkins_]
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 [TabAtkins_]
jdaggett: Yes.
17:35:35 [TabAtkins_]
RESOLVED: Public a new WD of Fonts.
17:36:15 [TabAtkins_]
<br dur=15min>
17:36:21 [TabAtkins_]
RESOLVED: Publish a new WD of fonts.
17:36:25 [dbaron]
"My system just crashed." "Oh, good."
17:45:16 [glenn]
s/put those common defaults for this feature in this section/put a link from "common defaults" to its defining section/
17:51:56 [jet]
dbaron: LOL!
17:52:40 [Rossen]
Rossen has joined #css
17:57:44 [krit]
krit has joined #css
18:00:35 [fantasai]
18:01:26 [Bert]
ScribeNick: Bert
18:01:37 [dbaron]
Topic: CSS3 Text
18:02:03 [Bert]
fantasai: We resolved to postpone to level 4, but now we have a shorthand idea.
18:02:23 [Bert]
... [issue-236]
18:02:26 [fantasai]
18:02:58 [Bert]
tab: sounds useful, now we have a useful way to address aliasing.
18:03:03 [Bert]
florian: I'd agree
18:03:33 [Bert]
fantasai: So resolve that word-wrap is shorthand for overflow-wrap?
18:03:50 [Bert]
RESOLVED: make word-wrap shorthand fpr overflow-wrap
18:04:23 [Bert]
18:04:23 [trackbot]
ISSUE-221 -- text-emphasis-color can't recompute color to match text on descendants -- raised
18:04:23 [trackbot]
18:04:45 [Bert]
fantasai: there is an errata open, should be posted to css3-color
18:05:20 [smfr]
smfr has joined #css
18:05:42 [smfr]
smfr has joined #css
18:05:49 [tantek]
18:06:01 [Bert]
action bert: add errata to css3-color errata ist about currentcolor, (as in above URL)
18:06:01 [trackbot]
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 [Bert]
18:06:23 [trackbot]
ISSUE-243 -- graphical effects and text-decoration -- raised
18:06:23 [trackbot]
18:06:36 [dbaron]
record of currentColor errata is in
18:06:37 [Bert]
fantasai: issue with underline and shadow and all these kinds of things
18:06:43 [Bert]
... if you have an ancestor,
18:07:05 [Bert]
... say whole para is underlined and a text has shadow, etc.
18:07:12 [Bert]
... is the underline shadowed?
18:07:32 [Bert]
SteveZ: Is the underline logically part of the para even if physically it is not?
18:07:43 [Bert]
fantasai: How about visibility?
18:07:53 [Bert]
SteveZ: If not visible, also not undelrined, I think.
18:08:02 [Bert]
dbaron: ssociated with the text.
18:08:12 [Bert]
... text decor gets colors from elt it comes from.
18:08:29 [Bert]
fantasai: if invisible, definitely not visible.
18:08:36 [Bert]
dbaron: You mean opacity?
18:08:39 [Bert]
fantasai: yes
18:08:47 [Bert]
dbaron: opacity happens all at once.
18:08:54 [Bert]
... I can't imagine another option
18:09:04 [Bert]
... opctity on ancestor applies to all descentants.
18:09:26 [Bert]
fantasai: Then remaining question is filter efefects (same way?) and tet shadow,
18:09:36 [Bert]
tab: filter efect is same yes
18:09:50 [Bert]
fantasai: part of underline could be shadowed and part not, looks weird.
18:09:57 [Bert]
SteveZ: looks weird eihter way
18:10:06 [Bert]
fantasai: [draws on white board]
18:10:17 [Bert]
dbaron: three cases:
18:10:33 [Bert]
... shadow on something inide, on same, on something outside.
18:10:43 [Bert]
... debate is on inside case
18:10:57 [Bert]
SteveZ: For emphasiz, I think the udenrline should get shdaow
18:11:20 [Bert]
fantasai: [draws text with underline, part of it get shadow]
18:11:26 [Bert]
... does underline get shadow?
18:11:45 [Bert]
TabAtkins_: I think so. Some case lookk weird, but bulk is ok.
18:11:53 [Bert]
dbaron: I have diff. intuition
18:11:55 [fantasai]
18:12:12 [Bert]
sylvaing: ie does shadow the underline
18:12:33 [Bert]
... so the etst case is para is underlined, and a part of iut has shadow?
18:12:38 [Bert]
fantasai: yes
18:12:51 [Bert]
sylvaing: webkit shadows the underine, ff also,
18:13:06 [Bert]
dbaron: what i syour test case, sylvaing ?
18:13:37 [sylvaing]
<!doctype html>
18:13:38 [sylvaing]
18:13:38 [sylvaing]
p {
18:13:38 [sylvaing]
text-decoration: underline;
18:13:38 [sylvaing]
18:13:38 [sylvaing]
#test {
18:13:40 [sylvaing]
text-shadow: 0.1em 0.1em #333;
18:13:42 [sylvaing]
18:13:44 [sylvaing]
18:13:46 [sylvaing]
<p>This is <span id="test">underlined</span></p>
18:13:51 [Bert]
sylvaing: [trying to copy his test case]
18:14:06 [Bert]
SteveZ: it makes more sens with shadow below than with above.
18:14:27 [Bert]
sylvaing: looks like opera doesn't shadow th eunderline
18:15:31 [Bert]
dbaron: Not sure we could do anything than what we do. WOnder how Opera is able to.
18:15:38 [Bert]
... text-shadow is inherited.
18:15:51 [Bert]
... we don't even now what is outside or inside
18:16:00 [Bert]
fantasai: But you do know for udnerline.
18:16:16 [Bert]
florian: We don't shadow the undelrine either way.
18:16:32 [dbaron]
s/either way/either way you nest them/
18:17:22 [Bert]
bert: in fantasai 's drawing i think without shadow looks better...
18:17:39 [Bert]
dbaron: To implement, you'd redo your text decoration...
18:17:47 [Bert]
fantasai: Basically the same way as for color
18:18:05 [fantasai]
s/Basically/Basically you do your shadow finding/
18:18:25 [Bert]
fantasai: So it is possible to implement, what do we want?
18:19:05 [Bert]
... if we decide it is not shadowed, users can still aplly a filter effect to get a shadow.
18:19:13 [Bert]
... It is not a very common case.
18:19:30 [Bert]
sylvaing: We have interop between 3 browsers out of 4 i tested.
18:19:44 [Bert]
SteveZ: General underline rule covers position and color.
18:19:55 [Bert]
... We'd like it to behave the same way.
18:20:05 [Bert]
... Filter effects hould apply, we said.
18:20:18 [Bert]
... Authors would be surprised if shadow was absent.
18:20:44 [Bert]
tab: I dont' care that much, lets go with [??]
18:21:03 [Bert]
plinss:biased towards finding shadow the same way as the color.
18:21:12 [Bert]
... decotration visually belongs to parent,
18:21:26 [Bert]
... slight bias.
18:21:45 [Bert]
SteveZ: So doesn't matter much now, and once it does, we'll put in a proeprty to control it.
18:21:58 [Bert]
plinss: I'm never quite sure how it should behave,
18:22:07 [Bert]
SteveZ: It's certainly one of th emost complex definitions.
18:22:36 [Bert]
dbaron: inclined to agree with bert about lower one [no shadow] being better.
18:22:56 [Bert]
SteveZ: I think it depends on the shadow. THis shadow is above. Below would look less strange.
18:23:19 [Bert]
plinss: the letter is different color, undelrine visually doens't belong to that text.
18:23:29 [dbaron]
I was actually saying I agreed with Brad (since fantasai quoted his opinion), but it turns out Brad and Bert agree :-)
18:24:37 [Bert]
fantasai: I'll look strange no matter what.
18:24:56 [Bert]
sylvaing: is there a use case where it is abad thing what browsers do now?
18:25:17 [Bert]
dbaron: I think i prefer to go the other way, more consistent with the model.
18:25:28 [Bert]
SteveZ: Despite that filters apply?
18:25:40 [Bert]
dbaron: Different kinds of things.
18:25:54 [Bert]
TabAtkins_: They just apply to the pixels.
18:26:05 [dbaron]
more consistent with the model and with most of the people who expressed an opinion about which is better
18:26:13 [Bert]
SteveZ: How would the user see the difference wheteher it is picel based or not?
18:26:39 [Bert]
sylvaing: Without a use caseshowing it is clearly wrong, I'd not like to change.
18:27:11 [dbaron]
A) shadows draw the same decorations as the text they're shadowing
18:27:29 [Bert]
glazou: bottom
18:27:50 [Bert]
18:28:02 [Bert]
sylvaing: top
18:28:12 [Bert]
Bert: bottom
18:28:18 [Bert]
koji: top
18:28:25 [Bert]
SteveZ: top
18:28:33 [Bert]
glenn: top
18:28:36 [Bert]
ted: top
18:28:39 [Bert]
alan: top
18:28:44 [Bert]
fantasai: abstain
18:28:49 [Bert]
tantek: abstain
18:28:53 [Bert]
TabAtkins_: top
18:28:56 [Bert]
dbaron: bottom
18:29:03 [Bert]
florian: bottom
18:29:07 [Bert]
leif: bottom
18:29:11 [dbaron]
18:29:13 [Bert]
peter: bottom
18:29:41 [Bert]
fantasai: How about a public poll?
18:29:56 [Bert]
sylvaing: Does anybody object to what is already done?
18:29:56 [glazou]
18:30:12 [Bert]
florian: That would be ok, even if it is against what i prefer.
18:30:17 [dbaron]
dbaron: yep
18:30:22 [Bert]
18:31:01 [Bert]
s/top/ apply shadow, because it is what is most widely implemented now.
18:31:17 [Bert]
18:31:17 [trackbot]
ISSUE-273 -- Interaction of text-decoration longhands and blink -- raised
18:31:17 [trackbot]
18:31:46 [Bert]
fantasai: issue is that text-deco takes a number of values, including blink.
18:31:59 [Bert]
... we dont have long hand for blink.
18:32:21 [Bert]
... we can make 'blink' a valid value in one of the long hand properties.
18:32:28 [Bert]
... or we can make a blink property
18:32:44 [Bert]
... or we can throw it away in the DOM.
18:33:04 [Bert]
[jokes about blink]
18:33:15 [Bert]
fantasai: Could be a text-decoration-style
18:33:28 [Bert]
TabAtkins_: I'm using animation instead of blink
18:33:49 [Bert]
glazou: [shows his home page with blinking underline]
18:34:02 [Bert]
dbaron: most browsers haven't implemented blink.
18:34:12 [Bert]
... not in webkit and IE.
18:34:13 [fantasai]
Tab: <blink> can be implemented as an animation
18:34:31 [Bert]
glazou: I don't like special cases. so not fantasai's last option.
18:35:04 [Bert]
dbaron: We added an additional proeprty -moz-tex-blink to solve this issue.
18:35:15 [Bert]
glazou: i like that one.
18:35:34 [Bert]
dbaron: It is an extra property for a feature we might rather remove.
18:35:46 [Bert]
fantasai: Prefer to not ceate new property, seems excessive.
18:35:59 [Bert]
... prefer to put in on text-decoration-style.
18:36:36 [Bert]
TabAtkins_: Prefer to ignore the blink on the shorthand, parse it, but doens't do anything.
18:36:43 [Bert]
fantasai: not even store it?
18:37:04 [Bert]
tab: right, doens't round trip, only round trips functionally.
18:37:51 [Bert]
dbaron: it is backwards-incompatible to pout it on anything else than tetx-decoration-style.
18:38:05 [Bert]
... in fact, current spec seems not backwards compatible.
18:38:19 [Bert]
glazou: do not want to deprecate it.
18:38:33 [Bert]
TabAtkins_: But only two impls, so why not deprecate it?
18:38:40 [Bert]
plinss: We have two impls.
18:38:57 [dbaron]
We haven't yet implemented the backwards-incompatible change that's in the spec
18:39:01 [Bert]
tantek: dprecate doesn't mean remove.
18:39:05 [dbaron]
it looks like we still accept 'text-decoration: underline blink overline'
18:39:23 [Bert]
plinss: But still needs to be defined, even if deprecated.
18:39:56 [Bert]
... can you say 'underline red overline'
18:40:08 [Bert]
dbaron: Not according to spec, and don't thing you should be able to
18:40:18 [Bert]
plinss: and 'underine solid overline'?
18:40:25 [Bert]
fantasai: Seems odd ordering.
18:40:33 [Bert]
... Inclinded to say no.
18:40:48 [Bert]
dbaron: Easiest path forward is to make 'blink' value of text-decoration-line
18:41:01 [Bert]
... the way we make the shorthand is bit weird.
18:41:12 [Bert]
... because on eof the long hands is the old property.
18:41:23 [Bert]
... We coluld just have added the new properties
18:41:51 [Bert]
... we moved text-decoration functionailty.
18:42:08 [Bert]
... blink is funny since CSS1.
18:42:32 [Bert]
[talk about history of netscape]
18:43:23 [Bert]
florian: Opera has implemented it. I'm not srongly asking for deprecation, but in favor of deprecation.
18:43:50 [Bert]
SteveZ: You don't really want people to use blink for accessibilty reasons.
18:44:07 [Bert]
fantasai: We can map BLINK tag to anaimation in user agent style sheet.
18:44:15 [dbaron]
glazou (before SteveZ): If we're going to deprecate it, should have an example explaining how to do it with animations.
18:44:33 [Bert]
plinss: resolve to put blink on txt-decoration-line and deprecate it?
18:44:56 [Bert]
florian: so: should not, but are allowed to use blink?
18:45:13 [Bert]
plinss: it is a warning that it *may* be removed from spec later.
18:45:45 [Bert]
RESOLVED: blink is value of text-decoration-line and it is deprecated with warning that authors should not use it.
18:46:41 [Bert]
RESOLVED: add example of corresponding animation to the spec.
18:46:58 [jdaggett]
jdaggett has joined #css
18:47:00 [dbaron]
(in the UA style sheet appendix)
18:47:03 [jdaggett]
18:47:23 [Bert]
jdaggett: I did some tests.
18:47:31 [Bert]
... Checking interopreability.
18:48:06 [Bert]
... letter spacing should control spacing on either side of char, but should not affect last letter (if right aligned line)
18:48:20 [Bert]
... [shows image]
18:48:28 [fantasai]
18:48:33 [fantasai]
"Letter-spacing must not be applied at the beginning or at the end of a line."
18:48:38 [Bert]
... But implementatiosn add spacing after last letter.
18:48:57 [Bert]
... [shows another image]
18:49:13 [Bert]
... THis image shows fully justified.
18:49:27 [Bert]
fantasai: The spec already says what UAs must do.
18:49:42 [Bert]
jdaggett: It doesn't say *how* spacing is applied.
18:50:14 [Bert]
... at the end of the line yu should not get space.
18:50:24 [Bert]
fantasai: Yes, that is a bug according to the current spec.
18:50:51 [Bert]
jdaggett: But the spec doesn't say exacty that
18:51:22 [Bert]
dbaron: the spec is precise, but you are describing a differnet model, eqwually precise, but different at element boundaries.
18:51:41 [Bert]
jdaggett: I think you atually have to get into how it works, e.g., in rtl.
18:52:06 [Bert]
fantasai/dbaron: What impls do is already bug, according to current spec.
18:52:14 [Bert]
jdaggett: I don't see that text.
18:52:23 [Bert]
.. What fantasai quoted is not precise enough.
18:52:42 [Bert]
fantasai: Give me an example that is not covered by the spec, and we'll improve the spec.
18:53:02 [Bert]
jdaggett: and between ltr trl boundaries?
18:53:14 [Bert]
fantasai: It is still "between chars" as the spec says.
18:53:25 [Bert]
SteveZ: Hald on each side, and you can't tell the difference.
18:53:45 [Bert]
fantasai: You can do it as trailing edge, but you stll have to handle the boundaries correctly.
18:53:53 [Bert]
jdaggett: I'll have to look more.
18:54:00 [Bert]
... I started from looking nto justification.
18:54:13 [Bert]
... letter nd word spaceing is input to justify.
18:54:22 [Bert]
... allowed ot expand in different places.
18:54:37 [Bert]
... but the actual algo wasn't clear form the spec, for different values.
18:54:48 [Bert]
... Each diff value of text-justify,
18:54:57 [Bert]
florian: I have a similar concern:
18:55:15 [Bert]
... reading the spec, good algos can be done, but spec doesn't tell you how.
18:55:32 [Bert]
... the spec doens't induce vendors to implement those algos
18:55:49 [Bert]
SteveZ: It is modeled on systems from well before XSL.
18:56:06 [Bert]
jdaggett: Now we are designing knobs with semi-undefined justification systems.
18:56:29 [Bert]
... how these inputs are used, i don't see differences between justify values.
18:56:44 [Bert]
fantasai: Priorities between buckets.
18:56:57 [Bert]
... It sorts the expansion opportunities into buckets.
18:57:04 [Bert]
... It doesn't tell you the algo precisely.
18:57:13 [Bert]
... It is not our job to define the algo.
18:57:26 [Bert]
jdaggett: That's the pb, Knobs have no precise meaning.
18:57:36 [Bert]
alan: not ndefined, maybe udnerspecified.
18:57:53 [Bert]
florian: Intentinally, i think. Don't prevvent better algos.
18:58:01 [Bert]
jdaggett: But we need a mininmum.
18:58:16 [Bert]
... I don't udnertsand th euse cases for the different justify values.
18:58:21 [Bert]
... What are teh examples.
18:58:33 [Bert]
... I dnbd' tsee a whole lot of difference in trying them.
18:58:45 [Bert]
... It seems to have been modeled on IE 5.5.
18:58:59 [Bert]
... Not clear where the difference are.
18:59:11 [Bert]
... What are the use cases, maybe sylvain can tell?
18:59:17 [Bert]
.. Are the cases till relevant?
18:59:22 [Bert]
s/.. /... /
18:59:31 [Bert]
sylvaing: You wan tto deprecate some?
18:59:44 [Bert]
jdaggett: Spec is just too vague.
18:59:57 [Bert]
fantasai: table in spec shows the differences.
19:00:22 [Bert]
florian: Don't agree. It seems most of these are needed for internationaliztion.
19:00:33 [Bert]
fantasai: One case is mixed scripts on one line.
19:00:49 [Bert]
... Interword will expand the spaces and nothing else.
19:00:59 [Bert]
... ideograph exapnds between ideographs.
19:01:06 [Bert]
... distribute expands both.
19:01:22 [Bert]
florian: Different countries have different expectaions.
19:01:37 [Bert]
jdaggett: Do we have collected the examples?
19:01:50 [Bert]
florian: With this spec we can impl an algo that matches the spec.
19:02:06 [Bert]
... But that algo may still not be very good.
19:02:15 [Bert]
... A bad algo can stil be conformant.
19:02:36 [Bert]
fantasai: We cannot define all algos. That's more than a PhD research.
19:02:51 [Bert]
jdaggett: All I ask is some simple use cases.
19:03:02 [Bert]
... why is it important to have these property values?
19:03:10 [Bert]
fantasai: Pictures?
19:03:18 [Bert]
jdaggett: Conncrete exampels.
19:03:40 [Bert]
jdaggett: Is there enough info in the spec to say if an impl matches?
19:04:06 [Bert]
... Not saying we should deprecate. But I don't see the diff. when trying them out.
19:04:31 [Bert]
florian: I'm not sure I'm asking for more specific. That might lock into bad algo.
19:04:40 [Bert]
... But I'm gemnerally unhappy.
19:04:48 [Bert]
... Not sure if more defined makes me happier.
19:05:04 [Bert]
SteveZ: Document whatr the differences are is one yhing.
19:05:16 [Bert]
jdaggett: Spc shoul dat leats have rudimentary examples.
19:05:33 [Bert]
SteveZ: You say we should take things out *until* we can provice examples?
19:05:44 [Bert]
jdaggett: Posting to www-style is OK, too.
19:06:08 [Bert]
jdaggett: Would like to ask sylvaing to find where it comes from.
19:06:20 [Bert]
... No doubt came from cases in MS Office.
19:06:33 [Bert]
... can we get more info?
19:06:50 [Bert]
... The description by MS is "this is good for Thai"
19:06:57 [Bert]
... But why is it good?
19:07:12 [Bert]
fantasai: So you wan texamples in the spec. I'll take an action.
19:07:22 [Bert]
sylvaing: And I one to fine out about IE5
19:07:31 [Bert]
19:07:49 [Bert]
jdaggett: We are trying to break it down by script. That is not the ideal way.
19:07:58 [Bert]
fantasai: Typographic tradition.
19:08:07 [Bert]
jdaggett: Kashida is an example.
19:08:14 [Bert]
... Could apply to cursive in general.
19:08:23 [Bert]
... Even if it is not currently used for latin.
19:08:30 [Bert]
SteveZ: Swash charcters?
19:08:42 [Bert]
... They can go across words.
19:08:47 [Bert]
jdaggett: They extend?
19:08:51 [Bert]
SteveZ: yes
19:09:00 [Bert]
jdaggett: This is about alongating.
19:09:16 [fantasai]
19:09:46 [Bert]
ACTION fantasai: put examples of text-justify in the spec.
19:09:46 [trackbot]
Created ACTION-503 - Put examples of text-justify in the spec. [on Elika Etemad - due 2012-08-22].
19:10:19 [Bert]
ACTION sylvaing: look into history of text-justify in IE 5+
19:10:19 [trackbot]
Created ACTION-504 - Look into history of text-justify in IE 5+ [on Sylvain Galineau - due 2012-08-22].
19:11:32 [Bert]
19:11:32 [trackbot]
ISSUE-276 -- Split Text Decoration into separate module? -- raised
19:11:32 [trackbot]
19:11:47 [Bert]
jdaggett: Why needed to split?
19:11:53 [Bert]
fantasai: module is very long.
19:12:08 [Bert]
... text-deco no interaction with anything else in spec.
19:12:26 [Bert]
florian: Useful if that makes things faster. Does it here?
19:12:45 [Bert]
fantasai: Don;'t think so now. Maybe future levels may be different.
19:12:55 [Bert]
... Table of contents makes more sense.
19:13:13 [Bert]
florian: Somewhat helpful for prioritizing.
19:13:33 [Bert]
... Smaller spec easier.
19:14:43 [Bert]
jdaggett: I think the spec needs to be stronger. Take thinks to level 4.
19:14:54 [fantasai]
19:15:05 [Bert]
... This spec should be considered for what is specified and anot and push thibgs out accordingly.
19:15:17 [Bert]
... DOn't think tetx-deco needs its own spec.
19:15:30 [Bert]
SteveZ: But splitting makes it easier.
19:15:36 [Bert]
tantek: Agree.
19:15:54 [Bert]
florian: I'm happy with split if editors want it and take on editing both.
19:16:13 [Bert]
jdaggett: *AND* not new features in either part.
19:16:21 [Bert]
fantasai: Agreed. No new features planned.
19:16:52 [Bert]
... But we need to talk about one issue next.
19:17:20 [Bert]
bert: it is so hard to find in which spec a prop is defined.
19:17:24 [lstorset]
Handy CSS property index for split specs:
19:17:32 [Bert]
tantek: That is a glbal pb. Needs to be fixed.
19:17:42 [Bert]
glenn: snapshot?
19:17:51 [Bert]
fantasai: snapshot doesn't incude anything below CR.
19:18:07 [Molly]
Molly has joined #css
19:18:25 [fantasai]!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 [Bert]
RESOLVED: split text-decoration into sepearet module.
19:18:50 [Bert]
19:18:50 [trackbot]
ISSUE-275 -- constant vs. varying text-decoration positions -- raised
19:18:50 [trackbot]
19:19:18 [Bert]
19:19:18 [trackbot]
ISSUE-270 -- text-decoration-skip value for border/padding/margin -- raised
19:19:18 [trackbot]
19:19:32 [Bert]
fantasai: [explains example above]
19:19:44 [Bert]
... strange effects on hover.
19:20:17 [Bert]
... imagine you're hovering over a link, with padding
19:20:25 [Bert]
... the strike through is fragmented.
19:20:31 [Bert]
... looks really bad.
19:20:45 [Bert]
dbaron: We discussed text-decaration models a lot.
19:20:56 [Bert]
... We came up with one. Took many years to get it impleented.
19:21:12 [Bert]
... FF implemented it. Now you say we don't want thtta model.
19:21:29 [Bert]
fantasai: Use case is editor's names on drafts.
19:21:45 [Bert]
... I added padding around the links.
19:21:52 [Bert]
... That broke strike trhrough.
19:22:42 [Bert]
... Any kind of padding on inline elements will break it.
19:22:56 [Bert]
alan: padding is not content, text-decoration should not apply.
19:23:08 [Bert]
sylvaing: But underline doesn't stop under padding.
19:23:19 [sylvaing]
correction: it actually does
19:23:49 [Bert]
glazou: Say in an editor I select a paragraph, and it has modification marks, highlighted with line thrhough.
19:23:55 [Bert]
fantasai: But the para is a block.
19:24:14 [Bert]
... Issue is if ancestor is striking through an elt.
19:24:18 [Bert]
dbaron: Proposal?
19:24:37 [Bert]
fantasai: I propose keyword 'box-decoration'
19:24:45 [Bert]
dbaron: On inline elts only?
19:24:48 [Bert]
fantasai: Yes.
19:24:53 [dbaron]
(display:inline, not inline-block, etc.)
19:24:56 [jet_]
jet_ has joined #CSS
19:24:58 [Bert]
... If text-deco is pallied by ancestor
19:25:11 [Bert]
... then is is applied from margin edge to margin edge.
19:25:21 [Bert]
tantek: We had long discussions long ago.
19:25:33 [Bert]
... We all did something different with CSS2
19:25:45 [Bert]
... We settled on a model that looks reasonable.
19:25:58 [Bert]
... We had to make exceptions for blocks
19:25:59 [fantasai]
tantek^: about how box properties apply to inlines
19:26:11 [Bert]
... This seems liek ame pb. We missed an exception.
19:26:31 [Bert]
... Same case as how borders and bgs apply to boxes.
19:26:55 [Bert]
... Rather than add property, we need to fix the definition.
19:27:16 [Bert]
... We did it with borders and bg, I think we should try to do the same here.
19:27:23 [Bert]
glazou: It's only inline?
19:27:31 [Bert]
fantasai: Yes, strictly.
19:27:45 [Bert]
... Either define, or add value (or both).
19:27:53 [fantasai]
for text-decoration-skip
19:27:57 [Bert]
dbaron: We aren't yet interop on the CSS 2.1 behavior.
19:28:16 [dbaron]
dbaron: So I'm ok with it even though it's a change from 2.1.
19:28:32 [Bert]
tantek: Maybe apply an optimistic change and give authors a way to scream if it breaks pages.
19:28:45 [Bert]
... Evaluate case by case, then change default accordingly.
19:28:55 [Bert]
glazou: I can live with proposed change.
19:29:10 [Bert]
... MAkes no sens for non-inline.
19:29:30 [Bert]
fantasai: Should try to do it by default.
19:30:07 [glazou]
<br type="lunch" />
19:30:58 [leaverou]
leaverou has joined #css
19:31:16 [Bert]
dbaron: Drawing the text-dco is thus independent of the text. Draws through margins.
19:31:26 [Bert]
florian: what does it mean?
19:31:38 [Bert]
dbaron: May be detecatable in cases with nested inlines.
19:31:49 [Bert]
... E.g., with relative pos.
19:31:51 [Zakim]
Zakim has left #css
19:33:39 [Bert]
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 [dbaron]
difference between "from margin to margin" and "through inlines" is detectable with painting order, e.g., with <span padding><span relpos>text</span></span>
19:33:57 [fantasai]
Default is to draw decoration on margin/padding/border
19:34:31 [dbaron]
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]
Blatt has joined #css
19:39:29 [miketaylr]
miketaylr has joined #css
19:51:14 [Blatt1]
Blatt1 has joined #css
19:54:30 [Blatt1]
Blatt1 has left #css
19:58:53 [Blatt]
Blatt has joined #css
20:02:27 [jet_]
jet_ has joined #CSS
20:09:19 [krit]
krit has joined #css
20:13:31 [fantasai]
20:14:28 [jdaggett]
fantasai: i think daniel/tab knows the skype csswg username
20:14:34 [jdaggett]
not me
20:26:17 [achicu]
achicu has joined #css
20:28:45 [mvujovic]
mvujovic has joined #css
20:32:21 [fantasai]
ScribeNick: fantasai
20:32:33 [Zakim]
Zakim has joined #css
20:32:45 [glazou]
Zakim, make room for 3
20:32:45 [Zakim]
I don't understand 'make room for 3', glazou
20:32:55 [glazou]
Zakim, room for 3
20:32:55 [Zakim]
I don't understand 'room for 3', glazou
20:33:01 [plinss]
zakim, room for 3?
20:33:03 [Zakim]
ok, plinss; conference Team_(css)20:33Z scheduled with code 26631 (CONF1) for 60 minutes until 2133Z
20:33:51 [vhardy_]
vhardy_ has joined #css
20:34:05 [Zakim]
Team_(css)20:33Z has now started
20:34:12 [Zakim]
20:34:36 [vhardy__]
vhardy__ has joined #css
20:34:49 [glazou]
Zakim, ??P0 is me
20:34:49 [Zakim]
+glazou; got it
20:35:12 [glazou]
krit: waiting for you on the call above
20:35:15 [Zakim]
20:35:52 [krit]
20:36:09 [fantasai]
Vincent: FPWD request for filters
20:37:03 [fantasai]
krit: Are there any questions?
20:37:28 [fantasai]
krit^: Spec is a combination of predefined filter effects, SVG filter effects, and CSS shaders
20:37:45 [fantasai]
alan: SVGWG already agreed to publish
20:39:09 [fantasai]
fantasai: Last time CSSWG discussed this, we concluded we wanted several "targets" of things to filter
20:39:33 [glazou]
krit: what's your skype id ?
20:39:39 [fantasai]
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 [krit]
20:39:55 [glazou]
krit: leaving the call now
20:39:59 [Zakim]
20:40:13 [fantasai]
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]
fantasai: If not, I think that's an issue
20:40:34 [fantasai]
hober: ok with just marking that as an issue
20:40:35 [fantasai]
fantasai: sure
20:41:20 [cabanier]
fantasai: are you thinking of blending and compositing?
20:41:50 [cabanier]
fantasai: It's in there. I haven't heard of doing this for filters too (but it makes sense)
20:42:33 [fantasai]
no idea what the technical term, only that we want to be able to apply filters to each part
20:43:04 [fantasai]
fantasai: We've had requests for background-fiter, border-filter, etc-filter (replace filter with opacity, or shadow, or whatever)
20:43:19 [fantasai]
fantasai: We decided we should do this generically with filters, rather than adding a new property for each
20:43:47 [fantasai]
fantasai: So this module needs to be accommodating those requests somehow
20:43:52 [fantasai]
ACTION krit: mark this as an issue
20:43:52 [trackbot]
Sorry, couldn't find user - krit
20:44:23 [fantasai]
ACTION dschulze: mark this as an issue
20:44:24 [trackbot]
Created ACTION-505 - Mark this as an issue [on Dirk Schulze - due 2012-08-22].
20:44:34 [fantasai]
alan: Anything else?
20:45:03 [Zakim]
20:45:04 [Zakim]
Team_(css)20:33Z has ended
20:45:04 [Zakim]
Attendees were glazou, krit
20:46:08 [fantasai]
RESOLVED: Publish Filters FPWD
20:46:21 [fantasai]
Topic: Masking
20:46:46 [fantasai]
Topic: Transforms
20:46:54 [krit]
20:47:09 [fantasai]
krit: Talked about interpolation, and request for some tests
20:47:39 [fantasai]
krit: All browsers do ?
20:47:50 [fantasai]
krit: All browsers do matrix decomposing
20:47:54 [fantasai]
krit: ...
20:48:25 [krit]
20:48:26 [fantasai]
krit: Let me post a link
20:48:39 [fantasai]
krit: What I tested was browsers interpolation on rotate3d
20:48:58 [fantasai]
krit: Actually looks like all browsers do magic decomposing (matrix decomposing)
20:49:01 [fantasai]
20:49:33 [fantasai]
krit: Suggest we always to matrix decomposing
20:49:48 [dbaron]
s/Suggest/Suggest that when rotate3d() is involved/
20:49:51 [krit]
for rotate3d we always decompose with matrix
20:50:03 [krit]
thats is what all browsers do with the exception of chrome
20:50:19 [krit]
chrome does number interpolation if the roatate is arround 0,0,1
20:50:21 [krit]
20:50:22 [Koji]
Koji has joined #css
20:50:23 [krit]
or 1,00
20:51:17 [krit]
I can change the behavior of Chrome in WebKit to match all other browsers
20:51:23 [fantasai]
fantasai: Is matrix decomposition satisfactory for what users would want to do?
20:51:44 [krit]
I would expect that useres want number interpolation
20:51:54 [krit]
but that is not what browsers seem to do
20:52:18 [fantasai]
dbaron: Not that great
20:52:38 [krit]
It seems unlikely that IE10 can change the behavior
20:52:52 [krit]
it is already ready for shipping
20:54:31 [stearns]
sylvaing: current behavior is used in our app frameworks - could be tricky to change
20:54:53 [stearns]
20:55:02 [hober]
hober: i'm happy with krit's proposal on this issue
20:55:40 [sylvaing]
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]
fantasai: So do we really want to lock that in? or just consider it a bug ?
20:56:11 [krit]
A bug in browsers or implementation?
20:56:18 [fantasai]
sylvaing: It's hard for us because we use this in our app frameworks.
20:56:18 [fantasai]
fantasai: Usually the problem is switching behavior from a numeric interpolation case to a matrix decomposition one
20:56:21 [fantasai]
fantasai: Other way around I understood from last time was not so much of a problem
20:56:23 [fantasai]
TabAtkins: In first case, where everything's the same, would expect angle.
20:56:26 [fantasai]
TabAtkins: But where vectors are different, would be weird.
20:56:28 [fantasai]
TabAtkins: Even if we do numeric interpolation, interpolating the 3 args numerically is probably not what authors want.
20:56:32 [fantasai]
dbaron: I think we want numeric interpolation when the 3 components are the same
20:56:40 [fantasai]
TabAtkins: That would be minimally good
20:56:53 [fantasai]
TabAtkins: That would at least allow rotation along an axis that is not x/y/z
20:57:07 [fantasai]
dbaron: If authors want something more complicated to animate, then they have to explicitly split it up the way they want
20:57:27 [krit]
I am unsure if Safari can implement numerical interpolation for rotate3d in general
20:57:44 [fantasai]
fantasai: Seems better than matrix decomp
20:58:00 [fantasai]
TabAtkins: So question is, do we normalize the vector before comparison?
20:58:04 [fantasai]
Vincent: Don't think that'll work
20:58:16 [fantasai]
krit: Spec wants the vectors to be normalized
20:58:31 [fantasai]
krit: Safari doesn't, sticks on CoreAnimation
20:58:38 [fantasai]
krit: Can't do numeric interpolation
20:59:08 [fantasai]
sylvaing: That's their problem.
20:59:19 [fantasai]
krit: This will mean that you'll have different behavior on Safari than other browsers
20:59:37 [fantasai]
TabAtkins: Not strictly true. Safari just has to do some additional bookkeeping
20:59:41 [decadance]
decadance has joined #css
21:00:20 [fantasai]
dbaron suggests doing this on a telecon
21:00:37 [fantasai]
Proposal A: rotate3d() always uses matrix decomposition
21:01:06 [fantasai]
Proposal B: rotate3d() uses numeric interpolation when the first 3 arguments (defining the axis) match
21:01:30 [fantasai]
Proposal C: roate3d() uses numeric interpolation when the first 3 arguments (defining the axis) match *after normalizing the vector*
21:01:57 [fantasai]
A is implemented right now, but what authors will want
21:02:04 [fantasai]
is B or C
21:02:17 [hober]
RRSAgent: url?
21:02:17 [RRSAgent]
I'm logging. Sorry, nothing found for 'url'
21:02:17 [fantasai]
because otherwise can't rotate along axes other than xyz
21:02:41 [fantasai]
krit: There is no B, spec says they are normalized
21:02:43 [plinss]
rrsagent, pointer?
21:02:43 [RRSAgent]
21:02:50 [fantasai]
TabAtkins: At what stage? Does it say computed values are normalized?
21:02:55 [fantasai]
TabAtkins: If not, we can say that
21:03:17 [dbaron]
The spec says it's normalized, but doesn't say when, so it's basically meaningless.
21:03:30 [fantasai]
plinss: Only place that user would notice is when rotate takes you back where you came from?
21:03:34 [fantasai]
dbaron: No, lots of cases
21:03:46 [fantasai]
dbaron: If you decompose a 90deg rotation into 2 components, won't do exactly the same thing
21:04:03 [fantasai]
dbaron: The bigger the angular difference, the more noticeable it is
21:04:13 [fantasai]
dbaron: Past 180deg, will notice greatly because might get different direction of rotation
21:04:20 [fantasai]
dbaron: or different number of rotations.
21:04:29 [dbaron]
krit: Animating from negative vector to positive vector?
21:04:34 [dbaron]
dbaron: Just count as a mismatched vector.
21:05:34 [fantasai]
fantasai: So we're down to A or C.
21:05:45 [fantasai]
fantasai: I think we should go with C, since that's what authors will want.
21:05:50 [fantasai]
hober: Go with A, that's what's implemented
21:06:12 [fantasai]
TabAtkins: This isn't a compat issue, so we don't need to do bugwards compat
21:07:22 [fantasai]
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 [fantasai]
hober, TabAtkins: it's predictable
21:07:54 [fantasai]
TabAtkins: If the vector is the same, we interpolate otherwise not
21:08:53 [fantasai]
Vincent: We have two vectors, right, we could ... even if they don't match
21:09:12 [fantasai]
Vincent: Could do better behavior than decomposing
21:09:24 [fantasai]
plinss: That would be less surprising to the author, I think
21:09:42 [fantasai]
TabAtkins: So that would be option D, fully define interpolation
21:10:03 [fantasai]
dbaron: There are a bunch of places where you'll have to make a lot of arbitrary decisions
21:10:33 [dbaron]
dbaron: special behavior for antiparallel vectors? If so, use that behavior for any >90deg angle? What about 90deg angles?
21:10:50 [fantasai]
hober: Would be nice if Simon were here for this
21:11:14 [fantasai]
plinss: Anyone want to take an action to try to define D
21:11:28 [fantasai]
ACTION Vincent: Write a proposal for vector interpolation for rotate3d()
21:11:29 [trackbot]
Created ACTION-506 - Write a proposal for vector interpolation for rotate3d() [on Vincent Hardy - due 2012-08-22].
21:12:09 [fantasai]
plinss: anything else?
21:12:31 [fantasai]
krit: Can we publish after decision about rotate3d()?
21:12:38 [fantasai]
plinss: How far are we from LC?
21:13:13 [fantasai]
krit: Some minor issues, would also like to publish WD and ask for review before going to LC
21:13:20 [fantasai]
plinss: Asking if this is last WD before LC
21:13:48 [fantasai]
RESOLVED: Publish WD of Transforms after rotate3d() is resolved
21:14:00 [dbaron]
s/rotate3d()/rotate3d() animation/
21:14:15 [dbaron]
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 [krit]
21:14:26 [dbaron]
I think it should be just for the function.
21:14:39 [fantasai]
krit: CSSWG decided to apply masking to HTML content, SVG WG ants to work together with CSSWG
21:14:47 [fantasai]
krit: So we made FXTF draft for masking
21:14:56 [fantasai]
krit: It's a proposal that just specifies ... for browsers
21:15:10 [fantasai]
krit: We have Firefox that .. and we have Webkit that does something with masking
21:15:17 [fantasai]
krit: Specification which tries to address both proposals
21:15:26 [fantasai]
krit: Two different sets of properties
21:15:31 [fantasai]
krit: One is mask-image, similar to bg image
21:15:45 [fantasai]
krit: idea is that authors don't need to learn new syntax for it
21:15:53 [fantasai]
krit: syntax is exactly the same
21:15:58 [fantasai]
krit: behavior is same, just with masking
21:16:04 [fantasai]
krit: masking process ... filter
21:16:20 [fantasai]
krit: There's also 2nd set of properties mask-box-image
21:16:31 [fantasai]
krit: similar to border-image
21:16:32 [krit]
21:16:37 [drublic_]
drublic_ has joined #css
21:16:52 [fantasai]
krit: Does CSSWG want to go with this approach?
21:16:57 [fantasai]
krit: any concerns about this?
21:17:37 [fantasai]
fantasai: Are there use cases for all these properties?
21:17:46 [fantasai]
krit: They are quite useful, easier/ more poweful than SVG masking
21:17:51 [fantasai]
krit: So think it's very useful
21:18:11 [fantasai]
krit: ...
21:18:17 [fantasai]
krit: mask-box-image, used quite a lot
21:18:26 [fantasai]
krit: still a feature that's heavily used on mobile devices today
21:18:54 [fantasai]
fantasai: My opinion is basically if roc thinks it's a good idea, it's good
21:19:14 [fantasai]
hober: harmonizing webkit-mask with SVG is a no-brainer, should continue to work on it
21:19:28 [fantasai]
dbaron: Would like a chance for other to people look at it
21:19:49 [fantasai]
krit: roc said same thing as you, fantasai
21:20:02 [fantasai]
Vincent: Goal was to see if group thinks its a good idea to work on this
21:21:14 [fantasai]
fantasai: Think it's good to work on this, think that idea of aligning with existing properties seems smart,
21:21:41 [fantasai]
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 [fantasai]
e.g. postion should refer to definition of <position> in css3-background rather than duplicating it
21:22:28 [fantasai]
dbaron: I'm a little unsure how high priority this should be
21:22:35 [fantasai]
dbaron: There's been some stuff in webkit for awhile
21:22:45 [fantasai]
dbaron: we've had a huge a mount of pressure for TTA, but not so much for masking
21:23:20 [fantasai]
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 [fantasai]
krit: I can't disagree with that of course
21:23:39 [fantasai]
krit: We want to address this in SVGWG, so don't see how it can harm the CSSWG
21:24:05 [fantasai]
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 [dbaron]
s/TTA/transforms, transitions, and animations/
21:24:41 [fantasai]
Bert: I have two questions
21:24:52 [fantasai]
Bert: Since 'clip' has never been used, why would 'mask' be used more?
21:25:06 [fantasai]
Bert: Second, isn't this a kind of filter
21:25:18 [fantasai]
TabAtkins: We have lots of examples of -webkit-mask being used on the Web
21:25:36 [fantasai]
krit: Used a lot for images and videos
21:25:56 [fantasai]
krit: clip-mask can also be used similar to shapes in CSS exclusions
21:26:05 [fantasai]
krit: I'm fine to specify if CSSWG wants
21:26:31 [fantasai]
fantasai: Speccing something that replaces -webkit-mask with a standard feature seems like a good idea
21:27:17 [fantasai]
hober: And doing it in a way that harmonizing with SVG is good
21:27:32 [fantasai]
krit: Been in Webkit for 4 years
21:28:10 [fantasai]
Leif: Not handled by other spec?
21:28:50 [fantasai]
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 [fantasai]
Mask the filters? :)
21:29:19 [dbaron]
krit, also should say who the Editors are
21:29:29 [fantasai]
krit: In SVG, masking, then filters, then clipping is separate step
21:29:53 [fantasai]
jdaggett: Should we move on?
21:30:22 [fantasai]
Topic deferred, giving dbaron &co to ask others for feedback
21:30:43 [fantasai]
Topic: Writing Modes
21:30:51 [vhardy_]
vhardy_ has joined #css
21:31:34 [fantasai]
koji: In the end I would like one working group resolution, so would like to start from some background.
21:32:06 [fantasai]
koji: UTR50 started last August
21:32:34 [fantasai]
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 [fantasai]
koji: So after UTR50 draft 1 was done, there was a lot of feedback
21:33:08 [fantasai]
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 [fantasai]
koji: The editor, Eric, set scope to Japanese
21:33:26 [fantasai]
koji: Most feedback I saw was scope should be global rather than Japanese
21:33:42 [fantasai]
koji: Other feedback like multi-language / math expressions shoudl be handled
21:33:52 [fantasai]
koji: Some people wnat that consistency by ignoring osme legacy usage
21:34:01 [fantasai]
koji: Some people want better typogrpahy than what's used today
21:34:20 [fantasai]
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 [fantasai]
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 [fantasai]
jdaggett: To not be a combination of other properties and font information
21:35:03 [fantasai]
jdaggett: The original draft of Writing Modes had that as the defining factor of orientation
21:35:21 [fantasai]
jdaggett: The goal of UTR50 was to give us a defautl distinction, that at least set Latin sideways, and kanji upright
21:35:28 [fantasai]
jdaggett: beyond that, I don't think it's as important
21:35:32 [fantasai]
koji: Everyone agrees with that
21:35:38 [fantasai]
koji: Issues is about symbols
21:35:48 [fantasai]
jdaggett: Key point is that this thing have consistency
21:36:00 [fantasai]
jdaggett: Specifics of whether one symbols is upright/sideways is much less important
21:36:07 [fantasai]
jdaggett: Just trying to set a set of reasonable default
21:36:19 [fantasai]
jdaggett: If you're talking about math expressions in vertical text, you're off in the weeds
21:36:27 [fantasai]
jdaggett: What has come out of UTC and the mail you sent around, this is the scope
21:36:35 [fantasai]
jdaggett: That is much more confined scope, I'm fine with that
21:36:44 [fantasai]
koji: The UTC resolved to tighten the scope
21:36:53 [fantasai]
koji: Now UTR50 scope is Japanese and then East Asian
21:37:01 [fantasai]
koji: And it's goal is interchangeability rather than better typography
21:37:06 [fantasai]
koji: And to capture major use
21:37:19 [fantasai]
florian: So they won't address non-EA things?
21:37:30 [fantasai]
koji: I misunderstood at first point, but scope they mean priority
21:37:57 [fantasai]
fantasai: Scope is all of Unicode
21:38:01 [dbaron]
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 [fantasai]
koji: For that, usage in East Asia wins, and Japanese wins over that
21:38:38 [fantasai]
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 [dbaron]
Florian: ...
21:38:52 [dbaron]
jdaggett: and that's precisely why we shouldn't bikeshed on this
21:38:57 [jet]
jet has joined #CSS
21:39:31 [fantasai]
koji: Basic idea is goal of UTR50 is to interchange
21:39:42 [fantasai]
koji: For various specific applications, encouraged to tailor
21:39:57 [fantasai]
koji: So UTR50 resolved to go back or tighten the scope
21:40:14 [fantasai]
koji: means if we follow UTR50, CSS Writing Modes scope would match that of UTR50
21:40:34 [fantasai]
Florian: Question is They have changed the way they define everything, are we ok with that.
21:40:51 [fantasai]
jdaggett: As long as there's not an uproar, then it's okay
21:41:25 [dbaron]
fantasai: UTC's scope document (UTC member confidential) seemed reasonable to me
21:41:30 [dbaron]
fantasai: though one point I wanted clarified
21:42:02 [dbaron]
jdaggett: I think writing mode should just say that ... is defined by this property over here in Unicode.
21:42:16 [dbaron]
fantasai: I think we just need them to publish a draft that has known errors fixed.
21:42:54 [dbaron]
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 [dbaron]
koji: I apologize for that.
21:43:16 [dbaron]
koji: I prefer to use UTR50 as is, and I want to make sure everyone is ok with that.
21:43:20 [dbaron]
jdaggett: I think we're all fine.
21:43:29 [dbaron]
koji: UTC resolved not to do SVO for the first version.
21:43:47 [dbaron]
koji: writing mode has text-orientation: upright. Discussion about whether upright is forced or smart.
21:43:54 [dbaron]
koji: e.g., parentheses being upright
21:44:12 [dbaron]
koji: UTC had resolved to add SVO to solve that
21:44:28 [dbaron]
jdaggett: I think we should make text-orientation: upright be upright always
21:44:41 [dbaron]
jdaggett: authors who want sideways parentheses should use sideways (or mixed)
21:44:52 [dbaron]
koji: Could defer smart upright or define our own properties
21:44:58 [dbaron]
fantasai: or refer to existing draft tables.
21:45:03 [dbaron]
florian: it's an option, but we shouldn't pick it
21:45:23 [dbaron]
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 [dbaron]
florian: This kind of table can only be maintained by Unicode.
21:45:47 [dbaron]
Steve: I'd propose we either drop upright or leave it as forced upright as Koji suggested.
21:46:06 [dbaron]
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 [dbaron]
Florian: I think that's fair.
21:46:32 [dbaron]
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 [dbaron]
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 [dbaron]
fantasai: I don't see a use case where forced upright is better than upright.
21:47:09 [dbaron]
Steve: Do you want to take upright out?
21:47:17 [dbaron]
Steve: We don't have a definition of what smart upright would do.
21:47:23 [dbaron]
jdaggett: We need upright in some situations.
21:47:31 [dbaron]
jdaggett: Need to have it for making Latin upright.
21:47:59 [dbaron]
Florian: I think we're in agreement.
21:48:25 [dbaron]
fantasai: I'm not happy with upright being a forced upright, but I'm not going to override the WG.
21:48:40 [dbaron]
fantasai: I don't think there's a use in having ...
21:48:46 [dbaron]
fantasai: We could use the data that are already there.
21:49:00 [dbaron]
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 [dbaron]
jdaggett: I think smart-upright is an illusion.
21:49:26 [dbaron]
koji: UTC had some discussion on this, and they may add the value of ??? in the future.
21:49:53 [dbaron]
Bert: Can you explain difference between smart and forced?
21:50:29 [dbaron]
fantasai draws "(some-text)" in both forced and smart upright
21:50:49 [dbaron]
jdaggett: With a regular font this isn't going to work, because regular fonts don't have vertical metrics.
21:51:00 [dbaron]
fantasai: IF you have a font that has vertical metrics, or you're using capital letters...
21:51:19 [dbaron]
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 [dbaron]
jdaggett: For the set of use cases here I think that's acceptable.
21:51:37 [dbaron]
alan: esp. if you have to modify the spans individually for the lack of font metrics
21:51:47 [dbaron]
fantasai: If you don't have vertical metrics you might as well use ...
21:52:33 [dbaron]
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 [dbaron]
Peter: We're still calling the value 'upright'?
21:52:57 [dbaron]
jdaggett: If you have smart upright, then you have no way of forcing character to upright
21:53:04 [dbaron]
fantasai: You could use tate-chu-yoku.
21:53:08 [dbaron]
RESOLUTION: text-orientation:upright is a forced upright; it always means upright
21:53:53 [dbaron]
koji: Excel does forced upright up until 2007; switched to smart upright in 2007. Been doing vertical writing since 1995.
21:54:31 [dbaron]
koji: Last one is HO property is being removed from UTR50 draft 7.
21:55:12 [dbaron]
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 [dbaron]
jdaggett: The way the fonts are designed -- typically designed rotated 90 degrees.
21:55:43 [dbaron]
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 [dbaron]
Glenn: Goes back to history of Mongolian
21:56:19 [dbaron]
[discussion of history of scripts]
21:56:38 [dbaron]
jdaggett: It was never really a very important property, because it just said whether the script was Mongolian or Phags-Pa.
21:57:03 [dbaron]
Koji: Some points have different orientation of glyphs from the Unicode code chart.
21:57:20 [dbaron]
Koji: So to make visually correct orientation you have to render differently from UTR50.
21:57:33 [dbaron]
Koji: Because UTR50 reflects against code charts, and code charts and fonts don't match.
21:58:22 [dbaron]
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 [dbaron]
(before prev line) Koji: ...
21:58:45 [dbaron]
Steve: Using the horizontal metrics in vertical settings
21:59:15 [dbaron]
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 [dbaron]
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 [dbaron]
Steve: Just the way people historically made the fonts.
22:00:31 [mvujovic]
mvujovic has joined #css
22:00:33 [dbaron]
Bert: schedule?
22:00:40 [dbaron]
jdaggett: I think the draft needs cleanup first.
22:00:48 [dbaron]
fantasai: Also need to wait for UTR50 to publish an update.
22:00:59 [dbaron]
Steve: As long as it's in something equivalent to last call or one step away from...
22:01:10 [achicu]
achicu has joined #css
22:01:15 [dbaron]
jdaggett: First we need a WD that just says [...]
22:01:26 [dbaron]
jdaggett: The ED right now points at a fictitious property.
22:01:46 [dbaron]
Bert: What schedule do we expect? LC soon?
22:01:54 [dbaron]
jdaggett: Depends on edits Koji makes in Unicode.
22:02:18 [dbaron]
jdaggett: ... incorporates changes that have been discussed. Draft 7 will. Expect to publish next UTC (November).
22:02:22 [dbaron]
22:02:40 [dbaron]
koji: UTC has public review period after the draft. If people agree with it, could go quickly.
22:03:04 [dbaron]
jdaggett: First step is to get a WD that says ...
22:03:17 [dbaron]
fantasai: Other thing we were blocked on was an objection from Glenn on the naming of the logical directions.
22:03:38 [dbaron]
Glenn: before/after vs. head/foot
22:03:51 [dbaron]
Steve: Glenn made one objection, Murakami-san made one, I'm unhappy (but only unhappy)
22:04:10 [dbaron]
jdaggett: Can we put an issue in the spec labeling this as an objection?
22:04:25 [dbaron]
GLenn: Don't want to block this; I'm in the unhappy category.
22:04:33 [dbaron]
Glenn: Some concern about cultural notion of head and foot.
22:04:38 [dbaron]
jdaggett: Why can't we mark this as an issue?
22:04:47 [dbaron]
jdaggett: shouldn't block this as a WD
22:04:53 [dbaron]
[agreement, it seems]
22:05:05 [dbaron]
[desire to resolve before LC]
22:05:24 [dbaron]
Steve: Are people willing to reconsider this or should we go away and give up?
22:05:38 [dbaron]
Florian: I'd prefer not to reconsider.
22:05:46 [dbaron]
Peter: I'd prefer not to discuss discussing it right now.
22:06:02 [dbaron]
Peter: We'll rename it before we go to last call. :-)
22:06:23 [dbaron]
Topic: Lists
22:06:30 [fantasai]
ScribeNick: fantasai
22:06:41 [fantasai]
TabAtkins: There are two issues to talk about
22:06:53 [fantasai]
TabAtkins: This has been sitting in WD because nobody has reviewed the draft yet
22:06:57 [fantasai]
TabAtkins: Would like to advance the spec
22:07:05 [fantasai]
TabAtkins: Otherwise I'll request LC
22:07:15 [fantasai]
TabAtkins: In simplest case, marker positions are same
22:07:26 [fantasai]
TabAtkins: Outside that, all implementations have different ideas of how markers are positioned
22:07:38 [fantasai]
TabAtkins: spec is similar to what IE does, because that was sanest
22:07:47 [fantasai]
Rossen: 3 years ago looked at it
22:08:04 [fantasai]
Rossen: We spent a ton of time looking at list markesr and looked at all the different implementations
22:08:16 [fantasai]
Rossen: As soon as you have anything other than simplest possible text with marker inside, all hell broke loose
22:08:37 [fantasai]
dbaron: There's a section called marker positoining, but nowhere near long enough to cover all this
22:08:52 [fantasai]
TabAtkins: Split across marker position and marker attachment
22:09:04 [fantasai]
TabAtkins: Actual definition in Ch 7
22:09:20 [fantasai]
TabAtkins: 7.1 defines behavior in terms of terms, and what that means.. then defined in ... right there
22:09:33 [dbaron]
22:10:03 [fantasai]
TabAtkins: If it's incomplete, please give me feedback. Correct me on anything that's wrong.
22:10:15 [fantasai]
TabAtkins: Counter handling. Everybody is pretty sane on this
22:10:23 [fantasai]
TabAtkins: Tried to tighten up definitions in the spec
22:10:37 [fantasai]
TabAtkins: Added the counter-set property, equivalent to counter-reset, except doesn't create a new scope
22:10:47 [fantasai]
TabAtkins: This is required if you want to implement HTML's value attribute in terms of CSS
22:11:02 [fantasai]
TabAtkins: same as counter-increment, just sets to explicit value intead
22:11:52 [fantasai]
TabAtkins discusses some weird case
22:12:07 [fantasai]
TabAtkins: I defined the ::marker pseudo-element
22:12:13 [fantasai]
TabAtkins: So you can style it, e.g. color the marker
22:12:26 [fantasai]
TabAtkins: Can be done right now with hacks and markup tweaks, rather annoying to do
22:13:05 [fantasai]
TabAtkins: marker-attachment property, was put in at request of bidi requirements groups
22:13:22 [fantasai]
TabAtkins: To address the problem of list markers appearing on the wrong side
22:13:45 [fantasai]
dbaron: I think this is a bad name
22:14:58 [fantasai]
TabAtkins explains the use case
22:15:25 [fantasai]
dbaron: We had a really long discussion about this at a TPAC
22:15:41 [arno]
arno has joined #css
22:16:20 [fantasai]
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 [fantasai]
dbaron: maybe 'marker-side' or 'marker-direction'
22:16:43 [fantasai]
Rossen: If it's an arrow, if it points to the left or the right? :)
22:17:40 [fantasai]
plinss asks about marker direction of contents
22:17:57 [fantasai]
TabAtkins: Last thing is inline list items
22:18:05 [jarek]
jarek has joined #css
22:18:08 [fantasai]
dbaron: Does it support list-style-position: outside
22:18:20 [fantasai]
TabAtkins: Hm, probably should
22:18:36 [fantasai]
TabAtkins: Ok, those were changes that need review
22:18:44 [fantasai]
TabAtkins: Let's start with one jdaggett is pacing about
22:18:51 [fantasai]
TabAtkins: Which is the question of user-defined identifiers
22:18:59 [fantasai]
TabAtkins: Do we preserve the case of user-defined idents?
22:19:06 [fantasai]
TabAtkins: ASCII case-fold?
22:19:09 [fantasai]
TabAtkins: ..
22:19:19 [fantasai]
22:20:40 [stearns]
jdaggett: we should design a simple system
22:20:53 [stearns]
jdaggett: this is not very important
22:21:06 [stearns]
jdaggett: CSS is otherwise case-insensitive
22:21:09 [fantasai]
TabAtkins: Interesting thing here is that @counter-style lets you redefine idents, including case-insensitive ones in CSS2.1
22:21:29 [fantasai]
jdaggett: users expect it to be case-insensitive
22:21:45 [fantasai]
TabAtkins: So proposal is to make them case-insensitive, figure out which kind it is
22:22:02 [fantasai]
jdaggett: Not always the best ways, but define something simple
22:22:14 [fantasai]
jdaggett: for where handled within itself
22:22:23 [fantasai]
Florian: Seems reasonable, but what do you do on the OM side of things?
22:22:49 [fantasai]
Florian: Does the OM output the saem case as input or lowercase or what?
22:23:02 [fantasai]
TabAtkins: Just do whatever OM does for idents
22:23:36 [fantasai]
fantasai: What idents do depends on whether it's a predefined keyword or not
22:24:21 [fantasai]
jdaggett: There are user idents in @font-feature rules
22:24:37 [fantasai]
Florian: From an author point of view, jdaggett's proposal is best.
22:24:48 [fantasai]
Florian: Question is if we will get this right on implementation side
22:25:23 [fantasai]
dbaron: What is jdaggett proposing?
22:25:35 [fantasai]
fantasai: Unicode lowercasing
22:25:55 [fantasai]
dbaron: In some cases where there are user-defined idents, we want a mechanism for fast comparison
22:25:59 [fantasai]
dbaron: such as atomization
22:26:21 [fantasai]
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 [fantasai]
dbaron: some unicode case comparisons that don't give you that
22:26:27 [smfr]
animation keyframes use user idents too, which are exposed to JS via animation events
22:26:40 [fantasai]
jdaggett: You might be thinking of full case mapping
22:26:46 [fantasai]
jdaggett: Unicode has simple case mapping and full case mapping
22:27:08 [fantasai]
jdaggett: full case mapping doesn't preserve lenght of a string, e.g. eszet will become double capital S
22:27:26 [fantasai]
jdaggett: There's also a simple set that preserves length of string
22:28:25 [fantasai]
fantasai raises issue of lowercasing, uppercasing, case-folding
22:28:41 [drublic]
drublic has joined #css
22:28:43 [fantasai]
ACTION jdaggett: propose case-comparison proposal
22:28:43 [trackbot]
Created ACTION-507 - Propose case-comparison proposal [on John Daggett - due 2012-08-22].
22:29:10 [fantasai]
TabAtkins: Should we resolve on ASCII-case-insensitivity
22:29:26 [fantasai]
jdaggett: Uncertain about that
22:29:42 [fantasai]
TabAtkins: It's in the platform, HTML has it in a number of places too
22:29:49 [fantasai]
Bert: Agree with jdaggett that it's a weird thing
22:29:56 [mvujovic]
mvujovic has joined #css
22:30:02 [fantasai]
TabAkins: I'm concerned about going back to case-sensitive
22:30:19 [fantasai]
plinss: So we're proposing to make idents case-insensitive in a form TBD
22:30:27 [fantasai]
dbaron: I'd also like to resolve that the form will support atomization
22:30:52 [fantasai]
dbaron: There has to be some conversion you can do once, such that you can do atomization
22:31:00 [fantasai]
fantasai: I think that's true for all of the casing optimizations.
22:31:09 [fantasai]
fantasai: You just can't do round-tripping.
22:31:18 [fantasai]
plinss: What about Unicode normalization?
22:32:09 [fantasai]
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 [fantasai]
jdaggett: then they will not match
22:32:26 [fantasai]
dbaron: If we want to fix that, then we want to normalize the whole sheet as parse time
22:32:40 [fantasai]
TabAtkins: I don't think you can avoid perf problems without doing that.
22:32:51 [fantasai]
dbaron: You have to do it in so many different places.
22:33:31 [fantasai]
dbaron: Unless you can test this for everything
22:33:55 [fantasai]
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]
fantasai: So I don't think we can do normalization until we have a normalization form that works.
22:35:41 [fantasai]
plinss: That's valid feedback to i18n
22:36:19 [fantasai]
plinss: This issue keeps coming up
22:36:24 [Zakim]
Zakim has left #css
22:36:55 [fantasai]
RESOLVED: user-idents in CSS are case-insensitive, insensitivity of a type TBD
22:37:20 [dbaron]
... but where the type of case comparison allows for atomization and hashing via a single up-front conversion
22:38:08 [fantasai]
Topic: Counter Styles
22:38:46 [fantasai]
fantasai: Previous discussion was to have counter styles in a different document
22:39:09 [fantasai]
fantasai: Proposal is to put @counter-style with them
22:39:49 [fantasai]
Florian: Point of splitting was to not put the counter styles list on the REC track
22:40:10 [dbaron]
The definition of Caseless Matching (Case Folding) in Unicode 6.0 section 5.18 actually seems like it would be ok.
22:40:21 [Bert]
scribe: Bert
22:40:53 [Bert]
fantasai: Definitions of all counter styles in 2.1 make a good module.
22:41:06 [Bert]
... Finsihed and complete, after case-insens inssue.
22:41:16 [Bert]
... All the rest deals with a lot of things, not near LC
22:41:23 [Bert]
... It is holding up counter style
22:41:41 [Bert]
... So we might as well give it is own title
22:41:55 [Bert]
jdaggett: As bare minimum ou need to [???]
22:42:05 [Bert]
... Splitteing counter-style
22:42:14 [stearns]
s/???/address OM/
22:42:23 [Bert]
TabAtkins_: Takes 5 mins to define.
22:42:43 [Bert]
... As soon as I have a checkout of the tetx.
22:43:16 [Bert]
florian: jdaggett has an opinion, but not as strong as whether or not to define long list of counter styles normatively.
22:43:30 [Bert]
... We should on defining that long list.
22:43:34 [Bert]
... I vote for not.
22:43:46 [Bert]
glenn: define whats in 2.1 and thats it.
22:43:54 [Bert]
fantasai: Do't want to limit ot 2.1
22:44:13 [Bert]
... The criteria for 2.1 where basically what bert and howcome knew about.
22:44:31 [Bert]
tantek: Will fantasai draw up ciriteria?
22:44:48 [Bert]
dbaron: We shoukd have a def for the 2.1 one, Everyone impls them.
22:44:55 [dbaron]
all the 2.0 ones
22:45:02 [dbaron]
some of which were dropped from 2.1
22:45:02 [Bert]
glenn: Want to focus on 2.1, want to see a proposal.
22:45:23 [Bert]
fantasai: Want to see how hard it is for author to come with a style.
22:45:30 [Bert]
... If it is hard, we should prefedine
22:45:40 [Bert]
... Khmer might be easy for an author.
22:45:45 [Bert]
... CJK is not easy.
22:46:01 [Bert]
glenn: mapping between numbers anbd symbols and then author can work it out.
22:46:08 [Bert]
fantasai: hat's what were talking about
22:46:17 [Bert]
jdaggett: Multiple ways of doing it.
22:46:44 [dbaron]
22:46:49 [dbaron]
has a bunch that are not in 2.1
22:47:10 [Bert]
TabAtkins_: Should not define a common resource. W3C would not host it.
22:47:34 [Bert]
glenn: rathole to define what is significnt or not, base don community size, e.g
22:47:53 [Bert]
jdaggett: We do 't know what the quality is of the definitions we have.
22:48:00 [Bert]
... Should be a community effort.
22:48:23 [Bert]
plinss: You say (1) we cannot define it, (2) it is a quality issue.
22:48:52 [jarek_]
jarek_ has joined #css
22:49:16 [Bert]
jdaggett: We cannot judge the quality. Who can jusge the Khmer numbering here?
22:49:30 [Bert]
glenn: I was there and I talked with the government there.
22:49:44 [Bert]
florian: We should draw a line somewhere.
22:50:09 [stearns]
s/I talked with/would not accept a proposal unless it came from/
22:50:26 [Bert]
tantek: jdaggett is asking for community. Community provides examples, test cases, etc. We can check them.
22:50:33 [Bert]
jdaggett: We cannot check them.
22:50:46 [Bert]
plinss: You aregue ther eis npublic review.
22:50:57 [Bert]
florian: Toss it out to specialized group.
22:51:17 [Bert]
SteveZ: Why doesn;'t the wikipedia solution work here? Put it out,
22:51:24 [Bert]
... Leave the community to get it right.
22:51:33 [Bert]
... *We* are not going to get it right.
22:51:41 [Bert]
TabAtkins_: OK
22:51:49 [Bert]
fantasai: I'd like a counter style smodule
22:51:57 [Bert]
... That defines 2.0 and 2.1 styles.
22:52:10 [Bert]
... And has informative appendix with the other currently in the draft.
22:52:19 [Bert]
some people: no
22:52:28 [Bert]
plinss: [missed]
22:52:37 [Bert]
tantek: We have a wiki. Propose it there.
22:52:48 [Bert]
... If the community steps up, that's great. If not, too bad.
22:53:25 [Bert]
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 [Bert]
florian: You don't.
22:53:50 [Bert]
... Authors copy it it to their own style sheets.
22:54:07 [Bert]
SteveZ: Knowing what we know, we would have creatred a registry.
22:54:25 [Bert]
dbaron: here is the set in 2.0, I think all implemented in browsers.
22:54:40 [Bert]
... One value got split in current draft, because of multiple interpretations.
22:54:48 [Bert]
... CJK ideographic.
22:54:54 [Bert]
... Split into 6 values.
22:55:17 [Bert]
fantasai: Complication with that one is that an author is not going to come up with that on hois own.
22:55:25 [Bert]
... Those should be in the required set of built-ins.
22:55:44 [Bert]
dbaron: I think the required set should be the 2.0/2.1 set plus these 6.
22:56:01 [Bert]
plinss: 2.0 is not the justification, it is just our source.
22:56:14 [Bert]
tantek: What is already implemented is the justification.
22:56:24 [Bert]
dbaron: It is sane and not a big addition.
22:56:35 [Bert]
glenn: 2.1 list is enough for me.
22:56:45 [Bert]
... Everything else, incl 2.0, in a registry.
22:56:57 [Bert]
dbaron: Don't kick out if it is implemented cross-browser.
22:57:18 [Bert]
[discussion about what FF supports]
22:57:44 [Bert]
florian: I can live with dbaron proposal. Not further than that.
22:57:53 [Bert]
TabAtkins_: Everything else goes into registry on wiki.
22:58:00 [Bert]
sylvaing: test cases?
22:58:13 [Bert]
dbaron: I think I submitted some. May have been removed since.
22:58:25 [Bert]
sylvaing: If no 2 impls, we can remove.
22:58:35 [Bert]
... Strat with that, everything goes to wiki.
22:58:45 [Bert]
TabAtkins_: TEsting is easy, generate a 1000 numbers.
23:00:20 [Bert]
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 [Bert]
[discussion about origin of six-way split of cjk ideographic]
23:01:11 [Bert]
florian: Mark 6-way split at risk?
23:01:24 [Bert]
dbaron: Agreed.
23:01:53 [Bert]
RESOLVED: {cont'd) and mark 6-way split at risk.
23:02:17 [Bert]
glenn: I object to 6-way split. At risk is OK.
23:04:54 [arno]
arno has joined #css
23:07:14 [jarek]
jarek has joined #css
23:21:10 [fantasai]
Topic: Editorship
23:21:17 [fantasai]
Alan: Propos krit as editor on Filter effects
23:21:23 [fantasai]
RESOLVED: krit as editor on Filter effects
23:21:26 [fantasai]
Topic: Sticky Positioning
23:21:55 [jet]
jet has joined #CSS
23:21:58 [fantasai]
hober: I posted to www-style a proposal for adding a new position value
23:22:05 [fantasai]
hober: called 'sticky'
23:22:10 [fantasai]
hober: similar to relpos
23:22:31 [fantasai]
fantasai: It's like a combination of relpos and fixedpos that actually works
23:24:54 [Koji]
Koji has joined #css
23:26:04 [fantasai]
hober: It's in-flow like relpos
23:26:14 [fantasai]
hober: but the calculation of the offset is based on the intersection of the veiwport and the containing block
23:26:26 [fantasai]
hober: common use cases are, e.g. sidebar in a web page
23:26:42 [fantasai]
hober demonstrates
23:26:55 [fantasai]
hober: This sort of thing is really common on the Web, using scroll events to emulate with JS
23:27:14 [fantasai]
hober: All just a single new position value
23:27:26 [fantasai]
hober: footer and header of table are always visible in viewport
23:27:49 [fantasai]
hober shows address book that works like iPhone address book headers
23:28:25 [fantasai]
plinss asks about a case of header and footer overlap
23:28:42 [fantasai]
hober: So I think it might be worth, in the longer term, adding a property for handling collisions
23:28:49 [fantasai]
hober: complicated if doing in multiple dimensions
23:28:57 [fantasai]
by default would overlap
23:29:03 [fantasai]
hober: Looking for resolution to pursue the feature
23:29:23 [fantasai]
szilles: How does it behave for print?
23:29:31 [fantasai]
fantasai: would be same as relpos
23:29:46 [dbaron]
[5 conversations at once]
23:29:58 [fantasai]
glazou: I think it's not that easy to specify
23:30:03 [fantasai]
hober: I'll take an action to write a description
23:30:10 [fantasai]
szilles: If I don't have scrolling it doesn't move
23:31:01 [dbaron]
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 [fantasai]
plinss^: why not print on every page
23:31:27 [fantasai]
glazou: If I can describe it this was included in the P language
23:31:50 [fantasai]
glazou: mechanism similar to pseudo-elements, you could select any element, such as viewport
23:32:08 [fantasai]
glazou: then had an element, and on that you could say "min-y: 0" inside the viewport
23:32:21 [fantasai]
glazou: meant element was always visible or invisible
23:32:35 [fantasai]
hober: Common design pattern, ppl emulate a lot with JS
23:32:45 [fantasai]
hober: But scrolling has gotten strange as time has gone on, so increasingly problematic
23:33:30 [fantasai]
Rossen: One question I have, new value is that the behavior is not applicable or useful for position: absolute
23:33:38 [arronei]
sticky, real world use case:
23:33:40 [fantasai]
hober: yes
23:33:48 [smfr]
arronei: sidebar
23:34:08 [fantasai]
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 [fantasai]
plinss: Suggest considering abspos version of this
23:35:28 [fantasai]
Bert: Seems you might want sticky differently in horizontal and vertical dimensions
23:35:54 [fantasai]
hober: Suppose you had a wide table, not so tall
23:36:18 [fantasai]
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 [fantasai]
hober: is it the nearest scrollable ancestor that you stick to?
23:36:44 [fantasai]
hober: do you have same decision in both dimensions?
23:36:48 [arno]
arno has joined #css
23:36:49 [fantasai]
hober: worth thinking about
23:37:08 [fantasai]
plinss: Think proposal is for hober to write something up for css3-positioning
23:37:22 [fantasai]
plinss: would you co-edit?
23:37:23 [fantasai]
hober: either way
23:37:28 [arronei]
hober: add the proposal to
23:37:31 [fantasai]
glazou: Suppose green is the viewport
23:38:02 [fantasai]
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 [Rossen]
smfr, an example is running shopping cart totals positioned to left/right of forms
23:38:25 [fantasai]
glazou: with collision could you get them to stack?
23:38:27 [fantasai]
overlap by default
23:38:39 [fantasai]
hober: I think overlapping by default is the right behavior here, could reus collision later
23:38:49 [fantasai]
hober: also question of percentage values, at what distance do you start sticking
23:39:03 [smfr]
stacking gets hard; you end up with a float-like algorithm
23:39:22 [dbaron]
I'm not convinced that reusing this same collision avoidance mechanism is the right thing.
23:39:26 [fantasai]
Topic: Animations
23:40:17 [sylvaing]
23:40:30 [fantasai]
sylvaing: This describes list of issues we had at last F2F
23:40:41 [fantasai]
sylvaing: some things fixed already
23:40:57 [fantasai]
sylvaing: hopefully reach LC at TPAC or before
23:41:05 [fantasai]
sylvaing: couple left over from Hamburg
23:41:09 [fantasai]
sylvaing: where in cascade do images go?
23:41:23 [fantasai]
sylvaing: I believe dbaron described what Gecko was doing
23:41:38 [fantasai]
sylvaing: The emerging consensus was that transitions would happen at the very end
23:41:51 [fantasai]
sylvaing: you would go from current animation value to the trnasition end, but never really resolved on it
23:42:00 [sylvaing]
23:42:07 [sylvaing]
23:42:19 [fantasai]
sylvaing: we discussed this part
23:42:21 [smfr]
23:42:27 [fantasai]
sylvaing: here's gecko's cascade
23:42:30 [fantasai]
sylvaing: we never resolved that
23:42:40 [fantasai]
sylvaing: I haven't checked recent webkit, but they used to have .. at the bottom
23:42:57 [fantasai]
sylvaing: in Gecko transitions are more important than animations
23:43:19 [fantasai]
dbaron: Except we would start a transition during an animation?
23:43:36 [smfr]
webkit still applies animations after everything else
23:43:39 [fantasai]
dbaron: starting a transition happens when we detect a computed value change that was not caused by an animation
23:43:47 [fantasai]
dbaron: the restyling operation..
23:43:57 [fantasai]
dbaron: The before and after styles are different in the no-animation case
23:44:10 [fantasai]
dbaron: I'm trying to remember what's the difference...
23:44:17 [fantasai]
23:44:34 [fantasai]
sylvaing: Other implementations don't let user !important and UA !important override animations. I think we do want that
23:44:39 [fantasai]
dbaron: I think we do want that.
23:44:51 [fantasai]
dbaron: Questio nis whether we want them under the other !important rules
23:45:46 [fantasai]
sylvaing: so any opinions?
23:45:56 [fantasai]
Florian: I remember having an opinion, but don't remember what it was
23:46:21 [fantasai]
fantasai: What are the options?
23:46:49 [fantasai]
sylvaing: Option A, animations are higher than UA and author !important rules
23:46:58 [fantasai]
sylvaing: Gecko allows them to override
23:47:29 [fantasai]
dbaron: Another option would be to put animations here, between author normal an dauthor override
23:47:42 [fantasai]
fantasai: Where would scoped style fit in with that?
23:48:26 [fantasai]
dbaron: Author override and scoped would be a group
23:48:48 [fantasai]
dbaron: Question would be whether animations would go before the !important rules, or after them
23:49:20 [fantasai]
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]
fantasai: I think having animations override user/UA !imporant rules it's not a good idea
23:50:48 [fantasai]
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 [fantasai]
sylvaing: so user rules could start them, but that's just about it
23:51:14 [fantasai]
glazou: I'm using them in BlueGryffon to prevent animations to run
23:51:45 [fantasai]
dbaron: Use case: user wants to override colors, but is fine with animations causing movement
23:53:12 [fantasai]
RESOLVED: Animations are below user !important rules, not above them. [still discussing whether below or above author !important]
23:53:47 [fantasai]
fantasai: So remaining question is whether author !important override animations or not
23:54:41 [glazou]
glazou: yes I think both User and Author !important should override animations
23:55:34 [fantasai]
RESOLVED: Animations override all normal rules, but are overridden by all !important rules.
23:56:24 [fantasai]
RESOLVED: Transitions happen last in the cascade
23:56:42 [sylvaing]
23:57:09 [fantasai]
sylvaing: snapshotting of values at the start of animation, action on smfr and dbaron on which properties snapshot or not
23:57:15 [fantasai]
sylvaing: talk about that yet?
23:57:18 [fantasai]
dbaron: not yet, no
23:58:28 [fantasai]
sylvaing: Raised by ...
23:58:37 [fantasai]
sylvaing: afaict not used
23:58:41 [fantasai]
dbaron: Yes, let's remove them
23:59:03 [fantasai]
RESOLVED: Remove initAnimationEvent method
23:59:26 [fantasai]
sylvaing: need to define a constructor
00:00:01 [sylvaing]
00:00:17 [fantasai]
sylvaing: Spec doesn't specify starting frmae / ending frame, spec defines generating them but doesn't define when ...
00:00:33 [fantasai]
dbaron: I believe we update it dynamically
00:00:42 [fantasai]
sylvaing: at some point you have your first frame, and others follow.
00:00:48 [fantasai]
dbaron: You're animating from that to some other pont
00:01:04 [fantasai]
dbaron: if there's a style change that changes here, you're following this line instead of this line
00:01:13 [fantasai]
Florian: You put a transition for the adjustment being smooth?
00:01:16 [fantasai]
dbaron: Yes, maybe?
00:01:37 [fantasai]
sylvaing: I think we do it static at the moment. Think Webkit does too
00:02:09 [fantasai]
hober: Should be snapshotting after delay
00:02:15 [fantasai]
sylvaing: but compute first frame, last frame
00:02:24 [fantasai]
sylvaing: we didn't have a use case for dynamic case
00:02:38 [fantasai]
dbaron: My worry about dynamic case is mostly style changes that are nearly sequential
00:02:50 [fantasai]
dbaron: Because it'll expose when browsers coalesce things or not
00:02:56 [jdaggett]
jdaggett has joined #css
00:02:56 [fantasai]
dbaron: Would like to minimize how much that's exposed
00:03:01 [leaverou_]
leaverou_ has joined #css
00:04:16 [fantasai]
sylvaing: Is that related to issue of which properties to snapshot?
00:04:25 [fantasai]
dbaron: testcases with a 5s delay are annoying
00:05:23 [fantasai]
dbaron: If I move th emouse into it while animating, it jumps to other position while animating
00:05:30 [fantasai]
sylvaing: Shouldn't this relate to general snapshotting issue?
00:05:34 [fantasai]
sylvaing: ok, think it's the same bug
00:06:23 [sylvaing]
00:07:09 [fantasai]
sylvaing: I don't understand how you get an invalid rule here
00:07:15 [smfr]
00:08:14 [fantasai]
sylvaing: Have a few more edits, then ask for new WD
00:09:58 [fantasai]
RESOLVED: Publish updated WD with those edits
00:10:26 [fantasai]
sylvaing: Aiming for LC at TPAC or before
00:11:57 [fantasai]
Topic: Scientific Notation
00:12:54 [fantasai]
TabAtkins: Required for SVG.
00:13:12 [fantasai]
dbaron: Unitless lengths and scientific notation are allowed in SVG attributes.
00:13:41 [fantasai]
TabAtkins: One use is to align with SVG
00:13:51 [fantasai]
TabAtkins: Other is it's useful in transformation matrices
00:14:25 [fantasai]
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 [dbaron]
8.574e-21parsec == 1px
00:14:50 [fantasai]
Florian: I will not object to scinot, but I'm not interested in it
00:15:17 [fantasai]
plinss: Any objections to adding scientific notation?
00:15:20 [fantasai]
Bert: Yes.
00:15:47 [fantasai]
Bert: I'm not happy with what we add, we don't have anything left for normal people.
00:16:22 [fantasai]
hober: Tab has two use cases
00:16:30 [fantasai]
hober: I don't consider them incredibly important, but they're reasonable.
00:16:45 [fantasai]
fantasai: I defer to dbaron.
00:16:54 [fantasai]
dbaron: I'm against it, but I'm not going to object.
00:17:01 [fantasai]
fantasai: That's my opinion.
00:17:06 [fantasai]
szilles: I'm not opposed, I'm not for
00:17:18 [fantasai]
alan: I think rationalizing things with SVG seems reasonable to do
00:17:28 [fantasai]
szilles: Useful, but not critical.
00:18:11 [fantasai]
Florian: which definition of scinot is this?
00:18:37 [fantasai]
Tab: Same as SVG. Number e integer
00:18:50 [fantasai]
Florian: How does this interact with minimum you're supposed to support
00:19:21 [fantasai]
TabAtkins: Turns into equivalent number
00:19:35 [fantasai]
dbaron: scinot is not valid in integers, only valid in numbers
00:19:45 [fantasai]
dbaron: Don't want to deal with scinot in integers
00:20:45 [fantasai]
TabAtkins quotes his spec text
00:21:28 [fantasai]
dbaron and TabAtkins discuss parsing problems
00:21:38 [fantasai]
and floats
00:21:43 [fantasai]
hober: Just force it to be a number
00:22:06 [fantasai]
00:22:24 [fantasai]
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 [fantasai]
Florian: Since you don't care either way, when we're specifying precision of support, shouldn't require ... cancel out
00:23:04 [fantasai]
TabAtkins: So you're allowed to do truncation as you're parsing
00:23:28 [fantasai]
dbaron: SVG's integer type does not accept scinot
00:23:34 [dbaron] says <integer> doesn't take scientific notation and <number> does
00:23:58 [fantasai]
proposal: scinot for <number>, allow range-checking based on parse time as well as interpretation-time limits
00:25:20 [fantasai]
straw poll -> no consensus
00:25:34 [fantasai]
Straw poll again, more formally
00:25:36 [fantasai]
glazou: yes
00:25:39 [fantasai]
bert: NO
00:25:42 [fantasai]
koji: abstain
00:25:44 [fantasai]
szilles: yes
00:25:48 [jdaggett]
jdaggett: no
00:25:55 [fantasai]
glenn: yes
00:26:00 [fantasai]
hober: abstain abstain
00:26:04 [fantasai]
alan: yes
00:26:12 [fantasai]
fantasai: defer to dbaron
00:26:15 [fantasai]
tantek: defer to dbaron
00:26:16 [dbaron]
dbaron: no, but not objecting
00:26:17 [fantasai]
Tab: yes
00:26:21 [smfr]
00:26:24 [fantasai]
Florian: abstain
00:26:32 [fantasai]
leif: why not, yes
00:26:35 [fantasai]
plinss: yes
00:27:03 [fantasai]
"Simon says"
00:27:11 [smfr]
00:28:31 [fantasai]
Bert: Not really fair to ask every F2F until not enough around
00:28:34 [fantasai]
who disagree
00:29:15 [fantasai]
5 no, 8 yes
00:29:30 [fantasai]
RESOLVED: add scinot to CSS
00:29:50 [fantasai]
Topic: text-size-adjust
00:30:00 [fantasai]
dbaron: Don't know what there is to discuss...
00:30:07 [fantasai]
tantek: Question is about going to FPWD
00:30:11 [fantasai]
dbaron: Think I'd rather not.
00:30:14 [dbaron]
with the ED as is
00:30:14 [fantasai]
Meeting closed.
00:30:30 [jdaggett]
but it's just 5:30?
00:31:42 [stearns]
text-size-adjust shut the whole thing down
00:33:14 [smfr]
smfr has left #css
00:35:11 [glazou]
glazou has joined #css
00:46:16 [glenn]
glenn has joined #css
00:50:43 [arno]
arno has joined #css
02:35:21 [achicu]
achicu has joined #css
02:35:31 [achicu]
achicu has left #css
03:14:57 [dbaron]
dbaron has joined #css
03:30:27 [shepazu]
shepazu has joined #css
04:06:03 [leaverou]
leaverou has joined #css
05:02:23 [dholbert]
dholbert has joined #css
05:22:38 [dbaron]
dbaron has joined #css
05:32:46 [fantasai]
fantasai has joined #css
05:33:00 [macpherson]
macpherson has joined #css
05:33:31 [hober]
hober has joined #css
05:33:55 [dholbert]
dholbert has joined #css
05:33:55 [plinss]
plinss has joined #css
05:34:00 [stearns]
stearns has joined #css
05:34:11 [paul___irish]
paul___irish has joined #css
05:34:20 [logbot]
logbot has joined #css
05:34:24 [heycam]
heycam has joined #css
05:35:03 [CSSWG_LogBot]
CSSWG_LogBot has joined #css
05:35:11 [gsnedders]
gsnedders has joined #css
05:35:12 [shans_away]
shans_away has joined #css
05:35:12 [glazou]
glazou has joined #css
05:35:31 [sylvaing_away]
sylvaing_away has joined #css
05:36:01 [vhardy_away]
vhardy_away has joined #css
05:36:31 [alexmog_away]
alexmog_away has joined #css
06:39:34 [leaverou]
leaverou has joined #css
06:42:43 [Ms2ger]
Ms2ger has joined #css
06:42:46 [jet]
jet has joined #CSS
07:00:34 [leaverou]
leaverou has joined #css
08:16:57 [tantek]
tantek has joined #css
08:20:13 [tantek]
tantek has joined #css
09:01:27 [drublic]
drublic has joined #css
09:27:28 [SimonSapin]
SimonSapin has joined #css
10:11:38 [karl]
karl has joined #css
12:51:00 [miketaylr]
miketaylr has joined #css
14:29:38 [krit]
krit has joined #css
14:33:30 [glenn]
glenn has joined #css
14:34:51 [ksweeney]
ksweeney has joined #css
14:36:32 [ksweeney]
ksweeney has left #css
14:41:44 [dbaron]
dbaron has joined #css
14:59:21 [jet]
jet has joined #CSS
14:59:45 [myakura]
myakura has joined #css
15:25:58 [jet_]
jet_ has joined #CSS
15:39:55 [drublic_]
drublic_ has joined #css
15:51:25 [drublic]
drublic has joined #css
15:59:40 [cabanier]
cabanier has joined #css
16:05:14 [jet]
jet has joined #CSS
16:08:49 [shepazu]
shepazu has joined #css
16:14:17 [jet]
jet has joined #CSS
16:46:57 [Rossen]
Rossen has joined #css
16:53:59 [dbaron]
dbaron has joined #css
17:44:04 [arno]
arno has joined #css
18:06:14 [jet]
jet has joined #CSS
18:17:39 [jet]
jet has joined #CSS
18:36:28 [dbaron]
dbaron has joined #css
18:42:39 [jet_]
jet_ has joined #CSS
18:54:08 [krit]
krit has joined #css
18:58:31 [lstorset]
lstorset has joined #css
18:58:53 [arno]
arno has joined #css
19:05:53 [jet]
jet has joined #CSS
19:09:07 [shepazu]
shepazu has joined #css
19:43:26 [jet]
jet has joined #CSS
19:53:21 [shepazu]
shepazu has joined #css
20:00:38 [dbaron]
dbaron has joined #css
20:02:10 [jet]
jet has joined #CSS
21:14:09 [bradk]
bradk has joined #css
21:14:17 [dbaron]
dbaron has joined #css
21:15:46 [bradk]
Hello. Anything happening here?
21:16:40 [ksweeney]
ksweeney has joined #css
21:16:59 [ksweeney]
ksweeney has left #css
21:21:02 [vhardy_]
vhardy_ has joined #css
21:31:37 [hober]
bradk: f2f finished yesterday
21:32:13 [bradk]
Ah. No wonder. I thought it was also today.
21:47:28 [vhardy_]
vhardy_ has joined #css
21:51:06 [vhardy_]
vhardy_ has joined #css
21:53:47 [vhardy_]
vhardy_ has joined #css
21:55:25 [krit]
krit has left #css
22:05:34 [vhardy_]
vhardy_ has joined #css
22:37:46 [vhardy_]
vhardy_ has joined #css
22:57:22 [drublic]
drublic has joined #css
23:02:47 [vhardy_]
vhardy_ has joined #css
23:04:39 [vhardy_]
vhardy_ has joined #css
23:05:49 [vhardy_]
vhardy_ has joined #css
23:15:35 [dbaron]
dbaron has joined #css
23:36:52 [arno]
arno has joined #css
23:44:00 [vhardy_]
vhardy_ has joined #css
23:48:37 [krit]
krit has joined #css
00:02:40 [arno]
arno has joined #css
00:12:05 [vhardy_]
vhardy_ has joined #css
00:28:10 [vhardy_]
vhardy_ has joined #css
00:58:17 [krit]
krit has joined #css
01:07:24 [arno]
arno has joined #css
01:17:30 [miketaylr]
miketaylr has joined #css
01:19:25 [vhardy_]
vhardy_ has joined #css
01:43:49 [vhardy__]
vhardy__ has joined #css
02:58:16 [drublic]
drublic has joined #css
03:28:54 [vhardy_]
vhardy_ has joined #css
03:41:13 [vhardy_]
vhardy_ has joined #css
03:49:11 [dbaron]
dbaron has joined #css
04:28:14 [vhardy_]
vhardy_ has joined #css
04:58:45 [drublic]
drublic has joined #css
05:22:40 [vhardy_]
vhardy_ has joined #css
07:32:37 [Ms2ger]
Ms2ger has joined #css
07:57:43 [tantek]
tantek has joined #css
08:59:35 [drublic]
drublic has joined #css
09:15:33 [SimonSapin]
SimonSapin has joined #css
09:29:47 [drublic]
drublic has joined #css
11:00:35 [drublic_]
drublic_ has joined #css
11:33:01 [krijnh]
krijnh has joined #css
11:43:58 [florianr]
florianr has joined #css
13:10:52 [arronei]
arronei has joined #css
13:57:23 [jdaggett]
jdaggett has joined #css
14:13:39 [vhardy_]
vhardy_ has joined #css
14:41:24 [miketaylr]
miketaylr has joined #css
14:44:34 [jarek]
jarek has joined #css
14:52:14 [vhardy_]
vhardy_ has joined #css
15:15:28 [vhardy_]
vhardy_ has joined #css
15:19:01 [dbaron]
dbaron has joined #css
15:59:26 [leaverou]
leaverou has joined #css
16:29:42 [arno]
arno has joined #css
16:30:11 [TabAtkins]
TabAtkins has joined #css
16:39:12 [krit]
krit has joined #css
17:01:50 [dbaron]
dbaron has joined #css
17:11:15 [jet]
jet has joined #CSS
17:19:05 [jet_]
jet_ has joined #CSS
17:28:18 [jet]
jet has joined #CSS
17:41:26 [jet_]
jet_ has joined #CSS
18:19:33 [dbaron]
dbaron has joined #css
19:55:20 [tantek]
tantek has joined #css
20:18:39 [drublic]
drublic has joined #css
20:23:39 [isherman]
isherman has joined #css
20:43:09 [drublic]
drublic has joined #css
21:11:30 [jarek]
jarek has joined #css
21:20:08 [drublic]
drublic has joined #css
21:27:06 [arno]
arno has joined #css
21:40:25 [arno]
arno has joined #css
22:00:20 [miketaylr]
miketaylr has joined #css
22:22:07 [tantek]
tantek has joined #css
00:12:31 [drublic]
drublic has joined #css
00:50:05 [myakura]
myakura has joined #css
00:57:19 [myakura]
myakura has joined #css
01:25:26 [tantek]
tantek has joined #css
02:47:54 [miketaylr]
miketaylr has joined #css
04:00:25 [krit]
krit has joined #css
07:58:13 [Ms2ger]
Ms2ger has joined #css
09:38:43 [drublic]
drublic has joined #css
09:54:14 [drublic]
drublic has joined #css
10:07:25 [drublic]
drublic has joined #css
12:32:09 [koji]
koji has joined #css
13:11:52 [drublic]
drublic has joined #css
14:13:07 [koji]
koji has joined #css
14:37:00 [lstorset]
lstorset has joined #css
15:35:07 [drublic]
drublic has joined #css
16:08:49 [drublic]
drublic has joined #css
17:04:31 [drublic]
drublic has joined #css
20:13:06 [cabanier]
cabanier has joined #css
21:17:02 [jarek]
jarek has joined #css
21:18:04 [jarek]
jarek has joined #css
21:28:48 [leaverou]
leaverou has joined #css
23:11:04 [drublic]
drublic has joined #css
23:43:59 [Liam]
Liam has joined #css
23:56:00 [tantek]
tantek has joined #css
00:01:26 [tantek]
tantek has joined #css
01:02:21 [tantek]
tantek has joined #css
01:16:10 [tantek]
tantek has joined #css
01:17:22 [tantek_]
tantek_ has joined #css
03:03:23 [tantek]
tantek has joined #css
04:10:49 [tantek]
tantek has joined #css
06:57:24 [tantek]
tantek has joined #css
07:02:41 [Ms2ger]
Ms2ger has joined #css
07:38:16 [tantek_]
tantek_ has joined #css
08:07:45 [jet]
jet has joined #CSS
08:20:26 [jet]
jet has joined #CSS
08:30:39 [tantek]
tantek has joined #css
11:33:26 [drublic]
drublic has joined #css
20:10:15 [jarek]
jarek has joined #css
20:49:23 [leaverou_]
leaverou_ has joined #css
22:23:57 [leaverou]
leaverou has joined #css
02:07:07 [leaverou]
leaverou has joined #css
06:56:13 [leaverou]
leaverou has joined #css
07:06:39 [leaverou]
leaverou has joined #css
07:52:43 [drublic]
drublic has joined #css
08:20:12 [drublic]
drublic has joined #css
08:49:06 [drublic]
drublic has joined #css
10:13:27 [SimonSapin]
SimonSapin has joined #css
11:16:32 [drublic]
drublic has joined #css
12:05:31 [drublic]
drublic has joined #css