17:03:26 <RRSAgent> RRSAgent has joined #CSS
17:03:26 <RRSAgent> logging to http://www.w3.org/2009/11/02-CSS-irc
17:03:27 <dbaron> dbaron has joined #css
17:03:36 <plinss> rrsagent make logs public
17:04:24 <Yves> Yves has joined #css
17:05:27 <sylvaing> ScribeNick: sgalineau
17:05:36 <plinss> zakim, this is style
17:05:36 <Zakim> plinss, I see Styl_CSS-FP(TPAC)12:00PM in the schedule but not yet started.  Perhaps you mean "this will be style".
17:05:52 <sylvaing> Introductions
17:06:05 <sylvaing> Peter Linss, HP. 
17:06:12 <Arron> Arron has joined #css
17:06:28 <sylvaing> Sylvain Galineau, Microsoft, IE team
17:06:31 <plinss> zakim, this will be style
17:06:31 <Zakim> ok, plinss; I see Styl_CSS-FP(TPAC)12:00PM scheduled to start 6 minutes ago
17:06:37 <sylvaing> Arron Eicholz, Microsoft, IE Team
17:06:45 <MikeSmith> MikeSmith has joined #css
17:06:48 <sylvaing> Beth and Simon, Apple, WebKit
17:06:56 <sylvaing> David Baron, Mozilla
17:07:01 <glazou> Pierre Saslawsky
17:07:28 <Bert_lap> Bert_lap has joined #css
17:07:30 <sylvaing> John Daggett, Mozilla Japan, CSS3 Fonts editor
17:07:35 <sylvaing> Chris Lilley, W3C
17:07:49 <sylvaing> Alex Mogilevsky, Microsoft
17:07:57 <sylvaing> Tab Atkins, Invited Expert
17:08:02 <sylvaing> Brad Kemper, Invited Expert
17:08:10 <sylvaing> Elika Etemad (fantasai), Invited Expert
17:08:27 <sylvaing> Daniel Glazman, csswg co-chair
17:08:33 <sylvaing> Bert Bos, W3C
17:08:48 <sylvaing> (scribe missed a couple of observers)
17:08:58 <sylvaing> Topic: Meeting Agenda
17:10:18 <sylvaing> http://wiki.csswg.org/planning/tpac-2009
17:10:43 <mielke> mielke has joined #css
17:11:00 <mielke> *waves back :)
17:11:59 <sylvaing> Discussing timing of various items, adding CSS test suite to agenda
17:17:20 <hamaji> hamaji has joined #css
17:20:45 <sylvaing> Topic: LC comments for Math-ML for CSS profile
17:20:52 <glazou> mielke: you've got mail
17:22:10 <sylvaing> bert: largely CSS2.1 to render MathML
17:22:24 <sylvaing> bert: I didn't find anything I would comment on
17:22:25 <mielke> sweet. thx for the agenda mail
17:22:40 <sylvaing> http://www.w3.org/TR/2009/WD-mathml-for-css-20091006/
17:24:16 <sylvaing> bert: in section 12 (default stylesheet), a general comment says 'it would be appropriate to extend CSS3 with a few math-specific properties'
17:24:36 <sylvaing> glazou: it would be helpful to know what is intended
17:24:43 <bradk> bradk has joined #css
17:25:08 <sylvaing> bert: one approach involves additions to the box model for math layout. then stretchable characters such as a parenthesis stretching to the size of the box next to it
17:25:35 <sylvaing> dbaron: stretchable characters require knowledge of what's being contained
17:26:08 <sylvaing> bert: the stretching character is bound to something; but an additional issue is that stretching the height of a character may also impacts its width
17:26:19 <TabAtkins> TabAtkins has joined #css
17:26:26 <sylvaing> bert: these are the general issues that were discussed in the past
17:27:51 <sylvaing> jdagget notices variant properties under the math variants section and forecasts comments...
17:28:32 <sylvaing> jdaggett: there are Unicode characters for maths outside the BMP
17:30:07 <sylvaing> jdaggett: when you use math characters, things like italics may have a semantic meaning i.e. they're not presentation
17:30:42 <szilles> szilles has joined #css
17:31:07 <dbaron> 𝐅𝒖𝓷𝖐𝘆 𝘾𝐡𝒂𝓻𝖘
17:31:45 <sylvaing> jdaggett: section 3.3: stretchar ?
17:32:33 <alexmog> alexmog has joined #css
17:33:45 <smfr> http://www.w3.org/TR/MathML2/chapter6.html#chars.BMP-SMP
17:33:52 <bradk> stretchar is spelled consistently throughout at least.
17:34:20 <ChrisL> ChrisL has joined #css
17:34:31 <ChrisL> http://www.w3.org/TR/2009/WD-MathML3-20090604/chapter7.html#chars.BMP-SMP
17:34:33 <ChrisL> 7.5 Mathematical Alphanumeric Symbols 
17:35:41 <sylvaing> TabAtkins: this section describes both Unicode and alternatives ways to specify math characters
17:36:02 <ChrisL> "Mathematical Alphanumeric Symbol characters should not be used for styled text. For example, Mathematical Fraktur A must not be used to just select a blackletter font for an uppercase A. Doing this sort of thing would create problems for searching, restyling (e.g. for accessibility), and many other kinds of processing. "
17:36:16 <sylvaing> jdaggett will send comments on document tonight
17:37:23 <sylvaing> Bert will share the WG's answer with MathML
17:37:36 <sylvaing> Topic: Transitions/Transformations/Animations
17:37:42 <plh-webapps> plh-webapps has joined #css
17:37:48 <ChrisL> also http://www.unicode.org/reports/tr25/tr25-8.html Unicode Technical Report #25
17:37:48 <ChrisL> Unicode Support for Mathematics
17:38:03 <sylvaing> glazou: there are large expectations from the web design community around these features
17:38:55 <sylvaing> glazou: we'd like to move these specifications along: edit the specs, test suites...
17:39:58 <sylvaing> smfr: we're committed to moving the specs forward, specifically 2D Transforms and Transitions
17:40:06 <sylvaing> smfr: 3D Transforms and Animations will likely take longer
17:40:28 <fantasai> +David Singer (Apple)
17:40:52 <sylvaing> smfr: we have tests we need to move to the W3C format
17:41:07 <sylvaing> fantasai: we have both stand-alone testcases and reftests
17:41:41 <sylvaing> fantasai: if we need another test format for transitions, that's understandable
17:41:50 <sylvaing> dbaron: some of these tests will have to scripted and we should be ok with that
17:42:18 <sylvaing> smfr: some of the functionality needed to test transitions may need to be specified as well
17:43:41 <dsinger> dsinger has joined #css
17:44:03 <sylvaing> dsinger: if we had agreement on a template testcase, it would help get us going
17:46:44 <sylvaing> dbaron: I'd be willing to help edit Transitions
17:47:24 <anne> anne has left #css
17:47:52 <anne> anne has joined #css
17:49:42 <dethbakin> dethbakin has joined #css
17:50:16 <sylvaing> dbaron: for the inheritance processing model issue, I think we decided that if you have 4 elements A, B, C in an ancestor-descendant relationship
17:50:43 <sylvaing> and you specify a transition on color in B and C and a dynamic color property change occurs, what happens to C's transition ?
17:51:32 <sylvaing> we decided that C's transition does not happen but it doesn't inherit B's animated values
17:52:25 <ChrisL> its just a case of being clear when the values are grabbed to compute the transition, and whether they can be changed during a transition.
17:52:29 <sylvaing> dbaron: C's transition would only be triggered when C is updated
17:52:59 <sylvaing> dbaron: if C was already in a transition, that would not be affected
17:55:53 <sylvaing> smfr: Webkit does not currently handle transitions on inherited properties and we haven't seen any issues from it
17:56:52 <sylvaing> glazou: are web designers going to understand this ?
17:57:03 <sylvaing> szilles: this is the most understandable solution yet
17:57:32 <TabAtkins> a { transition: none; color: blue; } a:hover { color: red; } b { transition: color 1s; }  <-- If I hover <a>, should <b> transition?  Does it currently?
17:59:11 <bradk> A>B
18:00:04 <plh-css> plh-css has joined #css
18:01:37 <TabAtkins> b>c { transition: color 2s } <-- Given the previous rules, now <c> does *not* transition when I hover <a>, but it does inherit <b>'s colors as <b> transitions.
18:02:19 <sylvaing> the answer to Tab's first case was that B does transition as the inherited color value is not animated
18:04:25 <sylvaing> smfr: transitioning visibility is an area we have thought of making changes to create fading effects vs. the current specified behavior where all non-1 values result in visibility:hidden
18:06:54 <sylvaing> pierres: regarding the inheritance discussion, does this mean that the result will be different depending on the sequence in which I trigger my transitions through script ?
18:08:10 <TabAtkins> Example: <script> $foo.css("color","red"); $foo.css("transition","color 1s");</script> <-- Does the color transition?  Does it not?  Is this impl-dependent currently?
18:08:31 <sylvaing> dbaron: transitions do complicate the model in that dynamic property updates were effectively simultaneous but now we still have residual effects from older values
18:10:38 <fantasai> smfr describes a case where the author turns off transitions, sets an intermediate value, sets transitions back on, and then sets another value
18:10:58 <fantasai> various browser optimizations may cause that intermediate value to not be used, in which case the transition transitions from the wrong start point
18:16:27 <Lachy> Lachy has joined #css
18:16:43 <Lachy> Lachy has joined #css
18:17:42 <tantek> tantek has joined #css
18:18:27 <sylvaing> TabAtkins: there was talk about grouping transitions together to happen as an atomic unit i.e. setting a number of transitions together without any one starting ahead of the others
18:18:42 <sylvaing> dbaron: we already batch these things
18:18:51 <sylvaing> plinss: the point is that the author can control when the batching start and stops
18:19:36 <glazou> AGENDA, move fitting text-size to monday afternoon to allow SteveZ's presence
18:19:54 <sylvaing> dbaron: the problem with such an API is that we will do more frequent flushing
18:21:03 <fantasai> dbaron: the browser has to flush right before the "don't flush here" call
18:21:10 <fantasai> dbaron: as well as at the "flush here" call
18:21:14 <sylvaing> smfr: I think this issue requires a note in the spec
18:21:44 <fantasai> dbaron: and if someone calls "don't flush here" in a loop to try to optimize, it'll cause lots of flushes and actually degrade perf
18:21:47 <sylvaing> ACTION smfr Add implementation note in the spec about style update batches and their effect on transitions
18:21:47 <trackbot> Sorry, couldn't find user - smfr
18:22:49 <sylvaing> sgalineau: pseudo-elements and transitions ?
18:23:01 <sylvaing> smfr: Dean Jackson updated the spec so that they can transition
18:23:22 <sylvaing> dbaron: only :before and :after transition.
18:23:38 <Lachy> Lachy has joined #css
18:23:47 <dbaron> http://lists.w3.org/Archives/Public/www-style/2009Jun/0121.html and http://lists.w3.org/Archives/Public/www-style/2009Jul/0050.html are the messages about the inheritance issue we discussed earlier
18:24:26 <sylvaing> ChrisL: are we aiming to move this specification to LC ?
18:24:34 <sylvaing> glazou: it depends on the editorial stability of the document
18:25:06 <TabAtkins> a { color: yellow; } <script>a.color="red"; a.transition="color 1s"; a.color="blue";</script>  <-- So the proposal is just to say "Hey authors, watch out for this!"?
18:25:07 <sylvaing> smfr: the spec has been edited over the w-e
18:27:25 <sylvaing> fantasai: you will have less to do during LC if you put out another WD first with all your changes
18:28:21 <sylvaing> Bert: I agree this is a likely path for transitions; I disagree that 2D transforms is as close to LC
18:29:01 <TabAtkins> Anyone have a nightly of webkit with transitions?
18:29:33 <Lachy> Lachy has joined #css
18:31:02 <smfr> TabAtkins: yes
18:31:17 <TabAtkins> smfr: Can I have it?
18:31:23 <dbaron> I probably need to send a bunch of comments on the "Animation of property types" section...
18:35:23 <sylvaing> tantek suggests an FAQ to answer 'When do we add a property?
18:35:41 <tantek> greetings everyone
18:35:46 <sylvaing> ' following a long discussion of this topic around 2D Transforms and all the other things we are adding to CSS
18:35:52 <sylvaing> glazou agrees
18:36:48 <sylvaing> ACTION Bert Draft an FAQ on when the CSS WG adds a new property
18:36:48 <trackbot> Created ACTION-189 - Draft an FAQ on when the CSS WG adds a new property [on Bert Bos - due 2009-11-09].
18:37:39 <sylvaing> <br />
18:38:10 <glazou> glazou has joined #css
18:38:35 <TabAtkins> Got a transition issue.  Check out www.xanthir.com/etc/transitions.html.  First, the transitions trigger on *pageload*, which is weird.  Second, "baz" doesn't start transitioning until after "bar" is done, when it *should* just inherit "bar"'s color as "bar" transitions.
18:55:30 <dethbakin> dethbakin has joined #css
19:00:55 <bradk> bradk has joined #css
19:03:10 <smfr> smfr has joined #css
19:03:29 <fantasai> TabAtkins: http://wiki.csswg.org/test/harness
19:03:59 <glazou> glazou has joined #css
19:04:10 <smfr> TabAtkins: your testcase looks like a webkit bug with transitions of inherited properties
19:04:15 <smfr> TabAtkins: what does FF do?
19:06:23 <mjs> mjs has joined #css
19:06:55 <TabAtkins> smfr: Notice also that it transitions on page load from black to red.  That doesn't seem to make sense.
19:07:23 <hyatt> hyatt has joined #css
19:07:43 <smfr> sounds like a bug
19:07:45 <plinss> plinss has joined #css
19:08:25 <sylvaing> smfr: transitions: we will publish another WD then aim for LC in early 2010
19:08:43 <shepazu> shepazu has joined #css
19:08:54 <tantek> tantek has joined #css
19:09:03 <Arron> Arron has joined #css
19:09:18 <sylvaing> glazou: 2D transforms; what about the rotated table header scenario esp. not overlapping preceding content ?
19:09:36 <sylvaing> fantasai: this is difficult as the table header borders also need to be properly rotated ?
19:10:02 <sylvaing> dbaron: there was a long discussion and proposal around this topic in the past (Beijing)
19:10:13 <sylvaing> Topic: CSS3 Animations
19:10:48 <Bert_lap> Bert_lap has joined #css
19:10:58 <sylvaing> smfr: we think animations are useful. There are things you can do with animations you can't with transitions such as moving objects through intermediate points
19:12:16 <sylvaing> smfr: 3D Tranforms needs more work e.g. detailing the 3D hiearchy of elements
19:13:02 <sylvaing> glazou: let's move transitions and 2d transforms forward
19:13:31 <Zakim> Zakim has left #CSS
19:13:53 <Zakim> Zakim has joined #CSS
19:14:04 <sylvaing> dbaron: I think transform-origin is interesting as in 3d the value requires extra input vs. 2d. (the latter is exactly like background-position)
19:15:45 <sylvaing> sylvaing: what about the note at the top of 2d transforms re: transforming fixed positioned descendants ?
19:16:11 <sylvaing> smfr: dave hyatt made this note; we think this is the most desirable behavior
19:16:15 <sylvaing> dbaron: we do this as well
19:16:52 <sylvaing> smfr: for fixed backgrounds, we have already noted that the transformed element will act like a porthole. we don't do this yet but will fix it
19:17:04 <sylvaing> Topic: Modularization and how to write a CSS profile
19:17:07 <smfr> i didn't say we'll fix it :)
19:20:23 <sylvaing> szilles: ideally profiles should refer to RECs. if not, breaking circularity can be achieved by referring to a snapshot
19:21:23 <sylvaing> fantasai: or a module such as CSS3 Multicolumn can refer to CSS2.1 but if an implementor supports CSS3 Color, the latter's definition of <color> then applies
19:22:06 <sylvaing> szilles: then the profile should state this
19:25:55 <sylvaing> quick discussion of when one can be conformant with no vendor prefix; answer: one a module reaches CR
19:26:26 <mmielke> mmielke has joined #css
19:26:46 <sylvaing> szilles: we hope that conformance would be claimed against the snapshot
19:31:25 <sylvaing> szilles: if I don't know what a snapshot is, I won't find the information I need
19:32:07 <sylvaing> fantasai: the CR reference for CSS3 should point to the snapshot
19:33:17 <sylvaing> fantasai: we can update the snapshot as soon as Selectors moves to CR or PR
19:34:14 <ChrisL> ChrisL has joined #css
19:34:38 <fantasai> http://wiki.csswg.org/planning/tpac-2009
19:35:53 <sylvaing> topic: text-overflow
19:36:07 <sylvaing> fantasai: there have been comments re: text overflow in the vertical direction
19:36:41 <sylvaing> fantasai: the feature was originally aimed at single lines; what about multi-line items ?
19:36:42 <szilles> Note, that under current rules, an implementation is still conforming if it implements features, like CSS3 color, that are in CR, using the CSS property names rather than having a vendor prefix
19:38:55 <fantasai> http://krijnhoetmer.nl/irc-logs/css/20090805#l-303
19:42:18 <sylvaing> TabAtkins: there is no useful distinction between line boxes overflowing vertically vs. blocks overflowing vertically
19:43:33 <sylvaing> smfr: a use case involves wrapped song names in the iTunes store that only need an ellipsis at the end of the last line
19:43:59 <sylvaing> tantek: what we're saying is that this really is an inline overflow
19:44:06 <fantasai> (there are only two lines of space for the song titles)
19:46:42 <sylvaing> smfr: does this property cause overflow though ?
19:46:56 <sylvaing> plinss: it seems orthogonal since its aim is to prevent overflow
19:46:58 <sylvaing> tantek: agree
19:47:28 <sylvaing> fantasai: do implementors agree on what the sensible behavior should be ?
19:48:11 <fantasai> smfr: We'd like to drop the requirement for overflow: hidden to trigger text-overflow
19:48:17 <fantasai> peter: Seems like this property prevents overflow
19:48:40 <fantasai> Alex: You can have other content that triggers overflow even in the presence of text-overflow
19:49:04 <fantasai> Alex: e.g. if you have a float that overflows and triggers scrollbars, and then also have text truncated by text-overflow
19:49:09 <fantasai> ...
19:49:20 <dbaron> Tantek: could say that 'text-overflow' always forces 'overflow' to 'hidden'
19:49:35 <dbaron> David Baron: Or you could say that it forces 'overflow' values other than 'visible' to 'hidden'
19:49:58 <hyatt> don't you mean forces only visible to hidden?
19:50:16 <dbaron> hyatt, no... but why do you suggest that?
19:50:38 <hyatt> you wouldn't want to turn overflow:scroll into hidden just because you set text-overflow after overflow
19:50:40 <dbaron> hyatt, I think the issue Alex raised was complications crossing "whether to have scrollbars" and "whether to have ellipses"
19:50:59 <dbaron> hyatt, or was that not the reason for the restriction in the first place?
19:51:14 <dbaron> hyatt, so, in that case, why do we want to change 'overflow' at all?
19:51:29 <dbaron> hyatt, or is it because otherwise nothing else in the spec actually hides the text that overflows?
19:51:50 <fantasai> TabAtkins: Anytime I'm using overflow: hidden for anything other than making the block overflow: hidden, I run into problems
19:51:56 <fantasai> ... block formatting context ... etc
19:52:07 <fantasai> Alex: How about floats?
19:52:19 <fantasai> TabAtkins: If I want my floats to get cut, I want to put overflow: hidden  on them. They're not text
19:52:42 <fantasai> Alex: If there is a float in the text beyond the ellipsis cut-off point,
19:52:51 <hyatt> can't text-overflow just be completely independent of overflow
19:52:51 <fantasai> Alex: Where would be the hypothetical position for that float?
19:52:56 <fantasai> (or something with abspos)
19:53:00 <hyatt> like it would truncate even if overflow is visible
19:53:02 <fantasai> Tab: Good question
19:53:04 <hyatt> but doesn't imply overflow:hidden
19:53:10 <fantasai> Tab: I think it would try to position itself at the end of the line
19:53:32 <fantasai> Alex: Or pretend overflow: visible and just refuse to render the text
19:53:34 <hyatt> i don't see why text-overflow has to really care what the value of overflow is...
19:54:26 <fantasai> hyatt, what happens if you have overflow: scroll and a float that overflows and text-overflow won the text and then you scroll down?
19:55:31 <fantasai> ...
19:55:37 <hyatt> i can't tell what you mean exactly
19:55:43 <fantasai> Alex: If there is a paragraph that fits perfectly, but there is a paragraph that does not fit
19:55:47 <hyatt> (sorry i don't want to derail remotely, so just ignore me if it is convenient) :)
19:55:57 <fantasai> Alex: Do we append an ellipsis to the paragraph that fits because of the paragraph that didn't fit?
19:56:11 <fantasai> ...
19:56:17 <sylvaing> plinss: yes, you want to truncate enough of the first paragraph to fit the ellipsis
19:56:23 <fantasai> Alex: In the process of measuring one block of text, you have to consider text that comes later
19:56:46 <fantasai> Peter: You finish the first paragraph, start the next paragraph, then go back and truncate the earlier paragraph
19:57:01 <fantasai> smfr: It's like the first-letter problem
19:57:12 <fantasai> Tantek: Like the first-line problem
19:57:12 <dethbakin> dethbakin has joined #css
19:57:21 <tantek> ::first-line
19:57:35 <fantasai> Alex: As you are formatting the line ... later you find that we have to go back and stick an ellipsis up there
19:58:04 <fantasai> ...
19:58:13 <fantasai> Steve: The critical thing is to say that there's content you're not seeing
19:58:16 <fantasai> Tantek: Write up the testcases
19:58:46 <TabAtkins> www.xanthir.com/etc/text-overflow.html
19:58:57 <fantasai> Tab: Pull it up in Safari or IE8
19:59:07 <fantasai> Tab: If you do, you see as expected the ellipsis
19:59:17 <fantasai> Tab: But if you start scrolling, you don't see anymore of the text
19:59:57 <mmielke> mmielke has joined #css
19:59:57 <hyatt> of course you also said nowrap
20:00:17 <fantasai> Peter: In this case I would argue you shouldn't have a scrollbar
20:00:38 <fantasai> Peter: It should behave as if there is no content to scroll
20:00:43 <hyatt> yup that's a bug in webkit that it showed a scrollbar
20:00:49 <hyatt> an enabled scrollbar rather
20:00:52 <fantasai> dbaron: dsinger made a comment to me which throws another comment in here
20:01:03 <fantasai> dbaron: If it's wrapped and you're doing text-overflow ellipsis, you get the ellipsis on the last line
20:01:03 <hyatt> that is definitely a bug in webkit
20:01:13 <fantasai> dbaron: and it scrolls, and you scroll, you get something idfferent
20:01:34 <fantasai> dbaron: Should these really behave differently?
20:02:12 <fantasai> ...
20:02:28 <fantasai> Peter: I implemented a control with this in 93. When you have a filename and it doesn't fit, it has an ellipsis.
20:02:40 <fantasai> Peter: If I'm editing the field, the ellipsis goes away
20:02:43 <fantasai> Peter: and it scrolls
20:02:50 <fantasai> Tantek: Sounds like :focus selector
20:03:57 <fantasai> Peter: For Tab's case, I can see a case for having ellipsis on both sides as we scroll until we get to the end, and then the ellipsis is on the left side.
20:04:18 <fantasai> Peter: In the vertical case, as I'm scrolling down, I'd want an ellipsis at the beginning
20:04:46 <fantasai> Peter: I can imagine wanting that for e.g. a DVR
20:05:02 <fantasai> Peter: And not all UAs have a scrollbar for scrolling
20:06:09 <fantasai> fantasai: roc's interpretation was that the ellipsis is a render-time thing: you lay out everything and then just draw the ellipsis
20:06:25 <fantasai> Peter: I get roc's point that you want it laid out and compute the scroll region as if there's no ellipsis
20:06:39 <fantasai> Peter: but when you render the text on that line you need to actually put the ellipsis in the text flow
20:06:45 <fantasai> Peter: Otherwise you don't get proper ligatures, etc.
20:06:56 <fantasai> Peter: It should look as if someone typed an ellipsis on the line
20:07:14 <fantasai> Steve: I'm confused in this particular case because I was thinkin the ellipsis would show me there's content that wouldn't fit
20:07:24 <fantasai> Steve: but if I put scorllbars there all the content fits
20:07:41 <fantasai> Steve: So there's no need for an ellipsis there
20:07:41 <Hixie> Hixie has joined #css
20:07:41 <dbaron> s/scorllbars/scrollbars/
20:08:08 <fantasai> Steve: But I do understand the example that peter mentioned, that the ellipsis is a second hint
20:08:26 <fantasai> ...
20:08:36 <fantasai> Tab: You're seeing the ellipsis as an indication of content you can't reach
20:08:44 <fantasai> Tab: I see it as an indication of content you can't see
20:09:16 <fantasai> Peter: We all agree that the behavior in Tab's example is not wanted (showing scrollbars indicating lots of content, but not beinga ble to scroll to it because it's truncated by the ellipsis)
20:09:47 <fantasai> Alex: What I see here is interoperable behavior that can't be explained easily and doesn't have much use cases
20:10:28 <sylvaing> fantasai: given that there *is* interoperable behavior, are implementors OK with changing it ?
20:10:35 <fantasai> to make more sense :)
20:11:06 <fantasai> Tab: I honestly can't see anyone depending on it working this way and not be happy with it changinge
20:11:58 <fantasai> ...
20:12:14 <fantasai> Alex: There are two questions here. Are we going to change quirks bahvior? No.
20:12:28 <fantasai> Alex: Other question is what do we want to happen here, and this scenario is really questionable to begin with.
20:12:39 <fantasai> Alex: We've created something and we're trying to figure out what we would want to happen
20:13:25 <fantasai> Alex: We have wrapped text, and it may not fit in horiontal direction and it may not fit in vertical direction
20:13:53 <fantasai> Alex: ....
20:14:06 <fantasai> Alex: I like that it does not affect layout
20:14:24 <fantasai> Alex: And just at render time we insert the ellipsis
20:14:40 <fantasai> Alex: I don't think there are cases where we have ellipsis in the middle
20:14:51 <fantasai> Peter: There's a use case for ellipsis in the middle
20:15:00 <fantasai> Peter: URLs
20:15:15 <fantasai> dbaron: We have a middle option for ellipsis in xul, too.
20:15:24 <fantasai> dbaron: Also in bidi you might have cases for ellpisis in the middle
20:16:24 <fantasai> dbaron: I think having a spec for bidi cases was one of the issues we're waiting on for implementing this
20:16:49 <fantasai> smfr: What happens with selection? What happens when the user selects the ellipsis?
20:17:04 <fantasai> dbaron: We don't define selection right now. We probably should at some point
20:17:28 <fantasai> Steve: I have one concern with what you said Alex, which was focusing on text
20:17:43 <tantek> fantasai, feel free to capture the selection question(s) as outstanding questions/issues for CSS3-UI
20:17:50 <fantasai> Steve: What if I'm using images to create lines of symbols, what happens?
20:18:19 <fantasai> Alex: You wouldn't get an ellipsis with floats, because then you don't have lines
20:18:22 <fantasai> Steve: no, I have lines
20:18:24 <TabAtkins> At the moment, both webkit and ie allow you to highlight the ellipsis, but then put only the visible text on the clipboard.  Ellipsis doesn't carry with the content.
20:18:28 <tantek> fantasai, I'm not familiar with Tracker, so I'll action you ;)
20:18:32 <fantasai> ... something about a pseudo-element
20:18:39 <fantasai> http://w3.org/Style/CSS/Tracker/ go for it
20:18:53 <fantasai> it's really straightforward
20:18:56 <fantasai> make product
20:18:57 <fantasai> add an issue
20:18:58 <tantek> ACTION fantasai: capture the (text) selection question(s) related to text-overflow as outstanding questions/issues for CSS3-UI
20:18:58 <trackbot> Created ACTION-190 - Capture the (text) selection question(s) related to text-overflow as outstanding questions/issues for CSS3-UI [on Elika Etemad - due 2009-11-09].
20:19:22 <fantasai> ACTION Tantek: learn to use Tracker
20:19:22 <trackbot> Sorry, couldn't find user - Tantek
20:20:02 <fantasai> Alex: I would like resolution to keep ellipsis a render-time thing. I'm open to extending it
20:20:20 <fantasai> Alex: Let's figure out what we need to do to have vertical overflow create ellipsis. that seems sensible and doable
20:21:33 <fantasai> Alex: We're not talking about existing ellipsis bheavior proeprty to change behavior to include overflow, right?
20:21:56 <fantasai> fantasai: that is what we're talking about
20:22:08 <fantasai> Alex: We've had this behavior for 10 years
20:22:26 <fantasai> Alex: We usually don't change behavior like that
20:22:44 <fantasai> Alex: I think we should come up with a new value
20:23:30 <fantasai> Alex: .. it's probably not helping that I can't come up with a better term :)
20:23:45 <fantasai> Tab: ellipsis-block
20:23:51 <fantasai> Steve: too long, but content-overflow-indication :)
20:24:05 <glazou> glazou has joined #css
20:28:02 <fantasai> ...
20:28:16 <fantasai> Alex doesn't see the point in changing the behavior in Tab's example.
20:28:28 <fantasai> Alex: Maybe if you show me a use case for a different behavior
20:28:47 <fantasai> Brad: I would expect that as you scroll to the right, the ellipsis moves to the right revealing more and more words
20:29:37 <fantasai> Tab: Putting an ellipsis in mind is not about "don't render anything past this point ever"
20:29:51 <fantasai> Tab: I don't want it to be visible all the time, but I still want to be able to scroll to it 
20:30:31 <fantasai> Peter gives examples from his DVR
20:30:35 <fantasai> and channel guide
20:31:00 <fantasai> Peter: This is a common UI in places other than web content, and it's something that people want to do with CSS
20:31:29 <fantasai> Peter: More and more people are using XML+CSS 
20:31:38 <fantasai> Peter: for UI
20:32:10 <fantasai> Peter: We're using it in our printer UIs. There's no scrollbars, it's flick mechanism
20:32:28 <fantasai> Peter: You can envision your channel guide, but imagine a table
20:32:45 <fantasai> Peter: For the table cells that are incomplete, they show ellipsis
20:33:09 <fantasai> Peter: and as you scroll to the right, the ellipsis shift and the content is revealed
20:33:48 <fantasai> Peter: I want an ellipsis on the right if there's content to the right, or an ellipsis to the left if there's content on the right
20:33:52 <fantasai> s/right/left/
20:34:14 <glazou> You want to apply width to ::ellipsis and a filter
20:34:26 <fantasai> dbaron: Are there cases where the behavior you want for ellipsizing text you can get to is dfferent from the behavior for ellipsizing text you can't get to?
20:34:33 <fantasai> Peter: I don't think so.
20:34:44 <fantasai> dbaron: Maybe crop in the middle case for URLs
20:34:59 <fantasai> dbaron: The other case is the bidi cases, which might be different
20:35:19 <fantasai> Peter: My position is that the ... ellipsizing is ortogonal
20:35:55 <fantasai> dsinger: I don't agree with you on the bidi case
20:36:24 <fantasai> Peter: .. I want to be able to specify an ellipsis that says "put an ellipsis wherever text is cut off"
20:36:36 <fantasai> Peter: and another one that just cuts off the text
20:36:50 <fantasai> dbaron: Currently it's the doesn't fit case, not the cut off case
20:37:10 <fantasai> dbaron: My position is that I'd like to see a spec based on what everyone else does
20:37:21 <fantasai> dbaron: otherwise we'll be adding a 4th implementation not based on a spec
20:37:32 <fantasai> dbaron: because people want this
20:37:54 <fantasai> Steve: that goes back to fantasai's original question: are we forced to live with the current situation, or can we change things?
20:38:06 <fantasai> Peter: hyatt thinks the existing behaviro in webkit is a bug
20:38:18 <fantasai> ...
20:38:39 <fantasai> Brad: Doesn't seem like it would need a separate property. The way it is now doesn't make any sense
20:39:00 <fantasai> Steve: The question isn't about does it make sense. The question is, is it so cast in stone right now that we can't change it
20:39:49 <fantasai> Tab: I greatly prefer presentation: it jsut shows you stuff you can't see
20:42:20 <dsinger> OK, if ellipses are visual, and the text is bi-di, then FIRST layout the entire text, then SECOND scroll to that visual position, and then THIRD if there is more text in the text-advance direction, replace the last character(s) in the text-advance direction with an ellipsis (and note that this/these character(s) might be visually in the middle of the visible area)
20:43:25 <fantasai> RESOLUTION: Only horizontal overflow triggers for text-overflow: ellipsis. Add a new keyword for handling ellipsis due to vertical overflow where the ellipsis appears on the last line
20:43:50 <bradk>  text-overflow-x (current text-overflow behavior) and text-overflow-y (vertical ellipsis)?
20:44:53 <fantasai> discussion of whether ellipsis is visual or logical in the order of text
20:46:22 <dbaron> http://dbaron.org/css/test/2009/text-overflow-bidi
20:49:44 <fantasai> fantasai: I think it should just behave as clipping. That is the easiest to understand. Maybe in bidi cases you get the end of the sentence and the beginning of the sentence and the middle off-screen
20:49:52 <fantasai> fantasai: But at least you can understand what is happening
20:50:02 <fantasai> (we are looking at actual behavior for bidi cases)
20:50:10 <fantasai> (it seems very weird)
20:53:05 <fantasai> Steve: If it's a rendering behavior, and affects no layout, then what Daniel is saying makes sense
20:53:16 <fantasai> Daniel: It's extremely simple, and understandable
20:53:24 <dsinger> choice B:  layout as a long visual element.  scroll to where you want to go.  show an ellipsis at the visual left and/or right edges, if there is more to be seen in that direction
20:53:29 <fantasai> dbaron: How does this deal with chopping a character or ligature in half?
20:53:40 <fantasai> Peter: I want to clarify the point about two ellipsis
20:53:44 <fantasai> s/is/es/
20:55:42 <fantasai> ACTION daniel: check for examples in Hebrew books
20:55:43 <trackbot> Created ACTION-191 - Check for examples in Hebrew books [on Daniel Glazman - due 2009-11-09].
20:57:26 <fantasai> <br type=lunch>
21:14:03 <Zakim> Zakim has left #CSS
21:21:10 <hyatt> hyatt has joined #css
21:21:41 <koalie> koalie has joined #CSS
21:21:59 <Zakim> Zakim has joined #CSS
21:22:25 <koalie> Zakim, please dial Salon_9
21:22:25 <Zakim> sorry, koalie, I don't know what conference this is
21:22:35 <koalie> Zakim, this will be css
21:22:35 <Zakim> ok, koalie; I see Styl_CSS-FP(TPAC)12:00PM scheduled to start 262 minutes ago
21:22:55 <koalie> Zakim, dial Salon_9
21:22:55 <Zakim> ok, koalie; the call is being made
21:22:56 <Zakim> Styl_CSS-FP(TPAC)12:00PM has now started
21:22:57 <Zakim> +Salon_9
21:23:02 <koalie> koalie has left #CSS
21:24:34 <Zakim> -Salon_9
21:24:35 <Zakim> Styl_CSS-FP(TPAC)12:00PM has ended
21:24:35 <Zakim> Attendees were Salon_9
21:26:18 <jdaggett> jdaggett has joined #css
21:26:25 <jdaggett> zakim: hello
21:26:41 <jdaggett> invite zakim
21:27:15 <jdaggett> invite Zakim
21:28:11 <hamaji> hamaji has joined #css
21:28:27 <mitzpettel> mitzpettel has joined #css
21:31:10 <jdaggett> Zakim: please dial Salon_9
21:32:36 <koalie> koalie has joined #CSS
21:32:53 <koalie> RRSAgent, pointer?
21:32:53 <RRSAgent> See http://www.w3.org/2009/11/02-CSS-irc#T21-32-53
21:33:21 <koalie> koalie has left #CSS
21:38:14 <jdaggett> jdaggett has joined #css
21:42:57 <glazou> glazou has joined #css
21:44:17 <Zakim> Styl_CSS-FP(TPAC)12:00PM has now started
21:44:25 <Zakim> +Hakon_Lie
21:45:46 <Curt`> Curt` has joined #css
21:46:40 <jdaggett> Zakim: please dial Salon_9
21:47:19 <jdaggett> http://www.w3.org/2009/11/02-CSS-irc#T21-32-53
21:48:30 <shepazu> shepazu has joined #css
21:48:55 <jdaggett> Zakim: hello
21:49:40 <glazou> glazou has joined #css
21:50:33 <jdaggett> Zakim, how are you?
21:50:33 <Zakim> I don't understand your question, jdaggett.
21:50:42 <jdaggett> Zakim, please dial Salon_9
21:50:42 <Zakim> ok, jdaggett; the call is being made
21:50:44 <Zakim> +Salon_9
21:51:19 <jdaggett> Zakim, who is here?
21:51:19 <Zakim> On the phone I see Hakon_Lie, Salon_9
21:51:20 <Zakim> On IRC I see shepazu, Curt`, jdaggett, hamaji, Zakim, hyatt, Hixie, anne, MikeSmith, Yves, RRSAgent, howcome, MoZ, arronei, karl, krijnh, fearphage, fantasai, trackbot, Bert
21:53:34 <mjs> mjs has joined #css
21:55:18 <dethbakin> dethbakin has joined #css
21:55:30 <dsinger> dsinger has joined #css
21:57:15 <bradk> bradk has joined #css
21:57:34 <smfr> smfr has joined #css
21:57:35 <jfkthame> jfkthame has joined #css
21:58:05 <Zakim> +[Mozilla]
21:59:06 <hyatt> hyatt has joined #css
21:59:23 <Arron> Arron has joined #css
22:00:06 <tantek> tantek has joined #css
22:00:17 <dbaron> dbaron has joined #css
22:00:24 <Bert_lap> Bert_lap has joined #css
22:00:36 <glazou> glazou has joined #css
22:03:34 <jdaggett> next discussion is font feature support in css
22:04:02 <szilles> szilles has joined #css
22:04:03 <jdaggett> original proposal: http://lists.w3.org/Archives/Public/www-style/2009Jun/0506.html
22:04:18 <jfkthame> so i'm hearing occasional bursts of sound on the phone, but lots of silence..... if you're discussing anything, i can't tell
22:04:28 <jdaggett> demo page: http://people.mozilla.org/~jdaggett/webfonts/features.html
22:04:52 <jdaggett> experimental build: http://people.mozilla.org/~jkew/ot-feature-build
22:05:20 <dbaron> ScribeNick: dbaron
22:05:23 <alexmog> alexmog has joined #css
22:05:24 <ChrisL> ChrisL has joined #css
22:05:26 <plinss> plinss has joined #css
22:05:32 <dbaron> jdaggett: Font feature support in CSS.
22:05:44 <dbaron> jdaggett: Many opentype fonts have additional glyph sets in the font.
22:05:55 <howcome> www.princexml.com also supports font features
22:06:01 <dbaron> jdaggett: They have variations to support various types of ways of rendering text.
22:06:23 <dbaron> jdaggett: I'll show demos using an experimental build of Firefox.
22:07:19 <dbaron> jdaggett: Demo of 'font-variant: small-caps' with shrunk capitals vs. small cap glyphs in the font.
22:08:23 <dbaron> jdaggett: Second demo with "MEgalopolis Extra" font:  alternate glyphs, discretionary ligatures, alternates and ligatures.
22:09:08 <dbaron> (Q about whether selection works; demo)
22:09:32 <dbaron> jdaggett: third demo: contextual substitution of opentype fractions
22:11:49 <dbaron> jdaggett: fourth demo, Coluna font, old style figures by default (numbers have descenders), but options for lining (no descenders), tabular (all digits same width), lining+tabular
22:12:30 <dbaron> jdaggett: Some proposed extensions to font-variant; URL above ("original proposal")
22:12:46 <TabAtkins> TabAtkins has joined #css
22:12:53 <dbaron> jdaggett: font-variant would become a shorthand for font-variant-{ligatures,alternates,caps,numeric,position}
22:13:19 <jdaggett> http://people.mozilla.org/~jkew/ot-feature-build
22:13:25 <dbaron> jdaggett: In WPF, Microsoft has implemented ...
22:13:30 <jdaggett> http://msdn.microsoft.com/en-us/library/ms745109.aspx
22:13:31 <sylvaing> sylvaing has joined #css
22:14:35 <dbaron> ligatures: common, additional, historical
22:14:45 <dbaron> alternates: normal, contextual, styleset #, swash #
22:14:52 <dbaron> caps: normal, smal-caps, pettie-caps, titling-caps
22:15:03 <dbaron> numeric: normal, lining, oldstyle, tabular, proportional, fractions, ...
22:15:10 <dbaron> position: normal, subscript, superscript, ruby, ...
22:15:18 <dbaron> s/historical/historical, .../
22:15:24 <fantasai> fantasai: what happens if the font doesn't have a subscript variant?
22:15:39 <fantasai> jdaggett: you get the regular glyph
22:15:48 <dbaron> jdaggett, also ones for CJK alternates, need to do more research about them to figure out what's needed
22:15:48 <fantasai> jdaggett: you could argue that some of these shouldn't be here ...
22:15:56 <dbaron> s/jdaggett,/jdaggett:/
22:16:11 <fantasai> dsinger: If I request subscripts, and get regular figures, that changes the semantics
22:16:14 <dbaron> dsinger: If the font doesn't have subscript, I'll get inline figures which changes the semantics
22:16:30 <dbaron> jdaggett: This is just saying "give me that glyph", not "change the baselien"
22:17:08 <dbaron> dbaron: Is it that the fonts have different glyphs for "when used as a subscript"?
22:17:19 <dbaron> dbaron: And you'll still get subscript size/positing if they don't have that?
22:18:28 <dbaron> ChrisL & dsinger: bad failure modes for getting double-subscript or none at all
22:18:36 <fantasai> s/for/are/
22:18:45 <dbaron> jfkthame: If the semantics are important, people should be using sup/sub elements
22:19:15 <dbaron> jfkthame: The opentype features of superiors or inferiors aren't really a first-class replacement for that.
22:19:30 <dbaron> jfkthame: If you request the feature and the font doesn't support it, you'll get no change.
22:19:57 <dbaron> jfkthame: Intended more for footnote numbers, numeral suffixes
22:20:07 <dbaron> fantasai: But if we have this feature people will use it for semantic subscripts.
22:20:36 <dbaron> fantasai: And then for somebody else who doesn't have the font, the user won't see the superscript/subscript.
22:20:38 <fantasai> because the currently faking it is ugly
22:21:05 <dbaron> jdaggett: I'll note this as an issue and look into it.
22:21:49 <dbaron> jdaggett: small-caps has issue being existing value
22:22:04 <mmielke> mmielke has joined #css
22:22:15 <dbaron> alexmog: I want all my subscripts to do the typographically correct thing, but I never want the effects to multiply.
22:22:48 <dbaron> SteveZ: small-caps has two effects ...
22:22:53 <glazou> rrsagent, this meeting spans midnight
22:23:02 <dbaron> SteveZ: some of these are mutually exclusive
22:23:10 <dbaron> jdaggett: yes, the proposal goes into that in detail
22:23:40 <mmielke> mmielke has joined #css
22:23:46 <dbaron> (shows 0506.html)
22:24:16 <dbaron> jdaggett: Shows old-style numerals vs. lining numerals
22:24:34 <dbaron> jdaggett: Demo: swash characters in Garamond Premier Pro
22:24:43 <dbaron> jdaggett: ... and additional ligatures
22:25:12 <dbaron> jdaggett: Opentype has language-sensitive rendering.  Demo for Macedonian.
22:25:52 <dbaron> alexmog: yes, that looks more Macedonian.
22:26:21 <dbaron> jdaggett: important not to ligaturize fi in Turkish so that dotted and dotless i can be distinguished
22:26:35 <dbaron> jdaggett: Demo: Also small-caps distinctions for Turkish.
22:27:22 <dbaron> jdaggett: example of lots of features at once
22:27:29 <dbaron> tantek: That also looks like copyfitting.
22:27:40 <dbaron> jdaggett: OpenType has the ability to specify a script and a languag.
22:27:48 <dbaron> jdaggett: But it's not precisely a language, it's a language system.
22:27:57 <tantek> would be great to get a URL to the "lots of features at once" example
22:28:20 <dbaron> jdaggett: But you can display Greek in the French way of displaying Greek.
22:28:36 <dbaron> jdaggett: So one might want a way of choosing the typographic language separately from the language.
22:28:49 <dbaron> fantasai: As long as the default is 'auto' and that uses the markup language.
22:29:10 <dbaron> (Turkish demo was using 'calluna' font.)
22:29:35 <dbaron> jdaggett: Style sets get kind of hairy, having the number.
22:29:44 <TabAtkins> tantek: http://people.mozilla.org/~jdaggett/webfonts/features.html, page to the end
22:29:51 <dbaron> jdaggett: This is the argument we've been having on the list... what happens in the fallback case.
22:30:07 <dbaron> jdaggett: You're not going to get unreadable text, you just won't get what the author hoped for.
22:30:23 <dbaron> jdaggett: Or you could say some of these apply only to the first font in the list.
22:30:42 <tantek> TabAtkins - interesting, in an old nightly of Webkit - the text is *not* copyfit - so this tells me that the OpenType features may be making use of some copyfitting feature somewhere?
22:30:48 <dbaron> ChrisL: That could have issues if you're using a font list to get good Latin from one font plus good Japanese from the second font, you might want properties for the Japanese font.
22:31:09 <dbaron> jdaggett: Doing something fancy... but that has the problem of an author having trouble figuring out what happened.
22:31:24 <tantek> TabAtkins - n.m. just viewed source - each line's font-size is set explicitly.
22:31:34 <dbaron> fantasai: Leave swash in as a keyword, so you can just get the first one.
22:31:43 <tantek> for reference: http://people.mozilla.org/~jdaggett/webfonts/features.html#page%2014
22:31:48 <TabAtkins> tantek: Yah, just wait a bit and we'll hit the copyfitting issue.  ^_^
22:32:30 <dbaron> jdaggett: We could add a font-variant descriptor for @font-face that would only apply the features to that specific face.
22:32:50 <dbaron> jdaggett: I like the idea of allowing that, but I don't like the idea of requiring it.
22:33:10 <dbaron> Håkon: There's pain to dealing with several @font-faces, but it's a neat way of achieving what we want.
22:33:20 <Bert_lap> -> http://people.mozilla.com/~jkew/feature-samples/MEgalopolis.html The multi-feature, justified example with MEgalopolis from the slides
22:33:21 <TabAtkins> In the font-variant-* properties, use a functional notation to target it at specific fonts.
22:33:29 <dbaron> Håkon: I'm tempted to go down the @font-face route, even if it's a little inconvenient sometimes.
22:33:46 <dbaron> jdaggett: I think it's impractical because you'd have so many permutations that it's impractical to use @font-face rules
22:34:10 <TabAtkins> font-variant-ligatures: font-face("foo",lig 1), lig 2
22:34:27 <TabAtkins> ^^^ Would activate lig2 on all fonts, but lig1 only on "foo" font.
22:34:30 <dbaron> fantasai: I'm saying a property is fine for most of these, but require it in @font-face for alternate glyphs, which are very specific (by number) to fonts.
22:34:52 <ChrisL> rrsagent, this meeting spans midnight
22:35:23 <dbaron> SteveZ: In that list, there are only 2 things taking numeric values:  style sets and alternates.  Treating those two differently from all the others makes perfect sense.
22:35:36 <dbaron> SteveZ: And, secondly, those are the two places where things are much more font-specific.
22:36:01 <dbaron> SteveZ: So I would argue that I'd introduce a property: one for style sets and one for alternates, where the property would take...
22:36:09 <dbaron> Steve: ... a font and a style set number that goes with that font.
22:36:52 <dbaron> SteveZ: So you'd match which element in the list corresponded to the font actually chosen.
22:36:58 <dbaron> s/Steve:/SteveZ:/
22:37:13 <dbaron> Håkon: You're proposing two new properties with comma-separated values?
22:37:15 <dbaron> SteveZ: yes
22:37:42 <dbaron> TabAtkins: font-variant-ligatures: font-face("foo",lig 1), lig 2
22:38:14 <dbaron> jdaggett: Originally I had a functional syntax, but people said we don't really have that.  I think a functional syntax would work just as well.
22:38:41 <dbaron> dsinger: It seems like you'd only have an explosion of @font-face rules if you have an explosion of styles on the page, which often isn't a good thing.
22:39:04 <dbaron> jdaggett: @font-face is just defining one face of a family:  So you'd then have to define all these variations across all faces of the family.
22:39:38 <dbaron> SteveZ: If I want to write a description of 18th century typography in English... historical ligatures, historical letterforms... which I only want to use in examples.
22:40:14 <dbaron> dsinger: You're probably using a different font for the 18th century text.
22:40:32 <dbaron> dsinger: The features would be consistently off in the modern text and on in the 18th c. text.
22:40:45 <dbaron> SteveZ: It's perfectly reasonable that I'm using an 18th c. font for my body text.
22:41:00 <dbaron> fantasai: It doesn't matter how many features you're turning on and off.
22:41:09 <dbaron> SteveZ: Each paragraph would have different features on it.
22:41:13 <dbaron> fantasai: That's a very special edge case.
22:41:31 <fantasai> SteveZ: Because I'm writing about typography
22:41:44 <dbaron> dbaron: Writing about typography is an edge case.
22:42:04 <dbaron> dsinger: If you're actually showing lots of faces, that's not a failure of CSS.
22:42:43 <dbaron> jdaggett: That's against the way CSS works, because you're forcing everything into @font-face rules, and people don't have the ability to change specific properties.
22:42:53 <dbaron> jdaggett: You've eliminated inheritance.
22:43:41 <dbaron> dsinger: But then you're asking for a feature in a font that you might not be using.
22:43:53 <dbaron> ...
22:44:15 <dbaron> dsinger: I don't mind changing what it looks like, but I mind changing the meaning.
22:44:29 <dbaron> jdaggett: It's not undermining fallback, it's still an "a".
22:45:25 <dbaron> jdaggett: 3 options, let substitution occur, (2) apply only to first font (3) put feature variants into @font-face, (4) Steve's property that takes family name
22:45:36 <glazou> shepazu: ping
22:46:02 <glazou> $
22:46:11 <ChrisL> ChrisL has joined #css
22:46:14 <dbaron> fantasai: Issue of mixing Latin font with Chinese font and choosing alternatives in both.
22:46:26 <dbaron> jdaggett: I like the idea of allowing features to be set in @font-face, but I don't like it being the only mechanism.
22:46:38 <dbaron> Håkon: You could combine (2) and (3).
22:47:04 <dbaron> jdaggett: The complication that these are all shorthands:  set all other values to default.
22:47:56 <dbaron> SteveZ: My proposing allows a list that includes fonts that aren't being used... reduces that problem.
22:48:06 <ChrisL> szilles proposal does not suffer from that
22:48:32 <dbaron> Håkon: There's basically a scripting language underlying that... similar to text-replace.
22:48:40 <dbaron> jdaggett: But that's all *inside* the font.
22:48:49 <glazou> text-replace lalala lalala :-)
22:48:53 <dbaron> Håkon: But you can turn those features in the font on and off using this mechanism.
22:49:45 <dbaron> Steve: Fonts gave you that problem, even without variants.
22:50:03 <dbaron> ChrisL: That's how people used to do Greek in Web pages.
22:50:12 <Bert_lap> (People in India are still doing this, using fonts with Indic glyphs in ASCII slots...)
22:50:57 <dbaron> jdaggett: I think that's all I have... I just wanted to present this.
22:51:07 <dbaron> jdaggett: I think there's more that needs to be hashed out.
22:51:33 <dbaron> ChrisL: You were demoing with a special build.
22:51:56 <dbaron> jdaggett: Yes, that build just has a single property demo hack to turn off opentype features by name.
22:52:15 <dbaron> SteveZ: I'd like some action to come out of this discussion.  (1) Do people think that John is on the right track?
22:52:21 <dbaron> ChrisL, fantasai: yes
22:52:36 <tantek> tantek has joined #css
22:52:53 <ChrisL> I'd like to see this put into the spec
22:53:19 <dbaron> Bert: I'm happy to see more attention to typographic features; I've always wanted tabular figures; but I'm wondering why suddenly this attention for putting every opentype feature into CSS when we still don't have hyphenation and leaders.
22:53:39 <dbaron> jdaggett: We're not talking about every opentype feature; a fair number have been omitted.  e.g., not exposing multiple ways of doing fractions.
22:54:09 <dbaron> fantasai: hyphenation's also hard because of need for dictionary
22:54:27 <dbaron> jdaggett: Hyphenation is a somewhat tricky problem:  language-based, and all sorts of typographic rules for hyphenation.
22:54:35 <dbaron> ChrisL: These are orthogonal features.
22:54:42 <dbaron> Håkon: We have hyphenation specced out.
22:55:05 <fantasai> s/e.g. We're taking some features that are more abstract. Also not, e.g./
22:55:23 <dbaron> Bert: Prince now has the whole-paragraph justification from TeX, but Mozilla will have swash characters but still won't do justification right.
22:55:36 <dbaron> Bert: Things like proper justification and hyphens have a much bigger effect.
22:56:25 <dbaron> dbaron: those are layout features, adding to an area of CSS that's already very complicated.
22:56:31 <dbaron> fantasai: font features are better encapsulated
22:56:44 <dbaron> jdaggett: And having @font-face gives us the opportunity to do more with fonts now.
22:57:18 <dbaron> SteveZ: The other thing I'd want is getting a clear statement of how things like subscripts and small-caps interact with existing facilities: so that (a) we don't get semantic changes and (b) ...
22:57:30 <dbaron> dsinger: yep
22:58:03 <dbaron> jdaggett: font-variant is part of the 'font' shorthand; we don't want any of this new stuff in the 'font' shorthand
22:58:33 <jdaggett> Zakim, you silly git...
22:58:33 <Zakim> I don't understand 'you silly git', jdaggett
22:59:02 <ChrisL> zakim, you suspect wrong. Stop doing that. You are thinking outside your pay grade
22:59:02 <Zakim> I don't understand you, ChrisL
22:59:08 <dbaron> Håkon: John, if we have a property that holds the features, do you see that as inherited independent of font-family?
22:59:18 <dbaron> jdaggett: Yes.  It makes sense for many things, e.g., tabular figures.
22:59:25 <dbaron> Håkon: Should a randomly-named feature inherit?
22:59:40 <dbaron> jdaggett: I don't even have a plan for including enabling/disabling arbitrary features.
22:59:57 <dbaron> jdaggett: I'm not keen on writing a spec for that, at least initially.
23:00:19 <dbaron> Håkon: When I said I wanted to go down the @font-face route, I meant that only for arbitrary features, not for features that we standardize.
23:00:32 <dbaron> Håkon: For the features we standardize, I think we should absolutely have properties that work the normal way.
23:00:38 <dbaron> SteveZ: So it sounds like we're mostly in agreement.
23:00:50 <dbaron> ChrisL: So we can start moving this stuff into the spec?
23:01:04 <dbaron> jdaggett: I still don't have a sense of the alternates...
23:01:24 <dbaron> ChrisL: I think it's time to start moving it into a spec now.
23:01:28 <dbaron> fantasai: I agree with that.
23:01:34 <dbaron> ChrisL: exposes it to more people, get wider review
23:01:48 <dbaron> jdaggett: Still not confident of ...
23:01:54 <dbaron> dbaron: Put big red issues in the spec so people know.
23:02:02 <fantasai> fantasai: That's why we have class="issue" :)
23:02:08 <ChrisL> Don't let that put you off. Lets get it into the spec
23:02:35 <dbaron> Topic: multicol
23:02:44 <dbaron> Håkon: Yes, I want to advance it.
23:03:04 <dbaron> Peter: So all the comments have been addressed?
23:03:08 <dbaron> Håkon: yes
23:03:14 <dbaron> fantasai: Do you have a disposition of comments?
23:03:18 <dbaron> Håkon: It's linked from the wiki page.
23:03:39 <howcome> http://dev.w3.org/csswg/css3-multicol/last-call.html
23:04:43 <dbaron> ChrisL: What are the uncolored rows?
23:04:46 <Zakim> -[Mozilla]
23:04:56 <dbaron> Håkon: They're not really comments, just questions.
23:05:03 <dbaron> ChrisL: put that in the grid at the top
23:05:15 <dbaron> ChrisL: Sylvain, could you send email about whether you're ok with that resolution.
23:05:23 <dbaron> Håkon: The other orange... he sent a message saying it was ok.
23:05:58 <dbaron> fantasai: I disagree with Håkon's disagreements.
23:06:42 <dbaron> Håkon: I'm happy to change.
23:06:49 <dsinger> comment #1: change "coing" to "going"
23:06:58 <dbaron> Daniel: some green rows have no action
23:07:06 <dbaron> Håkon: didn't result in changes
23:07:13 <dbaron> Daniel: so put "no changes needed"
23:08:23 <dbaron> Daniel: Don't use "white".  Use "green".
23:08:47 <Kangchan> Kangchan has joined #CSS
23:08:56 <Kangchan> Kangchan has left #CSS
23:10:44 <dbaron> ChrisL: Also need CR exit criteria.
23:10:49 <dbaron> fantasai: We have boilerplate for that.
23:10:57 <dbaron> Håkon: Should I prepare a CR draft then?
23:11:04 <dbaron> Bert: Yes, everything except the status.
23:11:22 <Zakim> -Hakon_Lie
23:11:22 <dbaron> fantasai: Bert can take care of the status right before publication.
23:11:29 <dbaron> RESOLVED: Advance css3-multicol to CR
23:11:45 <dbaron> Zakim, who is on the phone?
23:11:45 <Zakim> On the phone I see Salon_9
23:11:52 <glazou> #howcome { color-replace: white green; }
23:11:57 <Zakim> -Salon_9
23:11:57 <Zakim> Styl_CSS-FP(TPAC)12:00PM has ended
23:11:58 <Zakim> Attendees were Hakon_Lie, Salon_9, [Mozilla]
23:12:30 <ChrisL> zakim, remind us in 3 hours to go home
23:12:30 <Zakim> ok, ChrisL
23:13:06 <dbaron> <break duration="17min" />
23:19:23 <dethbakin> dethbakin has joined #css
23:20:03 <glazou> glazou has joined #css
23:31:51 <glazou> glazou has joined #css
23:35:25 <smfr> smfr has joined #css
23:36:03 <dsinger> zakim, you should have told us that break is over
23:36:03 <Zakim> I don't understand you, dsinger
23:41:38 <bradk> bradk has joined #css
23:41:38 <dethbakin> dethbakin has joined #css
23:44:11 <fantasai> ScribeNick: fantasai
23:44:17 <fantasai> Topic: grid, flexbox, css3-layout
23:44:55 <tantek> tantek has joined #css
23:45:14 <fantasai> Alex: Are there specific issues about these specs being inconsistent, overlapping, etc?
23:45:22 <Arron> Arron has joined #css
23:45:24 <fantasai> glazou: THe issue is that these specs are in limbo for 2 years
23:45:39 <fantasai> Tab: I added it to see if there is any way to unify the concepts, esp. between template, flexbox, and tables
23:45:55 <fantasai> Tab: These are 3 separate ways of dealing with layout, was wondering if we can combine them
23:46:09 <fantasai> dbaron: Tables have so many backwards-compatibility constraints that you probably don't want to do that
23:46:36 <fantasai> Alex: Flexbox is the first concept of layout that is completely independent of the rest of CSS
23:46:44 <fantasai> ...
23:46:53 <fantasai> Alex: There are two exceptions to that: table and flexbox
23:47:00 <fantasai> Alex: each uses its own algorithm to do layout
23:47:11 <fantasai> Alex: Which keeps its really simple: only layout concepts of this model apply
23:47:15 <fantasai> Alex: It's awesome
23:47:23 <fantasai> Alex: It's cool if this same model applies to something else
23:47:44 <fantasai> Alex: If it can be added as its own model without added any complexity of interference with other features
23:47:56 <fantasai> Tab: So you prefer the layoud modes bein completely separate from each other?
23:48:03 <fantasai> Markus: Depends on how you want to apply it
23:48:12 <fantasai> Markus: Flexbox is great for layout
23:48:18 <fantasai> Markus: Then use flow layout for the content inside
23:48:22 <fantasai> Alex: yes, I prefer different models separate
23:48:37 <fantasai> Alex: We can certainly discuss how this applies to CSS, where mostly everything applies to everything in combination
23:48:41 <fantasai> Alex: This is great for flow content
23:48:50 <fantasai> Alex: but the there are other systems like Silverlight, WPF, etc.
23:48:58 <fantasai> Alex: Where most layout models are self-contained and independent
23:49:07 <fantasai> Alex: Everyone has hits own model and it's extensible, you add a model
23:49:25 <fantasai> Alex: Is it good to go forward to have both system in CSS .. and ad flexbox and add somethign else and add something else... I don't know
23:49:56 <fantasai> Alex: I think the existence of flexbox as something separate is good. I would be worried if we tried to integrate with regular CSS layout
23:50:01 <fantasai> Tab: Ok, seems reasonable
23:50:14 <fantasai> Alex: Flexbox is a parent that has complete control of its descendents (?)
23:50:20 <fantasai> Alex: The model of the ocntainer overrides the contents
23:50:30 <fantasai> Alex: Abspos has that kind of gray area
23:50:47 <fantasai> Tab: That makes sense, esp within the context of flexbox
23:50:51 <fantasai> Tab: Jumping over to template
23:50:57 <fantasai> Tab: we have some definite parallels with how tables work
23:51:08 <fantasai> Tab: Might makes sense to align 
23:51:20 <fantasai> Tab: E.g. apply table border concepts to template slots
23:51:40 <fantasai> Tab: Do we want to redesign this, or treat them as applying to both
23:51:49 <fantasai> Peter: things like border-collapse could apply to flexbox too
23:51:58 <fantasai> Tab: Anytime I use a table, I'm almost always border-collapsing
23:52:09 <fantasai> Tab: I think most times for templates I'd want to collapse the borders
23:52:24 <CesarAcebal> CesarAcebal has joined #css
23:52:55 <fantasai> fantasai isn't sure if that's the case, a lot of designs put margins around their boxes
23:53:08 <fantasai> Tab: I think the biggest problem is making sure the drafts have some life into them
23:53:15 <fantasai> Tab: All three are extremely important to me as a web design
23:53:29 <fantasai> Tab: Static design right now is workable, but bloats my markup and requires many compromises
23:53:50 <fantasai> Tab: I would make many sites faster and easier if I had layout modes like flexbox and template, and even tables now that they're implemented widely
23:54:01 <fantasai> Tab: I want these specs to move and be implemented well so I can use them in a few years
23:54:13 <fantasai> Bert: For the spec writing part of that, I've been thinking it should be possible to merge grid and template together
23:54:25 <fantasai> Bert: flexbox is different, but some can also be used with template and grid
23:54:42 <fantasai> Bert: I was thinking to put them in all in one spec. What to do with flexbox display values they are rather separate
23:54:48 <fantasai> Bert: But the flex property can be applied to other things
23:55:10 <fantasai> Tab: That makes sense I think. Grid matches really well with template
23:55:18 <fantasai> Tab: Grid positioning basically does a static template
23:55:30 <fantasai> Tab: Template just has some extra magic with slot pseudo elements
23:56:16 <fantasai> fantasai: There are some things you can do with grid that you can't do with template
23:56:48 <fantasai> fantasai: Although template would be better for some of the examples Alex had, last time he showed some interesting examples
23:56:54 <fantasai> (they are minuted in the last F2F minutes)
23:57:06 <fantasai> Alex describes some things you can do with grid and .e.g multicol interactions
23:58:05 <fantasai> fantasai: Another thing about grid is that it creats a grid that you can use to align things
23:58:10 <fantasai> fantasai: have a snap-to-grid feature
23:58:16 <fantasai> fantasai: That you could use for flow content
23:58:30 <fantasai> fantasai: e.g. say this box should fit its content, but should snap to the grid
23:58:36 <fantasai> fantasai: and you adjust the margins to make that happen
23:58:38 <fantasai> ...
23:58:45 <fantasai> Bert: I wanted to do abspos the right way.
23:59:01 <fantasai> Bert: You want to position not by numbers, but say "this is next to that", and "this is just as tall as that"
23:59:08 <fantasai> Bert: I wanted to have that abstraction there.
23:59:12 <glazou> hum hum http://daniel.glazman.free.fr/weblog/position__new.html
23:59:20 <fantasai> Bert: you can put any element anywhere, but they align to each other
23:59:45 <fantasai> Markus: I'm not sure we should merge them
23:59:52 <fantasai> Markus: They each have their use cases
00:00:00 <fantasai> Markus: Grid is very much a pixel-perfect wireframe thing
00:00:07 <smfr> grid: http://www.w3.org/TR/css3-grid/
00:00:08 <fantasai> Markus: I think if we merge them, we might lose the original use cases
00:00:14 <fantasai> Markus: I see the benefit of what you say
00:00:20 <smfr> template layout: http://www.w3.org/TR/css3-layout/
00:00:41 <fantasai> ...
00:00:58 <fantasai> Markus: Grid was intended to be a positioning system over whatever positioning scheme you use
00:01:20 <fantasai> ...
00:01:33 <fantasai> Alex: could just as well be the other way, the grid defined as a side-effect of something else, e.g. a template
00:01:52 <fantasai> Alex: Currently it's explicit, but it doesn't have to be
00:02:05 <fantasai> shepazu: Have you guys talked about a fallback mechanism?
00:03:01 <fantasai> Alex: I'm not sure it makes sense to do fallback at the property level, you'd probably need an entirely separate style sheet
00:03:13 <fantasai> shepazu: What about for authoring tools?
00:03:34 <fantasai> glazou: Depends on if you need to preserve ... relation of prose
00:03:58 <fantasai> glazou: If I used this I wouldn't care about legacy browsers
00:04:27 <fantasai> shepazu asks when can browsers be relied on to support this stuff
00:06:01 <fantasai> fantasai: You'd need a media-query-like thing
00:06:08 <fantasai> fantasai: for something like this
00:06:58 <fantasai> shepazu: Yes. Is that a stupid question?
00:07:01 <fantasai> glazou: No, it's important
00:07:07 <fantasai> glazou: This has come up many times before
00:07:14 <fantasai> (shift that sentence up 2)
00:07:18 <fantasai> ...
00:07:25 <fantasai> shepazu: It's come up in dom3 events
00:07:34 <fantasai> shepazu: Before, hasFeature only worked on a very gross level
00:07:47 <fantasai> shepazu: e.g. do you support Mouse Events?
00:08:01 <fantasai> shepazu: if you support 5 events and not 1, then can you say you support them?
00:08:17 <fantasai> shepazu: It's very hard to say at a group level whether a feature is supported
00:08:42 <fantasai> shepazu: but if you have granularity, do you support this aspect of grid, then it's much easier to get an accurate response from the browser
00:08:47 <fantasai> Tab: You'd still run into bugs
00:08:57 <fantasai> Tab: That's something that JS-based feature testing can do
00:09:01 <Kai> Kai has joined #css
00:09:15 <fantasai> Tab: Maybe you just defer to JS 
00:09:23 <fantasai> Brad: Then JS has to be turned on
00:11:29 <fantasai> fantasai, glazou: testing at the property: value level is probably good enough
00:11:38 <fantasai> fantasai: If you need to detect specific bugs, then use a JS library
00:11:48 <fantasai> fantasai: but at the property: value level, then it's probably usable
00:12:10 <fantasai> fantasai: it's unlikely a browser would lie about hat
00:12:32 <fantasai> Peter: back on target
00:12:56 <fantasai> Tab: Personally I like the idea of template being built on top of grid and aligning a grid onto a box
00:13:08 <fantasai> Tab: Then you can align other boxes onto that grid (????)
00:13:14 <fantasai> Tab: But it works the other way for tables ...
00:13:30 <fantasai> Alex: I don't think merging the specs would help to resolve these questions
00:13:39 <fantasai> Alex: I prefer keeping it separate as a coordinate system
00:13:42 <fantasai> Alex: doesn't say what you use it for
00:13:45 <fantasai> Alex: or where it's coming from
00:13:48 <fantasai> Alex: Just defines a grid
00:13:54 <fantasai> Alex: make sesnse and can be implemented
00:14:00 <fantasai> Alex; they don't have to merge to be able to interact
00:14:05 <fantasai> Tab: The only problem I have
00:14:15 <fantasai> Tab: Is if you have e.g. on the body both a template and a type grid
00:14:55 <fantasai> fantasai: I think you should be able to have multiple grids on a element, name them, and be able to align differnet things to different grids
00:15:05 <fantasai> Markus: Keeping the specs separate also makes implementing easier
00:15:07 <fantasai> faster
00:15:20 <fantasai> Tab: I think multiple grids is useful and important
00:15:34 <fantasai> Tab: And should be addressed if we want grid and template to interact nicely
00:15:45 <fantasai> shepazu: While I appreciate your case, just from a deployment standpoint,
00:15:57 <fantasai> shepazu: I'd rather see something like this implemented at a simple level
00:16:03 <fantasai> shepazu: Than talk about how to merge them
00:16:21 <fantasai> shepazu: It seems to me that grid is solving a lot of cases designers care about
00:16:33 <fantasai> shepazu: slowing it down to add templates doesn't seem like a good idea
00:16:38 <fantasai> Tab: I want template to be done
00:16:45 <fantasai> shepazu: I don't know template as well  :)
00:16:52 <fantasai> Tab: A table defines its grid along its borders.
00:17:00 <fantasai> Tab: A type grid, you align your table cells along that grid
00:17:06 <fantasai> Tab: you give the table width and height to that grid
00:17:12 <fantasai> Tab: In that case you want multiple grids
00:17:18 <fantasai> Tab: you'll be introducing other grids along the way
00:17:23 <fantasai> Tab: I think it's useful to do so
00:17:31 <fantasai> Tab: but you still want to maintain access to your original type grid
00:17:41 <fantasai> Markus: To move these specs forward.. what are you asking for?
00:17:58 <fantasai> Tab: Do you have specific feedback on this? Then we can look at your comments and address them and move forward
00:18:04 <fantasai> s/Tab/Markus/
00:18:13 <fantasai> Markus: or are you asking ... or are you asking just how they itneract
00:18:21 <fantasai> Tab: Right now there's a note in the spec saying that it interacts with other specs
00:18:26 <fantasai> Tab: And thats the area where I want more attention
00:18:39 <fantasai> Markus: TO move theses things forward, we need to go through the process to maek that happen
00:18:48 <fantasai> markus: Here that means working through the issues
00:19:05 <fantasai> Markus: If there are no issues, then we leave the note and do nothing
00:19:07 <fantasai> ...
00:19:21 <fantasai> Tab: The note suggests right now an interaction that I don't think is good
00:19:39 <fantasai> Alex: The note just says the interaction might not happen, removing it doesn't change anything.
00:19:52 <fantasai> Tab: If grid and table don't interact and there are no plans for it, I'd like to keep it that way
00:20:02 <fantasai> Alex: Maybe someone comes in and implements that.
00:20:20 <fantasai> Steve: I'm losing track of where this discussion is going
00:20:26 <fantasai> Steve: I don't see any concrete proposal to discuss
00:20:29 <fantasai> Tab: I'm getting there
00:20:52 <fantasai> Chris: I think the discussion start with "shouldn't we merge them because they do the same thing" and has gotten to "no they're doing different things" and now we should move on
00:21:08 <fantasai> Tab: If we're going for simplicity, I'd there not to be a suggestion that tables create a gird
00:21:20 <fantasai> Tab: I want it either removed, or something stating that it will be added later
00:21:22 <fantasai> motion to remove note
00:21:35 <fantasai> RESOLVED: remove note about interaction between grid and tables
00:22:14 <fantasai> Peter: While we're on the topic, can we get better traction on these modules?
00:22:29 <fantasai> Chris, to MSFT: You could ship your experimental implementation.
00:22:40 <fantasai> Steve: There are two things missing
00:22:57 <fantasai> Steve: One is an agreement that people will focus their attention on at least one particular one of the mechanisms and make some progress there
00:23:07 <fantasai> Steve: I tend to agree with Tab's comment that there are too many mechanisms there
00:23:18 <fantasai> Steve: There are too many, so people say there are too many, and I won't do anything
00:23:27 <fantasai> Steve: The lack of agreement on one thing everyone will try and do is one of the blocks.
00:23:42 <fantasai> Steve: Second thing is, esp with grid, there are open questions on syntax etc.
00:24:09 <fantasai> Steve: Some things talked about in 2007 that need to get addressed.
00:24:24 <fantasai> Steve: e.g. backwards intrusions of flaots
00:24:36 <fantasai> Alex: Grid invites that kind of positioning ...
00:24:46 <fantasai> Steve: syntax and sizing... 
00:25:00 <fantasai> Steve: Basically there are still open issues on grid
00:25:24 <fantasai> shepazu: experimental implementations would help
00:25:35 <fantasai> Bert: There are three prototypes for template
00:26:01 <fantasai> Bert: Cesar's JS implementation, a JQuery implementation, and Andrew's htmllayout implementation
00:26:20 <fantasai> shepazu: MSFT is interested in grid. Mozilla or Apple?
00:26:50 <fantasai> shepazu: Is it a matter of priorities, or a matter of not liking the technology?
00:27:40 <fantasai> dbaron: I don't know enough about the tech to answer
00:28:20 <fantasai> ACTION Alex: remove note from grid wrt table interaction sect 4.something
00:28:20 <trackbot> Created ACTION-192 - Remove note from grid wrt table interaction sect 4.something [on Alex Mogilevsky - due 2009-11-10].
00:28:26 <fantasai> Topic: run-in definition
00:28:47 <plinss> http://lists.w3.org/Archives/Public/www-style/2009Sep/0126.html
00:29:16 <fantasai> 4.2 and 4.3
00:31:30 <fantasai> dbaron motions to shift discussion to later, maybe get bz on the phone
00:31:35 <fantasai> bert would also like more time to prepare
00:31:59 <fantasai> steve: 9am?
00:32:21 <fantasai> resolved: move to 9am tomorrow
00:32:33 <fantasai> Topic: Size to Fit (for text)
00:33:40 <fantasai> Bert: it's basically to do what John was showing: make each line the same size
00:33:47 <fantasai> Bert: Useful for titles especially
00:33:55 <fantasai> Bert: Mostly used in advertisements
00:34:13 <Kai> Kai has joined #css
00:34:19 <fantasai> Bert: You make a block of text look like a block of text by varying font size until it fits
00:34:25 <fantasai> Bert: We had a proposals for that
00:34:46 <fantasai> Bert: It was given with last-line-align
00:34:51 <arronei> arronei has joined #CSS
00:34:51 <fantasai> Bert: and we had min and max font properties
00:36:48 <fantasai> fantasai doesn't understand why you would want to apply only to the last line
00:37:13 <fantasai> http://www.w3.org/TR/2003/CR-css3-text-20030514/#last-line-alignment-prop
00:37:16 <fantasai> 'size' value
00:37:34 <fantasai> fantasai: Why would you want only the last line at the bottom to blow up in size, even though the rest of the paragraph is a small type size?
00:41:40 <fantasai> fantasai: It should apply to all lines
00:42:16 <fantasai> someone argues that it's only one line of text
00:42:26 <fantasai> because of forced breaks
00:42:44 <fantasai> fantasai argues that on web pages, which are flex layout, you don't want to force breaks everywhere
00:42:58 <fantasai> the title should be able to adapt to the available space
00:43:18 <fantasai> and with css3-text's text-wrap: suppress, you can get the title to break in the appropriate places as the available space shrinks
00:44:02 <fantasai> in such a case, if you wanted each line to size up to fill, you'd want the sizing to apply to all lines
00:44:05 <fantasai> not just the last line
00:45:36 <fantasai> Steve discusses another case where you size up the whole paragraph
00:45:42 <fantasai> to fill space
00:46:03 <fantasai> ?
00:47:02 <dbaron> copyfit: none | size-each | size-largest 
00:47:02 <dbaron> text-justify-last: ...
00:48:15 <TabAtkins> You'd want a min/max size on the copyfit too, to avoid runaway craziness.
00:48:18 <fantasai> There was a discussion somewhere of a last-line-length
00:48:30 <fantasai> Which would trigger rejustification if the last line was too short
00:49:42 <fantasai> Peter: Another case is wanting to trigger justification on the last line or not based on how long it is; e.g. if it's 70% of the line, justify it, if it's only 2 words, left-align
00:49:54 <fantasai> fantasai: If I was adding this to the spec, I would add 'size' as a keyword to text-justify
00:50:01 <fantasai> fantasai: text-align: justify turns on justification
00:50:14 <fantasai> fantasai: text-justify specifies how you justify: which algorithm
00:51:57 <fantasai> ....
00:52:09 <fantasai> dbaron: There's been a bunch of discussion of changing the last line behavior
00:52:15 <fantasai> s/behavior//justification/
00:52:21 <fantasai> dbaron: and then discussion of changing the size of the text.
00:52:29 <fantasai> dbaron: These seem largely independent
00:52:36 <fantasai> dbaron: I suggested a copy-fit property
00:52:43 <fantasai> dbaron: one value is none, which is now
00:52:52 <shepazu> shepazu has joined #css
00:52:54 <fantasai> dbaron: One is size the largest thing to fill thes pace
00:53:02 <fantasai> dbaron: and then everything else size up to match
00:53:59 <fantasai> s/thing/line/
00:54:37 <fantasai> dbaron: the last one is to scale each line independently
00:55:45 <fantasai> dbaron: explicit letter-spacing happens before this, justification afterward
00:56:41 <fantasai> ACTION fantasai: Add this stuff as notes in css3-text
00:56:41 <trackbot> Created ACTION-193 - Add this stuff as notes in css3-text [on Elika Etemad - due 2009-11-10].
00:57:21 <fantasai> pierre: You often want to do this in certain ratios
00:57:33 <fantasai> mentions of character stretching and compression for justification
00:58:01 <shepazu> shepazu has joined #css
00:58:51 <fantasai> Steve: There are properties other than size that you'd want to tweak for this
00:59:43 <fantasai> Steve: Perhaps have a value to add to properties saying how much to tweak
00:59:44 <fantasai> or whether
00:59:55 <fantasai> dbaron: Not sure if we want this available on blocks or inlines
01:00:48 <fantasai> Tab: was thinking of chaining techniques, specify in detail how you want something justified
01:00:51 <fantasai>  ....
01:01:06 <fantasai> Steve: In InDesign the size of the window doesn't change
01:01:22 <fantasai> dsinger: right, you're designing for a specific size of paper for print
01:01:42 <fantasai> Tab: I think the techniques we're talking about right now are enough for cases where you want that effect. For a movie poster, you'd not use CSS
01:02:14 <fantasai> Bert: I made a collection of examples... trying to find it
01:02:45 <fantasai> Peter: I think that's it for the day
01:03:15 <tantek> http://wiki.csswg.org/planning/tpac-2009
01:03:32 <Bert_lap> http://www.w3.org/Style/Group/2009/Santa-Clara.html
01:03:42 <Bert_lap> http://wiki.csswg.org/planning/tpac-2009
01:04:48 <fantasai> Tantek: Color draft?
01:05:13 <fantasai> Steve: your issue with color, gamma paragraph?
01:06:09 <fantasai> ...
01:06:18 <fantasai> Steve: since I won't be here for that discussion
01:06:22 <fantasai> Steve: Don't break plugins
01:06:27 <fantasai> Steve: work with them to fix the problem
01:07:23 <TabAtkins> TabAtkins has left #css
01:09:03 <Bert_lap> -> http://www.w3.org/Style/Group/1999/10/copyfit-examples.html justifying by font size
01:10:39 <myakura> myakura has joined #css
01:15:48 <tantek> tantek has joined #css
01:21:06 <Kai> Kai has left #css
01:23:10 <myakura> myakura has joined #css
01:39:54 <jfkthame> jfkthame has left #css
02:12:31 <Zakim> ChrisL, you asked to be reminded at this time to go home
02:15:25 <Zakim> Zakim has left #CSS
02:17:52 <sylvaing> sylvaing has joined #css
02:20:11 <tantek> tantek has joined #css
02:20:54 <anne> anne has left #css
03:38:42 <mmielke> mmielke has joined #css
03:38:48 <Arron> Arron has joined #css
03:47:33 <jdaggett> jdaggett has joined #css
03:52:08 <mmielke> mmielke has joined #css
04:08:50 <dsinger> dsinger has joined #css
04:43:23 <mjs> mjs has joined #css
05:39:53 <TabAtkins> TabAtkins has joined #css
06:00:33 <fantasai> http://www.w3.org/Style/CSS/Specs/Read
06:34:24 <TabAtkins_> TabAtkins_ has joined #css
07:11:25 <shepazu> shepazu has joined #css
07:27:36 <TabAtkins> TabAtkins has joined #css
07:38:38 <TabAtkins_> TabAtkins_ has joined #css
07:54:23 <howcome> howcome has left #css