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