- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 08 Apr 2010 00:14:54 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Transitions and Animations
--------------------------
- Discussed approaches for animation of non-interpolatable properties.
Two solutions are possibles: stepwise timing functions, and
allowing transition-delay to apply to non-interpolatable properties.
- RESOLVED: Make all properties animatable. (non-0 values round to 1)
- RESOLVED: Accept stepwise timing functions, with modifications
suggested in minutes (step-start and step-end keywords,
plus steps(number,[start|end]) function)
- Discussed combining Transitions and Animations somehow. No conclusions
reached.
- Discussed reversing animations. This is clearly desired. Also discussed
filling other holes in the draft, such as animation-fill-mode.
- Some name changes were suggested, specifically animation-iteration-count
to animation-play-count (typability, understandability, and consistency
with marquee) and animation-duration to animation-period (avoid confusion
with total duration of animation).
Fonts
-----
- RESOLVED: accept jdaggett's proposal to use css3-fonts wording about
font-weight hole-filling in css2.1 since css2.1 wording misses
a few cases
http://lists.w3.org/Archives/Public/www-style/2010Feb/0279.html
- Wrt font variant, discussed and marked as issues
* whether 'all-small-caps' and 'all-petite-caps' were needed
* whether all-small-caps/all-petite-caps feature should be triggered
by 'text-transform: lowercase' + 'font-variant: small-caps/petite-caps'
* whether petite-caps fallback should be
a) lowercase
b) synthesized petite-caps
c) small-caps
- Discussed superscripts and subscripts, the 'character-transform' proposal
http://lists.w3.org/Archives/Public/www-style/2010Feb/0245.html
http://dev.w3.org/cvsweb/~checkout~/csswg/css3-fonts/Fonts.html?rev=1.34&
content-type=text/html;%20charset=utf-8#character-transform-prop
and how to handle stacked superscripts or subscripts. Steve Zilles outlined
a proposal to address this by the parent's font size to substitute or
synthesize the appropriate glyph.
- Re-discussed issue of font-specific feature selection. No conlusion
reached because John Daggett vehemently disagrees with requiring
font-specific features to be scoped to a specific font.
- dbaron introduced 'font-size-adjust: auto', which would give 'font-size-adjust'
the value of the ex-height of the user's default font, providing an easy
way to introduce ex-height calibration and a way to more accurately match
the user's effective default font size for bicameral scripts.
i18n
----
- Briefly reviewed the status of Ruby
CSS2.1 Issues
-------------
- Reviewed test results for CSS2.1 Issue 114. Straw poll indicates preference
for ident+ syntax for unquoted font-family names within the CSSWG, but SVGWG
also needs to be consulted.
http://wiki.csswg.org/spec/css2.1#issue-114
- RESOLVED: Proposal accepted for CSS2.1 Issue 163
http://wiki.csswg.org/spec/css2.1#issue-163
- RESOLVED: No change for Issue 162 (position of bullet should follow containing
block, not element, directionality). We already have strong interop
on the existing behavior, and the behavior makes sense for some
non-list use cases of display: list-item. We may consider more control
over this for CSS3 Lists.
http://wiki.csswg.org/spec/css2.1#issue-162
- Reviewed proposal for CSS2.1 Issue 161. Tab to write updated proposal.
http://wiki.csswg.org/spec/css2.1#issue-161
- RESOLVED: Add non-normative for-example sentence explaining whether the
first page of a document is :left or :right for CSS2.1 Issue 160.
http://wiki.csswg.org/spec/css2.1#issue-160
- Rediscussed pt vs. px issue proposal. Still no consensus. fantasai to write
specific wording for proposal. http://wiki.csswg.org/spec/css2.1#issue-149
~fantasai
======= Full minutes below ======
Agenda: http://wiki.csswg.org/planning/cupertino-2010
Present:
Tab Atkins
David Baron
Bert Bos
John Daggett [afternoon-only, via phone]
Beth Dakin
Tantek Çelik
Arron Eicholz
Elika Etemad
Simon Fraser
Sylvain Galineau
Daniel Glazman
Dean Jackson (Apple)
Brad Kemper
Jonathan Kew (Mozilla) [afternoon-only, via phone]
Håkon Wium Lie
Chris Lilley
Peter Linss
Chris Lye (Adobe)
Alex Mogilevsky
David Singer
Anne van Kesteren
Steve Zilles
Scribe: TabAtkins
Transitions and Animations
==========================
Transitions of non-animatable properties Part I
-----------------------------------------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2009Nov/0328.html
dbaron: Transitions spec currently has a special case for visibility.
dbaron: We may want to keep it despite this, but the idea for the special
case is the if visibility has a transition from 'visible' to
'hidden', it's considered to be a property that can transition,
where all intermediate states are transitionable.
dbaron: So if you're transition from visible to hidden, the transition
happens when a timing function ends.
dbaron: This makes sense if you're, say, shrinking something and then
want it to disappear entirely.
dbaron: Somebody wanted this to apply in other cases; in particular,
they were trying to convert the controls Gecko uses for HTML5
video, which has a number of animations.
dbaron: He was trying to do them using Transitions, but one thing that
happens is a display change. He wants to be able to transition
to display:none after an opacity transition happens.
dbaron: He ended up using the transitionend event, but he'd like to do
this just with the transition support.
dbaron: So what we think we might do is that, for non-animatable
properties, we don't have transition-duration support, but *do*
have transition-delay support.
smfr: So you'd take transition-delay into account, and just do an
instantaneous transition after that.
dbaron: If we did this, we might still want to keep this special rule
for visibility, because it's a little bit harder to do things
this way (you have to do delay for this one property rather
than a duration).
dbaron: With visibility, we know that people want visible in the middle,
but for other properties we don't know what people want in the
middle.
dean: The next topic is discrete timing functions, which would also
solve this and give you control over when the non-animatable
property transitions.
dbaron: Yeah.
dbaron: Are you saying you want to do it the delay way, or the stepwise
way, or both...?
dean: Your way.
smfr: But if you have stepwise timing functions, you don't necessarily
need a delay trick.
<smfr> step-wise timing function proposal:
http://lists.w3.org/Archives/Public/www-style/2010Feb/0212.html
dean: With a stepwise timing function, if you say something like "I only
want a change at the end of the transition", you can control when,
say, a display:none transitions.
dean: Basically I think we can make this decision *without* having to
worry about stepwise functions first.
dsinger: Right. We just need to decide if we fix the transition to
happen at the beginning or the end.
plinss: What about a transition from block to inline? There's no easy
answer for start or end.
smfr: Right, stepwise timing functions have a start and end transition
function, so you can decide which one to use.
dsinger: So if you're not using a stepwise timing function, 0 is start
and 1 end, and what do we do in the middle?
dbaron: I think the rule that's most compatible is to have all non-0
round to 1.
Reversing Transitions Part I
----------------------------
dbaron: Now most of the time people will want to be able to reverse
their transition, so that's a little hard. They'll have to make
two different declarations.
smfr: We talked about the issue of not getting symmetry by default,
and there's no easy solution I think.
dbaron: One thing that just occurred to me is that we could add a
property that says "reverse all the timing functions".
dbaron: So when people transition to a hover state, they can put this
property on the hover and make it work.
smfr: That gets into a weird bit of statefulness.
TabAtkins: Like what if you go to :hover and then click and activate an
:active transition.
smfr: How are you defining the states?
dbaron: Well, any change. :hover, :active, a class...
smfr: Tracking states kind of scares me.
dbaron: It requires the author to track states, not the implementation.
smfr: All the transitions are reversible, right?
TabAtkins: Yeah, but to do it right you have to set up, say, a :hover
and then a :not(:hover) rule.
Transitions of non-animatable properties Part II
------------------------------------------------
smfr: So I think we have two non-exclusive proposals.
smfr: One is to just let delay apply to all properties. The other is
to add stepwise timing functions.
TabAtkins: The stepwise includes making all properties respond to delay,
so I'm fine with just going all the way up and adding stepwise
timing functions.
TabAtkins: Is anyone opposed to adding the stepwise timing functions?
[silence]
anne: One question. The use-case we were looking at this morning was
transitioning a display:none as well other properties. It can be
solved with stepwise timings, but could we also do a
transition-start event to activate it?
anne: Another advantage of making them all animatable is that if we add
the ability to interpolate one of the non-animatable ones later,
we can just do it.
<smfr> http://lists.w3.org/Archives/Public/www-style/2010Feb/0212.html
RESOLVED: Make all properties animatable. (non-0 values round to 1)
Stepwise Timing Functions and Bezier Curves
-------------------------------------------
smfr: [explains full stepwise timing-function proposal]
smfr: You may want to control where an *animatable* property precisely
step, so you can have it step, say, halfway through, or control
how many steps take place.
smfr: A good example of this is the progress spinner on Mac OSX. It
doesn't smoothly rotate; it does 12 discrete steps, and we can't
do that right now with Transitions.
dean: We'd suggested a few things, like letting someone specify the
timing function curve as an SVG Path, but I think this proposal
hits the majority of cases very simply.
howcome: I like this stepwise function, but I don't know if I accept
the value of full control of a bezier curve. I think a few
keywords would just do it.
dean: [shows some example of where animation programs allow complex
control of a curve]
dean: Writing a bezier function by hand is hard, but it's easy to
understand when you see it.
howcome: Can we just say that if you want more control, just use SVG?
Keywords are the 90% function, right?
dean: Well, we *also* have the 90% solution; we keep the keywords.
But we also then add the bezier function.
glazou: I think this is an excellent first example of something in
CSS that can't be really hand-authored.
howcome: I get worried when we say we don't care about complexity.
dbaron: 99% of the implementation complexity is just implementing 'ease'.
Doing any other bezier curve is just plugging in four more numbers.
TabAtkins: This doesn't produce any long functions. A bezier is just
four numbers.
szilles: Can't we just have a list of xy pairs?
smfr: That allows too much possibility of getting things wrong,
accidentally defining invalid steps.
szilles: Sure, but you can do that with just the plain number in step-start().
TabAtkins: Do you think we *need* that degree of control over the
transition steps?
dean: What I like about the simple form we have is that you can leave
off the number entirely and it's very intuitive what happens.
dean: [gives an example of using a step-start function to animate a
second hand on a clock]
[some confusion about difference between step-start and step-end]
glazou: I would like it better with something like "steps(60) start"
or "steps(60,start)".
dean: Yeah, that's fine, but we also want an author to be able to do
the simple case without having to write much, like just "steps"
or "steps(start)".
<Bert> (I don't believe you can animate a rotation: rotate(0) and
rotate(360) look exactly the same, moving the box from one
to the other is a no-op, isn't it? And 60 steps of no-op is
still a no-op.)
glazou: No, they end up looking the same, but it's still a different thing.
Bert: Where is it specified that you transition the value of the
rotate function?
<smfr> http://www.w3.org/TR/2009/WD-css3-2d-transforms-20091201/#matrix-decomposition
dean: In the Transitions spec, there's a big section defining how
to animate Transforms.
Bert: If you had a rotate and a translate both?
dean: If the from state and the to state have the same transform
functions in order, you pick them up in order and transition
each one independently.
glazou: no, 360deg and 0deg are not the same ; we all wrote our first
draw-a-circle-on-screen program iterating from 0deg to 360deg
dean: If they don't match, you do the matrix decomposition and animate
that, which is defined in Transitions spec.
Bert: Still a bit confused about transitions when the start and end
state look the same.
dean: I think you're confused because you haven't read the transition
spec yet.
Bert: Does this apply to color as well? If you transition from an
rgba color to an hsl color?
smfr: Right now we define it as transitioning through rgb space.
dean: The problem is defining exactly how to transition the hue.
dean: But we may have control over this later.
dean: SMIL and SVG don't give you these controls either.
howcome: Some implementor told me there was some ambiguity.
dean: I think the spec might just say it in a single sentence or something.
dean: So, back to steps.
smfr: I'm happy with what daniel proposed ("steps() function")
dean: Maybe it should be step() instead, and we decide whether it
goes at the start or end?
glazou: Just do step-start and step-end, and then steps().
dean: Okay.
szilles: I think the usage of the words is inconsistent.
[step "start" and "end" referring to different things]
<anne> step() and step-delayed()
howcome: Perhaps we can just write it down now, and come up with a
better word later?
<bradk> align-steps(start|end)?
RESOLVED: Accept stepwise timing functions, with modifications
suggested in minutes (step-start and step-end keywords,
plus steps(number,[start|end]) function)
<Bert> Why 2 functions, why not just step(n) where n >= 1, 1 by default?
<Bert> (Actually, step(0) as the default is better, then n is the
number of intermediate steps.)
<Bert> (or stepS().)
<Bert> (If you want the possibility of unequal steps, you could do
steps(0%,0%,20%,50%,80%,85%,90%). But that may be unnecessary.)
+Tantek
Combining Transitions and Animations Part I
-------------------------------------------
<howcome> http://people.opera.com/howcome/2010/talks/03-csswg-cupertino-ta.html
howcome: Maybe I'm stupid...
howcome: In my mind, when I come to this [points to exmaple on screen]
I see transitions and animations being the same.
howcome: I think animations are *great* for CSS, but I think we need
to have the model clear. I don't think we've ever quite
discussed if this is the right model.
howcome: We should have *one* set of properties, *-duration,
*-timing-function, *-delay.
howcome: I wanted to do an animation and a transition, and I wanted
them to do the same thing. They're basically the same code,
except in one I specify a transition and in one I name an
animation.
howcome: There are some minor differences.
glazou: They're not minor. In transitions the start is defined from
context, not explicitly in the animation.
howcome: [shows Simon's example of combining transitions and animations]
howcome: In my head, it's arbitrary whether you write transitions or
animations.
dean: I will raise you a head and say "Well, margin and padding are
the same thing, so let's make them the same."
howcome: Good argument, but I could also say something about webfonts
being completely different. But we found a model where they
work together with local fonts.
dean: I think the major difference between transitions and animations
is that transition is an effect you have happen whenever styles
change, while animations are something you write specifically
to happen when you change something.
howcome: I don't grok that as being so different that you need separate
properties for it.
smfr: If you open that example in a legacy impl, the transition will
make it still move, just instantaneous. The animation one,
though, won't do anything.
smfr: I think it would be useful to add an iteration-count to the
animation and see how it compares with transitions.
dean: dbaron raised the point on the list that you run into a cascade
clash. In most cases you want to control transitions as a
separate thing, separate from animations.
dean: [dbaron's issue of additive cascade]
dean: frex, for a transition you might want everything in a document
to transition. You can say "* { transition-duration: 1s; }"
and everything does it, no further difficulty.
dbaron: I wrote a strawman syntax proposal on the list that I didn't
particular like.
dbaron: I think I'm in the middle of you guys. I think the cascade
thing is something we need to solve a general. We need a way
to do additive cascading.
dbaron: Combining them together makes it a little bit worse in this
case, but it's already a problem.
dbaron: My strawman idea for combining them is - all the transition
properties have an animation sibling, except
transition-property and animation-name.
dbaron: Drop the individual properties, have a combined one that
takes a function for either a transition property, or an
animation name.
dean: That doesn't solve anything, it just maintains the current
separation with a functional syntax.
TabAtkins: It does partially address howcome's issue, in that it
would eliminate 3 nearly identical properties.
smfr: Is that a problem, though?
howcome: I think it is.
smfr: I think there's a fundamental difference there.
smfr: Transitions kick off when CSS properties change for any reason.
TabAtkins: [puts up an example of how transitions work]
plinss: I agree that there are enough similarities that it's *possible*
to define animations as a type of transition, or vice versa,
but I'm not sure it's worthwhile.
howcome: I think that's the key question. I want to raise awareness
in the room about that possibility.
szilles: One thing that struck me is that Transitions are parametrized
with the old value and new value. In the Animation, you've
stuck in a specific value, but the transition has a "variable"
of whatever the start and end values.
smfr: I also think you're missing is that Animations can have multiple
properties.
plinss: Right, so if you key it to Transitions, you could have an
animation started by a transition that changes other properties,
and then you're into circularity issues.
Reversing Transitions Part II
-----------------------------
[conversation shifts to hover/non-hover reversing]
http://lists.w3.org/Archives/Public/www-style/2010Mar/0266.html
<smfr> http://smfr.org/misc/tab.html
howcome: We agree that we want this sort of thing possible in CSS?
[referring to example]
everyone: yes
TabAtkins: But I have a js hack to make that work properly. Without
it, the reverse transition happens on page load.
bradk: :unhover!
tantek: :was(:hover)!
<glazou> in fact that's not what we need
<glazou> we need :will-be(:hover) :-)
<TabAtkins> :wants-to-be(:unicorn)
<tantek> is true on an element if it the selector inside the parens
was ever true on the element since document load.
Combining Transitions and Animations Part II
--------------------------------------------
szilles: What seems implicit here is that, to combine them, you need
an explicit way to refer to the implicit start and end values.
szilles: Some things seem simpler than others. Trigger an animation
on a transition seems like a relatively simple thing to do.
dean: It doesn't help our case, but internally we call them 'implicit'
and 'explicit' animations. We used a different name now because
they really are quite different things.
dean: [example of how the dock works with both transitions and animations,
with the zoom and the bouncing]
howcome: You could put them together, just have property names mean a
transition and a keyframe name mean an animation.
TabAtkins: That's a problem if we add a new property that matches a
common author keyframe.
<anne> to disambiguate you could use keyframe(<ident>)
<ChrisL> well, a keyframe name could have some syntax to always identify
it. $keyframe or something
szilles: [talks about animations as a restricted subset of transitions,
or viceversa]
dean: A transition could be considered an animation that's created
automatically at the moment of the property change.
dean: That automatically fills in the start and end, and automatically
removes itself at the end.
dean: We're not just concerned about the impl difficulty here, but
about authoring simplicity, and that's definitely why we did
them differently. But we'll try.
glazou: If you take the animation example, and remove the "from",
it's equivalent to a transition.
dean: Not quite. Even if you remove the "from" and the "end", you're
still saying you want a pulse, and there's nothing left to say
what is being transitioned.
<Bert> q+ to suggest 'transition-PLAY-count' instead of -ITERATION-,
to match 'marquee-play-count'
howcome: [doesn't like the names "Transition" and "Transform" being so close]
<bradk> trans(form|ition):
trans(former): robots-in-disguise;
[naming talk]
<bradk> metamorphosis-timing-function:
ChrisL: If you think of transitions as syntax sugar for an animation
that is automatically created, it seems you can harmonize it.
glazou: The discussion was not about naming. It was about harmonizing
transitions and animations.
dean: Ultimately what dbaron proposed is easy to implement; just merge
all the properties together and have some way of telling apart
transitions and animations.
dean: But I want to go back and look at content we have and see if this
sort of change will make it easier or harder to write.
tantek: How many people have authored this on the public web? I found
it confusing immediately, but as soon as I worked with it for
a little bit it became very clear.
howcome: I had the opposite.
dbaron: I said I was in the middle before, now I'm leaning toward dean.
plinss: It is possible to make a superset, the question is if it will help.
dean: A weird thing if you combine them is that you can have a transition
and an animation both controlling the same thing they'll fight.
glazou: I think you can possibly combine them, but at the cost of more
complex syntax.
glazou: I gave a demo with transitions and everyone got it immediately.
<tantek> transform makes sense from a mathematical functional sense
<tantek> http://en.wikipedia.org/wiki/List_of_transforms
<tantek> whereas transition makes sense like "state transition" in
science/chemistry/physics
<tantek> http://en.wikipedia.org/wiki/Transition_state
howcome: I think we need to try to *look* at the issue.
glazou: Sure, if someone can pull out a new proposal, great, but don't
block the existing draft on it.
Reversing Transitions Part III Combined With Combining Animations and Transitions Part III
------------------------------------------------------------------------------------------
howcome: I think this problem [referring to the example with reversing
an animation] needs to be solved.
plinss: Everyone agrees that that's a problem to be solved, but it's
separate from this issue.
howcome: I'm happy to go away and see if I can come up with something
smart, or if others can.
howcome: But also I'd like an action on the spec editors to deal with
the reversible animation. This was the first simple thing I
ran into that I thought I should be able to do.
tantek: I think this should be logged as an apparent hole, and I'm
interested in Dean's input on other apparent holes.
<Bert> (One thing I don't understand about animations and transitions
is how you can have both: an object can only be in one place at
one time (Heisenberg notwithstanding).)
Holes in Animations Draft (Other Than Reversal)
-----------------------------------------------
dean: [talk about fill modes being added in nightlies]
ChrisL: Oh, you didn't have that? Definitely, that's necessary.
dean: Yeah, it prevents a lot of added complexity.
dean: All the holes are trying to avoid writing script.
dean: So another one is how to chain animations.
<ChrisL> Having fill mode is crucial. smil has post-animation fill,
only. pre-animation fill is a useful addition
dean: So maybe say the end-time of one transition is the start of another.
ChrisL: So you can have animations keyed by a transition? Looks like
that would solve the example problem.
smfr: One thing I'd like to have is for the keyframes to apply with
the same specificity as the selector, as if they're sucked into
the declaration block and can be overriden.
dean: We'd known about these things for a while, we just didn't put them
in the proposal so we could have sometehing out in a reaonable time.
dean: Another is, if you have multiple transitions together, the latest
one wins. We'd like to be able to combine animations without
explicitly writing them together in a keyframe rule.
ChrisL: That seems crucial; you often want to run two animations that are
simple by themselves but are rather complex to specify together.
glazou: we need to close this for now.
ACTION: howcome to produce alternate proposal for handling animation and
transition together
animation-iteration-count name
------------------------------
Bert: Had a question about the name of one property - iteration-count.
Bert: But when we discussed marquee, Molly argued forcefully for play-count.
Perhaps we can use the same type of name.
TabAtkins: I agree; I think it's shorter, easier to type, and jives with
marquee's similar property.
<dbaron> What about repeat-count rather than play-count or iteration-count?
<Bert> (Also 'marquee-direction' and 'animation-direction' are subtly
different, but I haven't understood what the difference is yet...)
fantasai: What about tantek's suggestion to change animation-duration to
animation-period?
Plans for Progress on Animations and Transitions
------------------------------------------------
glazou: Steps to advance transitions
smfr: We'll add stepwise functions, and publish a new draft.
dbaron: I think we also need to handle the reversing business, and probably
the details in the "animation of property types" section. I've been
guilty of not sending comments about that.
dean: Can we settle on a goal for progressing to Last Call?
dbaron: I think it's doable to do LC in a few months.
tantek: Is there an issues page for this draft?
dbaron: I created an issues page, but didn't add anything to it for a while.
fantasai: Editors should be tracking issues.
ACTION: dean and smfr to produce issues list for Transitions and
Animations, including comments from dbaron and howcome.
<Bert> -> http://www.w3.org/Style/CSS/Tracker/products/22 issues list
for transitions (only has one issue currently)
[discussion of testing transitions/animations]
<glazou> transition-workin-group: lunch pulse 3mn
Fonts
=====
Scribe: fantasai
+jdaggett
+jfkthame
John Daggett and Jonathan Kew join via phone bridge
Font-weight Mappings
--------------------
jdaggett: I wanted to go over one thing that was discussed yesterday
jdaggett: There was the question of CSS2.1 font-weight
<jdaggett> http://lists.w3.org/Archives/Public/www-style/2010Mar/0510.html
jdaggett: The wording of the 2.1 spec now, the 4 bullet points you guys
were talking about
jdaggett: The 4th bullet point is not clear about 400 and 500
jdaggett: It's clear in case where 400 doesn't exist but 500 does, but
not about other cases
jdaggett: I've clarified this in css3-fonts
Chris: In that case I suggest we adopt the CSS3 wording in CSS2.1 to
keep these consistent
jdaggett: basically 400 and 500 map to each other, and then they map down
<jdaggett> http://lists.w3.org/Archives/Public/www-style/2010Feb/0279.html
RESOLVED: accept proposal to use css3-fonts wording about font-weight
hole-filling in css2.1
jdaggett: Adam Twardoch (sp?) posted about having an all-small-caps setting
jdaggett: It's very easy to add, I've added it to the current wording
<jdaggett> http://dev.w3.org/csswg/css3-fonts/#font-variant-caps-prop
jdaggett: The one tricky part about this is because of the bheavior
defined in 2.1 for small caps, where UAs fake small caps,
jdaggett: to be compatible with 2.1 we need to continue to fake that behavior
jdaggett: I don't think this would work for petite-caps, so I didn't add
simulation there
jdaggett: Because they are much smaller, and the size difference would be
noticeable
Chris: So what you're talking about is fallback. I think you're correct that
leaving petite-caps as lowercase is better than faking small-caps
jdaggett: So to summarize, we will fake small-caps and all-small-caps, but
not petite-caps or all-petite-caps
howcome: Isn't all-small-caps the same as text-transform + small-caps?
jdaggett: It's very close, but since you're doing the casing in the font
engine, the font can tweak things like parentheses because it
knows there are no lowercase letters
howcome: Wouldn't it make sense to do the higher-quality rendering for
text-transform + small caps as well?
jdaggett: You're not communicating to the opentype engine that it's all
small caps
howcome: You could, though. If you know tet-transform: lowercase is
applied, then you know that it's the same as all-small caps
and you can request that from the engine
jdaggett: Adam posted an explanation explaining the rendering of text
that has already been transforming
jdaggett: ... something about not knowing when things get transformed
<jdaggett> http://lists.w3.org/Archives/Public/www-style/2010Mar/0306.html
cslye: I do think some font developers do put extra stuff in these layout
features, like numbers and currency
cslye: I don't know if it's good or bad, but some people use this as a
way to pack more into a font. It's not just letters transforming,
but an alternate look
jdaggett: I think what howcome is saying is that instead of the author
explicitly requesting all-small-caps, the feature would be
implied by a combination of CSS properties
...
Steve: howcome's saying that after you've done the transformation, you
remember that fact, and then you pick up the c2sc
jdaggett: I think the implementation would be tricky because you'd have
to see if the font has this feature enabled. *If* not, then
you do the transformation yourself
cslye: Is it intuitive to split this? If you have an acronym, you usually
want to transform to uppercase, then use all-small-caps to get a
smaller version if that's available
cslye: Not to use a lowercase version
jdaggett: ... petite-caps is a different route than lowercasing and then
petitecaps
howcome: I think that keyword is not necessary, so I would like to see
this marked as an issue
Steve: My question is what is easier for the user
cslye: I think Adam addresses this in his email
Steve: What's the computed value?
ChrisL: What you get by copy-paste after transformation varies by UA
...
Steve: If you want to use text-transform selectively, then all-small-caps
is a better option
ChrisL: If a user agent understands and sees this combination of properties,
it could hand off the combination to the font engine and ask it
to do it all
Steve: The scope of the text-transform is different from the scope of the
all-small-caps
dsinger: If you have a way of asking the font engine to do something
directly, and you use a circuitous route, you should get
different results
Bert: Shouldn't have two ways to do two things that are so closely related
Bert: We already have one way to get there
Bert: And the difference between the two is very subtle, most people won't
notice but one way is definitely better
cslye: Our concern is that text-transform + small-caps is unintuitive
jdaggett: Sounds like we don't have a conclusion, but we should keep track
of the issue
SteveZ: you can put an issue in the draft
jdaggett: I will mark this as an issue, and the maybe ping Adam again
Petite-Caps
-----------
howcome: It's the same issue for all-petite-caps, too
fantasai: The fallback for petite-caps doesn't involve synthesis, so you
could wind up with all lower case instead
fantasai: at least for small caps + text transform, you're guaranteed
small caps even if they're not as pretty
Bert: Maybe the fallback for petite-caps should be small-caps?
cslye: It's a good question
cslye: Maybe you're better off faking petite-caps
jdaggett: I don't think we should have UAs fake the petite-caps
SteveZ: Which is why I suggest falling back to small-caps
jdaggett: I don't think it will work
jdaggett: The feature becomes so subtle, that ...
howcome: No this, is just to ensure that we can implement this in a non-OT
environment as well
howcome: so that UAs in those environments can do something there
jdaggett: When you try to synthesize petite caps, the glyphs get so small
that it's hard to read
<bradk> faked petite caps would look too fake and too light. Small
caps/fake small caps would be a better falback.
jdaggett and dsinger think this is a slippery slope
jdaggett: I think going in this direction is diminishing returns
<jfkthame> using small-caps as the fallback for petite-caps makes sense
.... like we use oblique as fallback for italic (or vice versa)
jdaggett: I would like to avoid artificial ways of doing font feature effects
cslye: That's fine, but then we can't implement the all-petite-caps feature
with text-transform, because we'll wind up with unwanted lowercase
jdaggett: Ok, I'm going to record this as there are two separate but
possibly related issues
SteveZ: Another point to record is that, it appears that some people
believe petite-caps match the x-height of the font
SteveZ: And in fact in one place, they were called ex-caps
jdaggett: Petite-caps are below the x-height.
cslye and stevez don't agree
jdaggett: It's smaller than small-caps
<bradk> 'text-transform:lowercase;' + small caps = all small caps seems
ituitive to me.
SteveZ: small-caps are typically above the x-height
<howcome> http://people.opera.com/howcome/2010/tests/petite.html
<bradk> 'text-transform:lowercase; + all-small-caps = all-small-caps seems
like a waste of a property
Superscripts and Subscripts
---------------------------
jdaggett: next issue
jdaggett: Dealing with subscript and superscript
jdaggett: OT has features that allow font designers to put sub / super
glyphs in the font itself
jdaggett: Issue is how to access it
jdaggett: currently sub/super is done with a combination of properties
jdaggett: the question is how to work things so that use the font feature
if available, otherwise fall back to altering properties as before
<jdaggett> http://lists.w3.org/Archives/Public/www-style/2010Feb/0245.html
jdaggett: that's the original issue
<jdaggett> http://dev.w3.org/csswg/css3-fonts/#character-transform-prop
jdaggett: This is how the spec currently words it
jdaggett: the idea here is that you use the subscript glyph if available,
jdaggett: and fall back to a synthesized version of that if that's not
available
jdaggett: and in this case I think it's better that the author see a
simulated version
ChrisL: Yes, this is good, because the fallback and the feature don't get
combined
ChrisL: It's a little weird that it resets the properties it simulates
with, but I also think it's a good idea here.
SteveZ: What happens if I stack superscripts or stack subscripts?
SteveZ: This is common in mathematics
<dbaron> We probably don't want to break 2<sup>2<sup>x</sup></sup>
SteveZ: The reason I say super { font-size: 70% } is so that stacking
superscripts works
Bert: It seems to me that we're using a feature in OT that we already have
SteveZ: We don't already have this. Simulated supserscripts are not nearly
as correct typographically as real ones
jdaggett asserts that stacked subscripts are unusual
SteveZ and ChrisL disagree, it is a common case in mathematics
<fantasai> you probably don't want character-transform to inherit...
jdaggett: the subscript or superscript is tied to a base font size
jdaggett: changing the font size changes the color of the glyph
jdaggett argues against something
Steve: Let me try another way
Steve: What I'm trying to get at is, the user decreased the font size
Steve: One way to deal with this is to reset the font size
Steve: The other way is to not reset the font size, but to use the
font-size of the parent when selecting the superscript glyph
<Bert> (But then the author doesn't get what he asked for, does he?)
fantasai: The tricky part is, if you have nested elements, you don't
want the parent
fantasai: you want the parent of the element on which character-transform
was set
Steve: That would allow us to get nice superscripts all the way down
jdaggett: I think I understand what you're trying to say
jdaggett: I can see these two things being used in conjunction. Whatever
it is, though, it should be understandable in the simple case
Steve: The simple case, they'll look exactly the same, so it didn't
really matter which way you did it
Steve: The result is you would use the subscript character in the size
of the original font
jdaggett: As long as that's there, that's the key thing
Chris and Steve try to explain the use case for character-transform to Bert
Bert: What if there's an image in there? Or fallback fonts?
jdaggett: This is something that would make sense for the default behavior,
but it doesn't make it impossible to use the old behavior
fantasai: Bert has a good point. If you have fallback, or if you have
images, you don't know where the effective baseline is
fantasai: And you can't align things to it
SteveZ: In that case, you could say, if there is anything in the element
that can't be substituted through the font, then you fake the
whole thing
jdaggett: I don't think you can do that
jdaggett: I don't think it's practical to make the fallback behavior
contextual
jdaggett: You're either affecting vertical-align or you're not
jdaggett: We have to know
SteveZ: my approach is that you don't affect font-size or vertical-align
when you do this
SteveZ: You just don't use them when rendering
ChrisL: I like that approach
peter says something quietly
<jfkthame> if you're applying an opentype superscript or subscript
feature, and you need to know the baseline for some other
alignment, you can ask the font for its superscript or
subscript offset
jdaggett: I'm not crystal clear on what is being proposed, so what
I'd ask you to do is to look at 6.2 and suggest specific changes
ACTION: SteveZ Propose changes to character-transform to address above concerns
jfkthame, thanks!
Font-specific Feature Selection
-------------------------------
jdaggett: new topic
<jdaggett> http://lists.w3.org/Archives/Public/www-style/2010Mar/0224.html
jdaggett: Talking about font-specific font features
<jdaggett> http://people.mozilla.org/~jdaggett/images/fallbackexamples.png
jdaggett: In the first page you have, say, two fonts
jdaggett: If you use the setting styleset(6), that's picking a specific
font feature
jdaggett: typically styleset numbers' effect is not consistent across fonts
jdaggett: Last time we talked about this, there were a number of people
were concerned that triggering a numbered styleset across font
would not be good
jdaggett: The key point here is that these are variations on the underlying
font itself
jdaggett: they're not .. look coherent with the text that surrounds it
jdaggett: The concern about showing some crazy glyph.. that the resulting
fallback will be ruinous
jdaggett: I think that's really far-fetched scenario
jdaggett: You'd have to have a pathological fallback situation for that
to happen
jdaggett: Most platform fonts don't have this feature, and they tend to
be subtle
jdaggett: Authors would have to not know about (?)
<dsinger> is that (a) because fallback etc. is unlikely or (b) because
styleset(6) (say) is likely to be there or not, but not very
"different" between fonts?
<jdaggett> http://people.mozilla.org/~jdaggett/tests/strangepresentationalligs.html
<jdaggett> http://people.mozilla.org/~jdaggett/tests/strangeligatures.png
jdaggett: on the left is safari, on the right is firefox
<dsinger> isn't it possible that styleset(6) in one font gives me a
variant designed for great legibility at small sizes and in
another, designed for swishy presentation in titling and at
large sizes?
ChrisL: Could I interject an observation?
ChrisL: I think there's not very many of these ligatures
ChrisL: They're added mainly for codepage roundtripping between legacy
encodings
ChrisL: They tend not to be supported in fonts
ChrisL: And they mess up other things like searching
ChrisL: As long as people have a more reliable method of getting the
same effect
ChrisL: I think the use of these presentation ligature codepoints will
be decreasing
jdaggett: My comment isn't about whether they should be used, but that
their fallback is different
jdaggett: My point is that when fallback occurs, strange things can occur
dsinger projects his IRC comment into voice
dsinger: Style sets should be only applied to the font for which they're
expected to apply
jdaggett: That's what you get with fallback.
<jfkthame> it's possible, but a very unlikely scenario - font features
are the wrong mechanism for a designer to be using there,
that's optical sizing
dsinger: Why do we wind up speciying a font-specific setting to a fallback
font?
dsinger: Why don't we design the syntax so you only apply the font-specific
setting to the font it was intended for?
jdaggett: styleset is the most extreme example
jdaggett: but some other features may or may not be font specific
jdaggett: e.g. the annotation forms feature
<jfkthame> styleset may well behave consistently across a whole library
of fonts, e.g., from a single designer/vendor
http://people.mozilla.org/~jdaggett/images/fallbackexamples.png
jdaggett: There is more consistency there
jdaggett: The author should be making the decision of whether it's a
font-specific or font-generic feature.
ChrisL: One way to get around this is to put the style set selection
in the @font-face rule
dsinger: Note also that the font that ends up being used might be
something the author didn't select at all. It could be
something specified by the user.
<fantasai> or on a system with limited fonts and no downloading
Steve: I may, with old eyes, want to use a high-contrast font
<ChrisL> While it may be sometimes true, or indeed often true, that
opentype font features only make sense when applied to a
specific font or to a spacific family, it is not clear that
it is *always* true
<ChrisL> and thus, authors should be able to choose whether to make
this general or font specific.
jdaggett: You can't guarantee that the web page is readable with an
alternate font
<jfkthame> if you want to use a personal stylesheet to force a certain
font, you can also use it to override the features
jdaggett: The author could pick a set of CSS features in combination
that would make the page unreadable with another font
dsinger: I'm not saying that all font features should be restricted
dsinger: But the ones where you're selecting by number, rather than
by name for a generic feature, you're getting a random effect
if you're getting one at all
dsinger: That doesn't seem right to me
jdaggett: You can already use @font-face if you really want
http://lists.w3.org/Archives/Public/www-style/2010Mar/0202.html
jdaggett argues that this and that is not that font-specific
peter: The problem is that the author may think that the feature is
not font-specific, and they test it on their three fonts,
but then some user 5 years down the line uses a font that the
author never expected
jdaggett: We're not changing the characters, we're changing the
presentation
dsinger: styleset(6) doesn't say what the change in presentation is,
and it might be very specific to the font
...
<Arron> font-variant: styleset(gabriola, 6) styleset("poetica std", 3);
howcome: Couldn't we just say that the styleset(6) applies only to
the first font in the list
howcome: and if you want to set it on other things, then you set it
on @font-face
jdaggett: If we come up with clever syntax to make it font-specific,
we increase the burden of the author
howcome: We increase the burden on the author to decrease the chance
of something weird happening
Peter: Authors aren't going to read the standard, and they're not
going to know whether they should use it in the property or
in the @font-face
Peter: It's going to work fine on their machine, and then the reader
gets screwed down the line
jdaggett: It won't be unreadable
dsinger: If it were designed for 30pts in titles and gets used in body
text, then you might well get something unreadable
cslye: ... throwing baby out with the bath water
peter: We're not saying let's not have this feature
fantasai: It's not that hard to tie the feature to the font. We have
at least 3 proposed ways to do it
<dsinger> I would prefer syntax that makes it unlikely, I would settle
for a warning...
jdaggett: I think whether something is font-specific or not is not
determined by whether it's numerical or not
dsinger: Yes, I accept a given foundry may use numbers consistently
across fonts
jdaggett: I think authors should have this flexibility
We're not moving forward with this :(
font-size-adjust: auto
----------------------
jdaggett: The other issue was font-size-adjust
jdaggett: I'm not sure I would be the best rep for that issue
dbaron takes the floor
dbaron: The idea of font-size-adjust is that it's a way of specifying
the font size by specifying the x-height
dbaron: it does it in backwards-compatible way so that old UAs get the
font-size property
dbaron: It does this by having font-size-adjust take a number
<jdaggett> http://dev.w3.org/csswg/css3-fonts/#font-size-adjust-prop
dbaron: font-size: 20px; font-size-adjust: 0.45; gets you 9px x-height
dbaron: this is useful for two things
<jdaggett> example of how font-size-adjust works
<jdaggett> http://dev.w3.org/csswg/css3-fonts/fontsizeadjust.png
dbaron: Particularly at small font size [in bicameral scripts],
legibility is related more to x-height than to font size
<ChrisL> and this is primarily useful when fonts are substituted, or
changed on sub elements
dbaron: e.g. Verdana is readable at very small font sizes
even though most fonts are not
dbaron: One use case for font-size-adjust is when you have multiple fonts
dbaron: E.g. in computer docs, you are mixing normal font with monospace font
dbaron: and depending on the fonts, the x-heights might be very different
dbaron: So to get a consistent effective size, you'd need to size them
differently (e.g. much smaller monospace font)
dbaron: I wanted to make font-size-adjust work better in cases where
the author wants to use the user's default font size
dbaron: but still equalize x-heights across fonts
<bradk> example of tiny x-height:
http://www.fonts.com/FindFonts/detail.htm?pid=203205
dbaron: The secondary use case is that browsers do really weird things
to equalize proportional and monospace fonts
dbaron: and this couldpotentially replace that
dbaron: Suggesting font-size-adjust: auto to mean, use the x-height of
the user's default font
jdaggett: the tricky part is that the default font isn't always one font
dbaron: I would love to get rid of this weird font pref setting thing
dbaron: It might require a little bit more, but that bit can be
browser-specific
dbaron: I would also like to allow authors to opt-into this world of
consistent x-heights
dbaron: by aligning to a reasonable default font
dbaron: Authors can do something similar by font-size-adjust: 0.5
dbaron: But that changes the user's default size, even if they don't
want to, by the amount by which that factor is off
szilles: I'm confused about what the "user's default font-size" is.
dbaron: There's the issue that the default font size does vary by language
dbaron: Some browsers have lang-specific font preferences
dbaron: so we might use those
szilles: If i set a font ...
dbaron: If you set a font family, not use the user's default, you
are likely to keep more closely to the effective font size
of the user's default with font-size-adjust: auto
dbaron: font-size-adjust: auto only depends on the default font-family,
not on the default font-size
<ChrisL> useful discussion at http://www.emdpi.com/css3xheight.html
szilles: So.. 'auto' makes a bunch of assumptions about where to go
look for things
szilles: And those assumptions work in pages where people use the
default font
szilles: Seems it wouldn't work as well to change the default font
dbaron: If they change the font, then they can also set a different
font-size-adjust
?: ...
szilles: But the values are hard to figure out
szilles: It would make more sense to say "match my parent's ex-height"
fantasai: That's an interesting idea. Setting it on the root would
hit up the initial font
howcome: Are we proposing to change page layouts across the web?
fantasai: no, we are just refining their typographical color
...
Bert, howcome: maybe be more useful as we see more fonts used
Alex: We have gotten requests for font-size-adjust
dbaron: font-size-adjust was in CSS2.0
jdaggett: I think it's a somewhat cumbersome feature
jdaggett: But I see people saying "I want this!" and when I see what
they describe, it's font-size-adjust
dbaron: It's implemented in Gecko
Alex: I'm not going to confirm or deny the plans for IE9
ChrisL: I think the proposal has merit
jdaggett: To me the big problem here is what you're calling the default font
jdaggett: Because that's something that's not defined normatively
jdaggett: And it's important for having this feature work consistently
dbaron: I tried to leave a bit of latitude for determining what exactly
the default font is
<ChrisL> a font example with a fairly small x-height
http://www.fonts.com/FindFonts/detail.htm?pid=203205#waterfall
howcome: I think I like Steve's proposal to use the root element
dbaron: I don't quite understand how that proposal would work.
Steve: The value on the root element, unless one is specified, is going
to be the default.
Steve: I can explicitly set a value on the root element
Steve: And have that used instead of the default font
Steve: So that could be the default font, but it doesn't have to be
dbaron explains something about overriding
dbaron: let's distinguish between user's default font-family and size
dbaron: This proposal gives a better way of matching the default font *size*
dbaron: It also gives users a better way to deal with the
monospace-proportional harmonization problem
Steve: That case is handled either way
dbaron: example
dbaron: Suppose the author wants to preserve the user's size
dbaron: But wants to use verdana
dbaron: They'd need this feature to effectively preserve the size
dbaron: because actually preserving the size, without this adjustment,
would result in a much bigger-looking font
howcome: initial value?
dbaron: initial value is none
dbaron: If we wanted to replace the current monospace hackery
dbaron: We would have to make the initial value be a value that if an
element or one of its ancestors had a font size in absolute
units, this special value would behave like none
dbaron: and otherwise the special value would be have like auto
dbaron: at least, in the way Gecko implement monospace pref
Steve: I'm confused why you think the default font size has anything
to do with what I'm looking
fantasai: So there are three use cases here, and dbaron's solves one,
steve's solves another, and both solve the third
1. Match the user's default size as well as possible, meaning
ex-height matching
2. Consistent ex-heights across font-switching throughout the
document, esp. mononspace vs. proportional
3. Steve Zilles' case
<dbaron> 4. Move towards replacing separate browser monospace font
size prefs.
stevez: The third use case is to match the ex-heights locally
stevez: handle the 2nd case when the author has changed the font-size
dbaron: Just set font-size-adjust: auto (or some other value) on the root element
fantasai and stevez try to work through stevez's case
-jdaggett
-jfkthame
<fantasai> 3. Keeping ex-heights consistent throughout the document
(requiring use of font-size-adjust) but wanting to set
an exact size for the main document font without looking
up the ex-height
<fantasai> e.g. Choose Palatino at 16pt, set font-size-adjust: foomatic
on the root and foomatic looks up Palatino's ex-height and
set's font-size-adjust to that so that Palatino's font size
doesn't change from 16pt *and* font-size-adjust takes care
of ex-height adjustment across the document
<dbaron> The problem with foomatic is that font-size-adjust inherits.
i18n/bidi/ruby
==============
Anne: HTML5 only includes simple ruby, which was implemented by IE
Anne: The module also has complex ruby
fantasai: I think Richard Ishida was planning to take that out of the
CSS3 Ruby module
Anne: There was some discussion on www-international
Anne: It seems in general that the Japanese people think the simple
model is adequate, because you can nest it
ChrisL: nesting was described as a hack
Anne doesn't particularly care
Proposal to defer entire discussion since Ishida is not here
Steve: There's ruby that's attached to individual characters, and ruby
attached to groups of characters.
Steve: Different ways of attaching to characters, and that's where most
of the trouble lies
Steve: I think we should wait and see what Richard's draft says
Anne summarizes HTML5's rendering rules for ruby, which mostly defer
to CSS by giving display types
Steve: So most of the complexity on the ruby side comes from how you
group the pieces and how you format across them
howcome: Can you write CSS rules on the rt elements?
Anne: The implementations so far have dedicated frame types in the
rendering model
howcome is asking if you can simulate ruby with existing CSS
Alex and Steve think not
SteveZ notes that there's a 96-page document that explains all the details
written by the JLTF in both English and Japanese
Steve: I think Richard is going to produce a new draft that is consistent
with HTML and the JLTF drafts
Steve: The plan is to wait until he gives us a draft to look at
Anne: Search for 'ruby' on www-international
<anne> http://lists.w3.org/Archives/Public/www-international/2010JanMar/
<anne> thread on ruby: http://lists.w3.org/Archives/Public/www-international/2010JanMar/thread.html#msg107
CSS2.1 Issues
=============
glazou: Arron told me we still have CSS2.1 issues to discuss
glazou: Since there's nothing else we can move to this time in the day,
I suggest we move to 2.1
http://wiki.csswg.org/spec/css2.1#issue-114
Arron: I put all the results for the testcases
ChrisL: I'm slowly converting those to SVG
Arron: Each one of these testcases are slightly different. Several are
parens/bracket/braces/quotes matching
Arron: The first one is the most interesting, using invalid characters
Arron: Trying to see if they match correctly
Arron: There are lots of interop issues, but at least 2 impl for most results
fantasai: I think we wrote the tests under the assumption that only nmchars
are allowed in unquoted font names
fantasai: brackets tests are more complex because they also test that
they're matched correctly
<anne> 002.xht is fun
dbaron: So, you're allowing idents, dimensions without + or decimal point,
numbers without + or decimal point.
Bert: you have to define in terms of tokens, not character sets
Bert: Should allow periods
dbaron: If we allow periods, we have the float round-tripping problem
random discussion of various option
Anne says we should just use ident+
Bert says it's confusing not to allow numbers unquoted
dsinger says it's reasonable to quote them
<bradk> FYI, the third test (Invalid curly brackets and pair matching)
passes in a recent nightly download of Webkit, even though it
fails in Safari.
http://test.csswg.org/source/contributors/microsoft/submitted/Chapter_15/font-family-invalid-characters-003.xht
general consensus that the discussion is going nowhere
Options are:
1. identifiers only
2. nmchars tokens only
3. try to come up with a grammar to make the current prose more clear
ChrisL: I need to take this back to the SVGWG and get feedback from them, so
we shouldn't make a final decision here.
1. http://lists.w3.org/Archives/Public/www-style/2010Mar/0369.html
2. http://lists.w3.org/Archives/Public/www-style/2010Mar/0395.html
3. To Be Written
FF and Safari are almost ident+
or are ident+, but have bracket-matching bugs :)
Opera is close to the current prose
IE is somewhere in between, but closer to Opera
Anne: 1
Steve: 1
Sylvain: 1
Alex: 2, but live with 1
Beth: 2
Bert: 3
Arron: 2 or 3
Elika: 2, live with anything as long as clear
dbaron: 1
Brad: don't care
Tab: 1
Tantek: Abstain
Glazou: 1, but can live with everything
ChrisL: 3, 2, 1
Peter: 2 is slightly better for authors in that it would be a little
surprising to not start with a number
Peter: I don't like the fact that 2 introduces a new token type, so 1
Bert: I think it can be done without
Howcome: 3
Elika: Actually, I'm going to change my vote to 2, then 1
dsinger: abstain
Steve: I can live with 2 also
Steve: I don't really see much difference between 1 and 2
<smfr> smfr has joined #css
Peter: My real preference is that people quote things more
Steve: That's why I voted for 1
glazou: Can't go further, Chris has to take this to SVGWG first
glazou: 7 for 1, 4 for 2, 3 for 3, and almost everyone can live with
everything
glazou: which is cool
ACTION: clilley Discuss font-family syntax with SVGWG
<dbaron> http://test.csswg.org/source/contributors/microsoft/submitted/Chapter_15/font-family-invalid-characters-002.xht
is buggy because it has ( { ) and expects the ) to match
the ( while you need to find a } first
<Bert> (Minor flashback to 1996: font-face was modeled in part on
Netscape's FACE attribute.)
dbaron notes that Mozilla has seen only one bug, that dbaron could
find, on this issue
<dbaron> I went through bugzilla.mozilla.org bugs with 'font-family'
and 'quote'... there were 4 reported by users (also one
internal code issue).
<dbaron> One was about this issue, two were complaining that
font-family: 'sans-serif' didn't work, and one was complaining
about font-family: 'Arial, Helvetica'; not working
<dbaron> The one that was about this issue was
https://bugzilla.mozilla.org/show_bug.cgi?id=471300
http://wiki.csswg.org/spec/css2.1#issue-163
dbaron: Anne, I don't understand why getComputedStyle is relevant
Anne: http://dump.testsuite.org/2010/width-computed-value.htm
Anne: If you set width: 10em on an inline, and then inherit it to
a block, you get 10em
Anne: But the spec says the computed value, the inherited value,
should be 'auto'
RESOLVED: Proposal accepted for Issue 163
http://wiki.csswg.org/spec/css2.1#issue-162 raised by i18nwg
data:text/html;charset=utf-8,<!DOCTYPE HTML PUBLIC "-%2F%2FW3C%2F%2FDTD HTML 4.0%2F%2FEN">%0D%0A<html
lang%3D"en">%0D%0A <head>%0D%0A <title>Test<%2Ftitle>%0D%0A <style type%3D"text%2Fcss">%0D%0A <%2Fstyle>%0D%0A
<%2Fhead>%0D%0A <body>%0D%0A <ul dir%3Dltr>%0D%0A <li dir%3Drtl>Bullet%0D%0A <%2Ful>%0D%0A
<%2Fbody>%0D%0A<%2Fhtml>%0D%0A
FF renders the bullet on the right
as does Chrome
Opera renders on the right
IE renders on the right
dbaron: So this is a proposed change where every impl we've tested
matches the current spec
dbaron: Direction changes are a relatively rare case
<dbaron> ... especially in the middle of a list
Daniel: If you have a <body dir=ltr> with <div display:list-item dir=rtl>
then you wouldn't see the right direction for the marker
<dbaron> Yeah, I think this change seems wrong for the general
display: list-item case.
<dbaron> Even if it might make sense for the way HTML li elements.
Steve: the most obvious example I can think of this giving a list
of phrases in different languages
Steve: I'd want the bullets lined up
dbaron: You don't want to change the block direction in Steve's case anyway.
dbaron: Because the alignment will change
Steve: Why can't I set text-align?
...
Steve: I can't think of a case where you'd want the bullet on the right
dbaron: You can have list items that are not using HTML list markup
Peter: so are we rejecting this then?
TabAtkins: As a side point, markers clearly belong to the list-item, not
the enclosing block. The color of a list marker comes from
the list-item.
<dbaron> http://www.w3.org/TR/CSS21/visuren.html#dis-pos-flo
<dbaron> ... says list items can float
<dbaron> ... and keep their marker
Steve: What I've heard is that we're already committed that the marker
is part of the list-item
fantasai also points out that it would create an inconsistency with
'list-item-position: inside' items if we swapped the direction
of the bullet based on the parent for 'outside'
dsinger: So we should resolve this and offer to i18n that we can add a
note explaining how to get their desired effect
RESOLVED: No change for Issue 162 in normative behavior
Bert and fantasai discuss ways to allow a switch in this behavior in
CSS3, possibly using the bidi-isolate concept
ACTION: fantasai move issue to css3-lists
http://wiki.csswg.org/spec/css2.1#issue-161
TabAtkins: [draws a picture with a containing block A, some number of
descendants B, and a positioned descendant C. Any overflow
on B has no effect on C, because A is C's containing block.]
| In certain cases, a box may overflow, meaning its content lies
| partly or entirely outside of the box, e.g.:
| ...
| A descendent box is positioned <del>absolutely</de>, partly outside the box.
| Such boxes are not always clipped by the overflow property on
| their ancestors. <ins>Note that absolutely positioned descendant
| elements are not always clipped by the overflow property on their ancestors.</ins>
dbaron: I thought the proposal was the replace the Such ... ancestors sentence
fantasai: I think that makes a lot more sense
apparently this was the original proposal, fantasai just forgot
Peter is concerned that "not always clipped" is unclear
dbaron: I think the reason for the change from such to note is because
we're removing absolutely from the first sentence
<bradk> "a positioned item is not affected by the overflow property of
ancestors inside its positioning block."
<bradk> s/positioning block/containing block
dbaron: And ambiguities in the second part of the sentence should be a new issue
<fantasai> so s/are not always clipped by the overflow property/do not always cause overflow/ ?
ACTION: Tab Rewrite proposal for Issue 161
http://wiki.csswg.org/spec/css2.1#issue-160
glazou: Melinda got it backwards
ChrisL: Prefix the sentence with "For example", because Japanese top-to-bottom
books start like rtl books do
<dbaron> css3-page says it the right way around in
http://dev.w3.org/csswg/css3-page/#progression
RESOLVED: Add non-normative for-example change
http://wiki.csswg.org/spec/css2.1#issue-149
Proposal Fix 96px per inch. Whether inches fixed to reality or pixels
fixed to screen res / viewing distance / something else may
vary by UA. (Print would match real inches, screens tend to
align with viewing distance and/or screen res.)
Peter holds up his iphone.
Peter: You are constantly zooming in and out on this device. There's
no guarantee you'll ever get a physical inch for an 'in'
SteveZ: You have the canvas, and the window onto the canvas.
SteveZ: You have controls to change the window onto the canvas
...
<Bert> (The problem is not zooming on the iPhone, the pb is that a very
small percentage of people thinks that it is illegal to use px
on font-size. We just need to tell them that is not so.)
dbaron: Are any other browser vendors willing to change their implementation
to match the 'pt' unit to match physical 'pt' using monitor detection
settings?
dbaron: Everyone assumes 96dpi. So there's pressure on us to do that.
Steve: It's all your fault Tantek.
Peter: You and I had a discussion in an elevator where we agreed that
Macs would use 96dpi instead of 72dpi
Peter: And you showed me UI that would allow the user the ability to
set an inch correctly by holding a ruler up to the screen,
which was cool.
Peter: I'm happy to give users that capability
Peter: If the UA wants to have a zoom factor of Actual Size, then it
can use the OS info to get the most accurate 1in == 1 inch
rendering it can
lots of conversations
<bradk> If the UA decides on having an "actual size" mode, and the
monitor is not really 96ppi, then GIF images and such would
have their pixels interpolated.
<ChrisL> "The suggested reference pixel is the visual angle of one
pixel on a device with a pixel density of 90dpi and a
distance from the reader of an arm's length. For a
nominal arm's length of 28 inches, the visual angle is
about 0.0227 degrees. "
<ChrisL> http://www.w3.org/TR/REC-CSS1-961217#units
Meta-Viewport Interlude
-----------------------
Tantek talks about a meta-viewport problem
Alex: For Facebook, I found that in the virtual viewport the bar
at the bottom was fixed-positioned, but you couldn't get to
it unless you scrolled down
Tantek: Shouldn't the meta viewport tag be a CSS thing, not a
proprietary meta tag?
Tantek: The exact problem that meta viewport solves, that should
be in CSS
glazou: What happens if you browse a meta-viewport page with Safari
on the mac?
smfr: It ignores it
Anne, Sylvain: Meta-viewport is setting the size of the viewport
and then the UA zooms in to that size
Tantek: Most other mobile browsers display a page designed for mobile normally
Tantek: But the iphone made it into this tiny box in the corner of the screen
Tantek: Even if you do use a media query to select an appropriate styling,
then it still doesn't behave appropriately
Sylvain: It defines what a pixel is as a fraction of the viewport
fantasai: So it's setting the size of the initial containing block
fantasai: not the viewport
smfr isn't sure
Tantek: If I write a media query to serve appropriate style sheets
for 350 pix, Safari scales the page down to a tiny thing
in the corner
smfr: That's a bug, and we have it filed
<tantek>
http://developer.apple.com/safari/library/documentation/AppleApplications/Reference/SafariHTMLRef/Articles/MetaTags.html
fantasai: If we don't have a proposal on this, then I think we
should close this topic
<tantek>
http://developer.apple.com/safari/library/documentation/AppleApplications/Reference/SafariHTMLRef/Articles/MetaTags.html#//apple_ref/html/const/viewport
CSS2.1 Issues (cont.)
---------------------
http://wiki.csswg.org/spec/css2.1#issue-149
dbaron: Did we have a resolution on the 2.1 issue we were talking about?
howcome: I want to see the proposal before deciding
howcome: I think the spec already says this
peter points out that it doesn't
and we go around in circles again
I'm so not minuting this
<anne> Bert, http://xkcd.com/386/ ;)
Bert argues that we should evangelize the web
Alex: In IE8 we tried matching px to in based on the resolution, and
this broke lots of things so we changed back to pretending 96dpi
http://wiki.csswg.org/spec/css2.1#issue-148
<dbaron> For issue 148, I'd like to figure out why we changed it in
the other direction.
Meeting closed.
dbaron and fantasai investigate the CVS logs after hours and find that
the change was made as part of a "lowercase html tags" change in 2002.
No evidence of why the semantic change was made.
Received on Thursday, 8 April 2010 07:15:33 UTC