- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 02 Aug 2011 22:50:49 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Writing Modes
-------------
- RESOLVED: Remove the concept of glyph-size tolerance from this level of
the spec for text-combine
- Discussed scaling methods for tate-chu-yoko effects
- Discussed name of 'writing-mode' property
Gradients
---------
- RESOLVED: when the UA has knowledge of the output resolution, it's allowed
to substitute an average color for the repeating color when the
device does not have the resolution to capture the gradient
correctly.
- RESOLVED: Use premultiplied colors for gradients and transitions
- RESOLVED: Split css3-images into level 3 and level 4 with level 3 containing
the more stable things.
- Discussion of removing keywords from level 3 for more work: corner-to-corner
gradients need a change of definition to work right, and other keywords are
confusing to some people. No objections to deferring corner-to-corner gradients.
However, no consensus on removing horizontal/vertical keywords.
Grid Layout
-----------
Phil summarized changes since March F2F. Brief discussion on 'fr' unit and relation
to flex() and flexbox.
CSS Positioning
---------------
- Arron and Rossen presented draft for CSS3 Positioning, which is mainly old stuff.
- Proposed 'position: page', but some problems with its model were noted.
- RESOLVED: put CSS3 Positioning draft on dev.w3.org
====== Full minutes below ======
Writing Modes
-------------
<glazou> jdaggett: can you hear us?
fantasai: I think there are several issues open right now.
fantasai: One is the name of the property.
fantasai: Second is the default orientation at a codepoint level.
fantasai: The third is whether we're doing context-based resolution of
punctuation, and if so, how?
fantasai: The fourth is if we're giving additional controls at level 3
(beyond what you can currently do with text-orientation).
jdaggett: Let's start with sylvain's issue.
jdaggett: I think #3 and #4 are dependent on a concrete proposal for #2.
szilles: Two more issues are Nat's comments on TCY
szilles: I think you suggested separating the text-combine prop into one
that did manual TCY and one that set up automatic TCY.
szilles: They may want to be over different ranges.
jdaggett: Why do you need that distinction, Nat?
<dbaron> (TCY == Tate-chu-yoku)
nat: Right now we have text-combine:horizontal, then a bunch of values
for controlling the auto case, I guess.
nat: Is that what we want? Just specify it on, and then specify the
details (do letters, do digits, combine X many)
nat: And then, if the letters in the span meet that criteria, combine them?
florian: One case was that, or a date, you don't wnat to have to add extra
spans around the day and month and year, but rather just one around
the year.
nat: The other issue I had was the default implied value.
fantasai: The values are "none", "all" (tcy the whole span), and then
various options that control what things are combined.
<jdaggett> nat's post: http://lists.w3.org/Archives/Public/www-style/2011Jul/0405.html
<dbaron> http://dev.w3.org/csswg/css3-writing-modes/#text-combine
nat: I thought if I tried to implement this, it would be easier if I didn't
thave to worry about having a state machine go through the text.
fantasai: You can't combine, say "all" and "latin 4" - it's not syntactically
valid.
nat: I think some examples would help here.
nat: So when it's not all, you can do auto TCY in any span.
<fantasai> ACTION fantasai: Add syntax examples
<trackbot> Created ACTION-357
nat: A second point, why do you have, in the alphanumeric tolerance section,
a "1.1em" figure. That seems arbitrary.
fantasai: koji was talking with hyatt about that issue. Hiragino apparently,
if you ask for half-width glyphs, won't fit within 1em if you put
them side-by-side.
szilles: if that's true, why not just do it when they ask for it?
fantasai: This is for whether you scale or not. This number is close
enough that you usually won't have to scale.
kojiishi: The idea of scale is to compress glyphs so that they fit into 1em.
kojiishi: But there are some fonts that get slightly gretaer than 1em when
you set two half-width next to each other.
kojiishi: So if two chars are much larger than 1em, authors would likely
want to compress them. But if they're just a tiny bit over
(maybe accidentally, like described here), you'd want to just
leave them alone.
nat: Okay. I think having the built-in tolerance is orthogonal to the
scaling issue.
nat: If you're tolerant of the idea that you're using glyphs that dodn't
fit into 1em, you're probably okay with not scaling, so you should
just say no scaling.
kojiishi: Even if you do scale, though, you probably still don't want to
scale if you're just very slightly over 1em.
nat: But you're saying to scale it to 1.1em, not 1em.
nat: You can have an "auto-scale" that has some tolerance in there.
florian: Can we just have a scale with no tolerance, and let you add the
tolerance in specifically?
szilles: If they're images, you really notice the artifacts. If they're
outlines you won't notice as much.
szilles: Can we say something other than "scale"?
squish/compress/scale-x?
<bradk> condense, horizontal scaling
Nat: condensed is bad because it implies a different font selection
fantasai: compress
jdaggett: If someone wants this tolerance, they should be involved in the
discussion.
florian: I don't think it's useless, but it seems to be going a bit too
far right now. Push it to level 4.
fantasai: The tolerance is used in the scaling (removed now), and also in
the "used glyphs" section.
fantasai: Which says to use half/third-width glyphs if available; if not
available, scale.
<bradk> Adobe calls it "horizontal scaling" in their programs, IIRC, FWIW
fantasai: What might happen is that you say you want to use third-width
glyphs, but it ends up being rendered with a font without
third-width glyphs.
fantasai: The default action, then, should be to go ahead and scale, as
that's minimally invasive to the rest of the page design.
nat: Is that how it's supposed to work? I didn't get the idea that things
had fallback.
fantasai: You can combine "scale" and "use-glyphs".
szilles: Why wouldn't you scale to 1em?
florian: You'd scale to 1em, but you wouldn't scale if you're "close enough"
to 1em.
szilles: [an example with "1.3" and TCY]
<bradk> Is it tragic to allow the glyphs to overflow if they are slightly
too wide?
jdaggett: In the original document this was based, there's an example for
that.
<jdaggett> original document == jis 4051 spec
szilles: I know that stuff like TCY'd "1.357" is actually done.
nat: I think we should just have a "use glyphs" option, and if glyphs don't
exist, just do fallback.
fantasai: We can say that if you find the right glyphs, just don't worry
about compressing. Assume that the glyphs are the right width.
kojiishi: If the first font has the glyphs (slightly off the right width)
but the second font doesn't, the first font would grab the glyphs
and be slightly off-width, while the second would synthesize and
be exactly right.
nat: I think you're far off in edge-cases here.
szilles: I think it's pretty simple. If it has half-width glyphs, it has
half-width glyphs. Just use them.
nat: Why are we doing anything if the half-width glyphs don't exist?
szilles: CSS generally tries to best capture the authors' intent.
kojiishi: If the author says "digits 3", and the half-widths are slightly
more than half an em, you'll get slightly more than 1em-width TCY.
fantasai: Is it possible to know if the font has third-width glyphs?
nat: There's a feature in OT that the UA can query.
jdaggett: The problem with these features is that for different features,
different sets of glyphs are available.
jdaggett: For third/fourth-width, often only digits are available.
szilles: What about numeric punctuation (periods and commas)?
nat: Generally not. Most only have half-width punctuation.
szilles: So you could do years and integers, but not decimal numbers.
nat: Right.
szilles: I think we just need a clear processing model of when things
are decided.
szilles: I don't think we want to say "let's make as tring, and then try
to compress it". I think you want to first check for half-width
glyphs or whatever, and then build out of what exists.
szilles: So I want a clear statement of what you're looking for from the
font, and under what conditions.
fantasai: So what I'm hearing is that we should use the correct glyphs if
the font has them, otherwise synthesize.
fantasai: So if I'm doing "122", if the font has third-width glyphs, I
use them. If it doesn't, I scale the "1" and "2" glyphs and
then combine them, rather than making "122" and then scaling.
florian: Also, the current spec specifies just that they should fit into
1em, which allows cherry-picking half and quarter-width glyphs
and combining them, which is not what you want.
<bradk> Doesn't kerning and tracking affect if two 1/2-width glyphs fit
into one em?
fantasai: We can tell if the font has a "third-width" feature, but we
don't know if individual characters have third-width glyphs.
So if I wanted "IBM" in third-width glyphs, I'd request those
glyphs from the font as third-width glyphs, but I may or may
not actually get third-width glyphs back.
fantasai: So once I get them back, if they're wider than 1/3em, I need
to scaled them to 1/3 em.
fantasai: I think we can make an exception that, for half-width glyphs,
don't measure and just use what you get. You may get proportional,
which may be close enough.
bradk: Can kerning affect this?
nat: You don't kern monospace CJK fonts.
jdaggett: In theory, it's an issue; in practice, you don't ever kern these
types of fonts. I don't think we need to worry about it.
<jdaggett> ... you don't generally kern these *glyphs*
<jdaggett> i.e. third-width glyphs
kojiishi: I think it may still be useful to have an option to not scale
glyphs, as it may be ugly sometimes.
florian: Perhaps if you say "use-glyph no-scale", you just use exactly
what's given back by the font, no measurement. It may be too
big, but shrug. Then "use-glyph" will scale if they're too big,
and "compress" will just always scale the full-size.
fantasai: Makes sense.
<fantasai> ACTION fantasai: edit as above
<trackbot> Created ACTION-358
RESOLVED: Remove the concept of glyph-size tolerance from this level of
the spec.
<jdaggett> whatever you spec out, you need to try it on some simple
examples and include them in the description
<jdaggett> the markup should be easy and the implementation should be
fairly easy
nat: yeah, you don't want multiple passes to support TCY
fantasai: So for fonts with propotional, but not half-width glyphs, if
you say "use-glyphs", should we just use the glyphs directly?
szilles: I think, since the user can say "no-scale" if they really don't
want it, you should have a single default that works decently
enough for everyone.
kojiishi: The tolerance came in to address the common case where the TCY
want to use two digits without scaling.
nat: If we have different scaling values (depending on number of digits),
it's too complicated for the value you get.
nat: I agree that it may be useful in some cases, as Koji says, but I
don't think it's worthwhile to address.
nat: Koji brings up the possibility that some people may want to scale
only when it looks terrible, and let it not scale if it's "almost
there".
nat: But I don't think it's worth dealing with that explicitly. That
should be something a UA could decide.
florian: Or we could go with steve's idea of adding a parameter to
no-compress, rather than using tolerances
szilles: I mainly just think we're spending too much time on this.
fantasai: And the default is the UA tries to do whatever it can to make
things fit. No limitations.
nat: Moving on, it looks like you can omit the integer in "digits" etc.
and it defaults to 2. I think it would be better to be explicit.
fantasai: Okay.
kojiishi: You're not requiring an integer for "all", right?
fantasai: Right.
nat: We should just make "all" be very simple. It does *all*.
<szilles> Add Usecases for 2 or 3 digits in auto t-c-y and have an example
with mix of digits and non-digits; e.g., "1.2"
fantasai: If you say "use-glyphs" and there's only a single char, the
current spec says to use a full-width glyph if one is availab.e
nat: And I think you shouldn't do that.
nat: glyphs substituation may cause problems (undefined?)
nat: Are you supposed to scale up the glyphs to 1em, or what?
fantasai: I'd just use proportional
florian: I think we've said that TCY and text-transform interacts.
fantasai: Spec says that any text-transform features are turned off for
combined text of more than 1 char.
florian: Then that's fine. You can use text-transform to get single
large chars, but have smaller chars for more TCY.
fantasai: jdaggett you were saying that for text-orientation we should
write up proposals first and then discuss?
jdaggett: Yeah, I did some experiments. Spec says currently that you have
to use the VR2 feature of the font, but in practice that doesn't
really work.
<jdaggett> http://lists.w3.org/Archives/Public/www-style/2011Jul/0401.html
jdaggett: In the post I summed up the key points:
jdaggett: Latin will rotate, greek and cyrillic won't, and there are many
other cases where it's not clear that what exists is what you want.
<jdaggett> http://lists.w3.org/Archives/Public/www-style/2011Jul/0402.html
jdaggett: In discussion with Erik Muller, we thought it made more sense to
specify a property (possibly going into unicode) that says whether
a character is upright or rotated.
jdaggett: Then we can use that property to define the gray areas here.
jdaggett: symbols, punctuation, currency, etc.
fantasai: That sounds reasonable.
jdaggett: I just don't think this can be a derived property from the
existing values.
fantasai: Agreed - but until it's a unicode property, we'll have to have it
be derived with a large list of exceptions.
jdaggett: And then the logic of text-orientation will be to use that
property, then apply the "vert" opentype feature to the upright
runs.
nat: And you do that so fonts which disagree with the feature can achieve
that?
jdaggett: Yes.
nat: I'm comfortable with that.
jdaggett: This property effectively already exists, but it's just custom
right now in different tables.
jdaggett: IE already has it (though clearly out of date; it doesn't do
non-BMP). Webkit has a similar table, similarly wrong.
<ChrisL> has Unicode consortium been asked to add this property?
jdaggett: It would be great to pull together our individual dbs and help
make a proposal to unicode.
nat: InDesign has something similar too.
<ChrisL> (I take what jdagett said to mean "not yet but we will")
<TabAtkins> chrisl, I believe so, yes.
jdaggett: I don't think we need to get into the individual heuristics yet.
nat: When unicode didn't provide two codepoints for something that was
two codepoints in shift_jis, we have to be able to differentiate.
nat: Some fonts have different designs for the two. In some fonts you
want to rotate, and in others you don't.
fantasai: We can get info for Japanese fairly easily, but I'm concerned
about other languages like Chinese where we don't have much
if any information.
nat: It's different, and unfortuantely the standards are even more loose.
nat: We don't use font metrics, but it's very complicated to deal with this.
jdaggett: to handle that sort of thing, we could call out those specific
codepoints and deal with those in a separate category.
jdaggett: So CSS3 can deal with japanese well, but the separation lets
us make better rules for Chinese and such later.
szilles: You and I, jdaggett, have proposed being able to provide a delta
on the unicode table.
jdaggett: I think it would be better to wait and propose the property
first, then went through and discussed how you might want to
modify it.
szilles: Right; I brought it up as a reminder of the concept.
jdaggett: Right. it would be nice to eventually let authors say exactly
what defaults they want ("never rotate english text"), so they
didn't need to put a bunch of markup around specific areas.
szilles: It would also allow all the default tables out there to be
incorporated.
fantasai: I have a concern that the rest of the draft (the layout parts)
really ought to be stabilized somehow.
fantasai: We have a lot of work left to do on text-orientation, but I
think the layout bits should be locked down and not held back
by this work.
fantasai: Another month or two I can handle, but if this'll take us until
next year, I'm concerned.
jdaggett: I don't think it'll take that long.
fantasai: One more item now.
fantasai: Sylvain was talking about the name of 'writing-mode' property.
sylvaing: The writing-mode property says it defines block-progression
(then why isn't in named "block-progression").
sylvaing: then it says that the writing mode is deifned by three properties,
one of which is called "writing-mode", which is confusing.
fantasai: I think we shouldn't change the name, but if you have a better
term...
sylvaing: There used to be a block-progression property.
fantasai: Yes, because at the time writing-mode was a shorthand that
overrides "direction", which was a very bad thing. We've
had this discussion a few times.
fantasai: And it's incompatible with SVG and IE6.
sylvaing: What is?
fantasai: We could call it block-progression, but then writing-mode would
be an alias.
dbaron: Is this a naming discussion, or a substantive one?
fantasai: Kinda both. Given legacy and other reasons, I think the name
should stay, but I'm willing to change the terminology.
szilles: I agree that this would be better called "block-progression".
But history/SVG means that it should stay consistent and be
"writing-mode".
<ChrisL> svg also uses the term 'block progression direction' (from xsl) btw
fantasai: I'd just like to avoid property aliases.
<ChrisL> but it does use the writing-mode property, yes
* jdaggett egads
dbaron: value aliases are much easier than property aliases.
<br/>
Gradients
---------
Scribe: fantasai
Tab: 3 issues to resolve
Tab: First one is repeating gradients when the distance between the first
and last stop approaches zero
TabAtkins: zw gradients are not a problem without repeating, but is a
problem for repeating because you can't repeat them on the
same point infinitely
TabAtkins: Right now I punt on the issue by making repeating gradients
required to have minimum 1px width
TabAtkins: That guarantees we can tile the space like we should
TabAtkins: Don't know if it's ideal, but it stops the problem of infinity
* glazou loves when Tab explains that n * 0 is always 0 whatever is n :-)
TabAtkins: Other possibility that preserves continuity is that when we
hit zero width, we pick the average color you'd get
* glazou loves when Tab explains that infinity / n is always infinity
whatever is n :-D
TabAtkins: Seems kinda complicated for an edge case, but I don't realy
care, just want a decision
TabAtkins: And to be consistent with svg
Florian: Pixels aren't px
TabAtkins: I'm fine with saying it's a hairline wide
Florian: So you do fallback at device pixel
Brian: WD says to use first color stop
TabAtkins: Yeah, but that's not continuous behavior
<ChrisL> device pixels is better. because svg scaling can mean that a 1px
is really big
[fast talking]
Brian: Non-repeating radial gradients folow last color stop rule
dbaron: But with those you always fill the area outside with that color
TabAtkins: As you approach the limit, you get that result
Brian: So it's continuity issue.
TabAtkins: I'm ok with either way, whatever way implementers would like to
do, let's do
shepazu: SVG, when it hits zero, says that nothing is rendered
shepazu: That kinda punts on that
shepazu: I don't know that SVG says anything about approaching zero
<ChrisL> it does not, no. its either a zero bounding box or it isn't
shepazu: The averaging thing doesn't seem like what ppl want to do
fantasai: I think that makes the most sense; as you zoom out that's what
you'd get
shepazu: It'd be mixed with other color.. start color end color harmonious
with page
TabAtkins: If you do 1px red blue and repeat it, it looks purple. If you
make it smaller, can assume it'll look purple
Brian: 1px seems too large to me. But making the spec normative at 1px,
but allow better resolution
TabAtkins: So the clamp is at 1px or below.
<ChrisL> px or device pixel?
<fantasai> CSSpx
<ChrisL> eww
Florian: So this would allow them to go to device pixel, but not force it
<ChrisL> device pixels is better. because svg scaling can mean that a 1px is really big
Brian: Do you want inconsistent rendering across zoom
Brian: If you'll get purple pixels sooner at one zoom level than another
zoom level
...
* glazou waited for "infinity * 0 is undefined", here we are :-)
TabAtkins: Gradients are a vector format in any case
shepazu: If you zoom in until 1px is the whole screen, then what?
TabAtkins: You're allowed to clamp at a smaller size
Brad: Makes sense. Like with text you get better resolution as you zoom in.
TabAtkins: It ends up being a quality-of-implementation issue.
dbaron: You could just specify that as the length of the repeating gradient
approaches zero, you should average the color.
Florian: Need to make sure it's not going to do that at 20px
<ChrisL> <g transform="scale(1000,1000)"><rect width="1px" height="1px"
fill="url(#gradient)"/></g>
<ChrisL> I don't want the 1000 by 1000 device pixels rect above to be a
solid colour
plinss talks about billionths of a CSSpx
dbaron: I think it should be device pixels, because if you zoom out ...
plinss: Say that the UA can substitute an average color if the gradient
length is small [...]
fantasai: Just define what happens at zero. Everything above zero is handled
by pixel-rounding, which we don't speicfy
TabAtkins: So should I specify averaging color?
dbaron: Need to specify color space to average in
shepazu: So what happens when you zoom in?
TabAtkins: That depends on implementation
<ChrisL> @dbaron yes, you do
TabAtkins: If you zoom enough you hit rounding issues
<ChrisL> @tab that is always the case. welcome to the world of non-financial
computing which uses fixed precision arithmetic
TabAtkins: I want to make sure ChrisL's case is handled
TabAtkins: is allowed to handle, don't know if I can require it
..
TabAtkins: I can't must without being precise
shepazu: It's not as important to specify the behavior at 1px when it's been
defined as 1px, it's what the rendering is.
<dbaron> I think Peter's suggestion was good.
shepazu: Important part was ... as you zoom in that 1px width is now 50
pixels it should have the whole gradient
shepazu: You can test that -- chris just wrote a test for that.
shepazu: You haven't been dealing much with things like scale, but you're
going to be, so you're going to run into this problem
<ChrisL> css transforms
Dean: We all know the implementers are going to do the best they can.
* fantasai peterl should type his proposal
* fantasai didn't catch the details
* ChrisL missed the nanoPx also
plinss: This is very simply specified.
plinss: You try to not overspecify it.
plinss: When the UA has knowledge of the output resolution, it's allowed
to substitute an average color for the repeating color when the
device does not have the resolution to capture the gradient
correctly.
plinss: It lets everybody do the right thing to the best of their ability.
RESOLVED: Accept plinss's proposal.
* ChrisL is okay with that
<arronei> I want my infinite resolution monitor
TabAtkins: Image values is becoming divergent in implementation stability.
Some features like gradients widely implemented, others have no
impls or are just beginning implementation.
TabAtkins: In the interest of getting gradients unprefixed as soon as
they're sufficiently stable, I'd like to either pull gradients
out into a Gradients spec, or go through and kick a bunch of
stuff into css4-images
TabAtkins: specifically, the image() function, the cross-fade() function,
and image-* properties
<ChrisL> which is larger, the bits you cut out or the bits you leave in?
JohnJansen: I think pulling out Gradients would make it easier.
sylvaing: If you move the others, you're still splitting the document.
<fantasai> ChrisL, about equal
<ChrisL> oh
fantasai: There's some things that should move just as fast as gradients.
Also you need to define <image> type so we can reference it.
TabAtkins: CR can reference WD, so it wouldn't delay CR, just REC
TabAtkins: I just want to get Gradients to a point where we can kill prefixes
TabAtkins: I don't care either way; WG decide for me.
<sylvaing> http://dev.w3.org/csswg/css3-images/
TabAtkins: So, we would keep 4.1. 4.3 is implemented in Mozilla, so keep
that there. We can test it for now.
TabAtkins: 4.2 and 4.4 would go
TabAtkins: Gradients stay
TabAtkins: 6 stays; object-* implemented already, rest is image sizing algorithm
TabAtkins: Rest can be punted to level 4
<ChrisL> I suggest splitting into css3 gradients and css3 images. because
css4 images sounds like its years away, just from the name
<fantasai> ChrisL, we'll publishing Selectors 4 next month ;)
<ChrisL> my point about perception stands, regardless of any actual facts :)
dbaron: Things without 2 impls should be at-risk
TabAtkins: 9 is a separate issue we need to discuss
smfr: Seems we need cross-fade() to interpolate gradients
Florian: We could pull back into 3 if it stabilizes before CR
<ChrisL> @smfr you mean to interpolate as in a transition, not to draw
the gradient?
plinss: Any objections to splitting along the lines described?
<smfr> ChrisL: my point is that interpolation of gradients and images
should be in the same spec
RESOLVED: Split css3-images as described
TabAtkins: 3rd issue is about gradients directly
TabAtkins: I've been messing with keyword definitions for gradients
TabAtkins: Right now you can specify linear gradients by keyword or angle
TabAtkins: Some very informal polls on twitter, if you ask someone what a
gradient with top should do, they agree with the spec
TabAtkins: If you ask them about angles, they agree with the spec
TabAtkins: If you ask them both at the same time, they say they should be
the same, despite that being inconsistent with their previous
answers
TabAtkins gives statistics for his sample size of < 20
TabAtkins: Given this, I think the angles are very easy to see, but the
way keywords work right now is confusing
TabAtkins: So I'm thinking we should drop keywords and work them out
better for level 4
<TabAtkins> data:text/html,<div id=one></div><div id=two></div><style>div {margin: 50px; border: thick solid black;width:
520px;height: 300px;}#one {background: -webkit-linear-gradient(top left, red, white, blue);}#two {background:
-webkit-linear-gradient(-60deg, red, white, blue);}</style>
TabAtkins: We have an issue that corner-to-corner gradients, for example,
are not sufficiently pretty.
<bradk> here's mine: http://www.bradclicks.com/cssplay/linear-gradient/corner-to-corner-gradient.png
TabAtkins: The top one is what corner-to-corner gradients currently do
TabAtkins: The gradient bands are perpendicular to the diagonal gradient line
TabAtkins: But the lower picture is what people actually expect/want
TabAtkins: The two are different by the angle being reflected over the
line y=x
<dbaron> data:text/html,<div class=one></div><div class=two></div><style>div {margin: 50px; border: thick solid
black;width: 520px;height: 300px;}.one {background: -moz-linear-gradient(top left, red, white, blue);}.two {background:
-moz-linear-gradient(-60deg, red, white, blue);}</style>
TabAtkins: one is 30deg other is 60deg
<dbaron> (for those who don't want to use WebKit to look at it :-)
Brad: Another way to say is that for corner to corner, the hypothetical
midpoint connects the other two corners
TabAtkins: With the current spec, the further the rectangle is from a square,
the more it looks like a sideways gradient rather than a
corner-to-corner one
TabAtkins: Given this issue, I want to drop keywords for now and address
them in level 4
bradk: Keywords are the most popular way of doing this right now, mostly
vertical or horizontal gradients.
Brian: Instead of up top and bottom, use upwards and downwards and instead
of left and right use leftward rightward
Brian: And remove the paired keyword corner options
plinss: If we do partial keyword option, then we're locking in our syntax
and it'll be incompatible with our future syntax.
plinss: We'll get into a situation where we dislike our legacy keywords
and can't change them.
TabAtkins: Could use a different function
dbaron: Authors really want gradients. At some point we need to stop fiddling
with it and declare it ready.
anne: We did that with border-radius, and by the time we got it sorted out
they weren't popular anymore. :-)
<arno1> We could just have "horizontal" and "vertical" as keywords
Florian: We're not throwing out all of it, just part of it
Florian: just the part we don't agree on it.
TabAtkins: We solve the cases we know we need now, get them unprefixed,
then see if the remaining cases are useful enough to care
Brad: the only gradient generators online use the keyword types right now,
and because we changed the angle definition, you can't get something
that works
Brad: People use prefixed versions for years.
TabAtkins: We're not going to change prefixed versions
Brad: Because we changed meaning of degrees, you can't make a backwards
compat version
TabAtkins: You write the prefixed versions with the old syntax, do
unprefixed version with spec version
various try to explain that prefixed versions aren't going to change;
they'll change when they drop the prefix
plinss: How vendors deal with them and their customers is up to them.
Brad: I don't think we can pretend what we decide here is not going to have
ramifications. If we don't have a committment that they won't do that...
otherwise we wind up with something unusable
TabAtkins: That's why nobody will do that.
dbaron: We've done it plenty of times, but we probably wouldn't do it with
this one
Anne: It worked fine for border-radius, -moz-opacity, etc.
Brad: I'd like to keep the keyword going and figure it out before we publish
it.
Arron: Do you have a problem with upwards/downwards/etc
Brad: As plinss pointed out, it'll make it harder for us to get a consistent
syntax later when we add corner-to-corner gradients
TabAtkins: The future has potential. I'm confident I'm not blocking my
ability to expand in the future.
Brad: I don't see the syntax as being problematic.
Brad: I don't think it needs to change.
* fantasai thinks Tab's questions were skewed
Brad: It's intuitive for a lot of people, and they've learned it, and do
we really want to hold up the spec for this.
...
smfr: I'm concerned about having multiple gradient functions. Do I need
linear-gradient or corner-gradient?
smfr: This will just add to the confusion.
TabAtkins: I think we can have a syntax that's different enough there won't
be a parsing ambiguity
Brad: "from top" would be close to current syntax and resolve ambiguity
Brad: "left" -> "rightwards" is more different
plinss: The question was about whether to drop the keywords, not about
what they should be
plinss: So do we drop the keywords, or go offline and figure it out
TabAtkins: I want to drop the corner keywords
plinss: Sounds like we're don't have consensus
plinss: Take it to email/telecon
plinss: Any other gradient issues?
Brian: Premultiplied? Keep it don't keep it have options?
TabAtkins: I think premultiplied produces most attractive gradients in
common cases blending with transparent.
TabAtkins: I can go either way, depending on implementers
fantasai: If you go other way, then make 'transparent' magic.
TabAtkins: I don't want to make transparent magic.
Brian: Drop 'transparent' keyword, make everybody use rgba()
Tab: If we're going to go non-premultiplied, then disallow use of
'transparent' and make everybody use rgba()
fantasai: That's horrible. You're making the author do the work.
Brian: You have the same problem with transitions.
fantasai: gradient from color to tranparent is very common use case
smfr: Reality is that if we go with premultiplied we won't have it
working correctly on Mac for another year or so
anne: If it's just a year, I say head for the future.
smfr: It could be more than a year.
Vincent: Example of where premultiplied looks better?
<nimbupani> http://jsfiddle.net/rK9Pd/11/show/
<nimbupani> (check in webkit vs opera)
TabAtkins: yellow to transparent, in premultiplied goes from yellow,
fading to transparent
TabAtkins: in non-premultilied, goes through an ugly grayish greeny color
TabAtkins: If you go red - transparent - blue, if you want to make it
work correct in non-premultiplied, you have to write red,
transparent-red, transparent-blue, blue, placing transparent-blue
and transparent-red at the same spot in the gradient
plinss: Why don't we want to do premultiplied?
TabAtkins: It's not natively available on some platforms
smfr: We'd have to get libraries to add it
Brian: Alan Gresley was asking about non-premultiplied gradients because
there are some cases that you'd want that result
TabAtkins: You could simulate it by manually arc it through the color
space, it's tricky, but doable, and a very uncommon case in
comparison
Someone asks who supports premultiplied today.
Brian: I had good results with Opera
TabAtkins: With Opera and IE we'll have 2 impls, so let's stick with that.
RESOLVED: Use premultiplied colors for gradients and transitions
shepazu: At the outset of this effort, there was discussion about remaining
compatible with SVG gradients.. was that abandoned?
TabAtkins: No. SVG doesn't have alpha colors.
shepazu: Talking about geometry
TabAtkins: Yeah, I don't think that's useful. But I was going to talk
tomorrow about using SVG paint servers in CSS or CSS gradients
in SVG.
shepazu: So an engine supporting both will have to support two different
things.
TabAtkins: Yes.
plinss: Ok, let's discuss that tomorrow. Grids.
* ed wonders what this meant: "TabAtkins: No. SVG doesn't have alpha colors."
(most if not all browsers already support rgba/hsla syntax in svg
colors/gradients, also there's stop-opacity in svg gradients)
CSS Grid Layout
---------------
Phil: My name is Phil and I'm from MS.
Phil: We recently published new editor's draft. Hoping none of it's
controversial so we can go through it quickly.
Phil: With one possible reduction in functionality in grid template property
Phil: specifically, assinging display types to grid pseudos
ACTION Phil: Post notes to www-style or www-archive so they can be put
in the minutes
<smfr> http://dev.w3.org/csswg/css3-grid-align/
Phil: 7.2 covered explicitly defined grid cells, creating named grid cells
Phil: You could place children of the grid into them. We're removing that
Phil: Removing grid-stacking property, which said which layout this
explicitly-defined grid cell would be using
Phil: The other mode it had was layer, which was the default layout type
for a grid cell so items would layer on top of others
Phil: When we presented that at MV ...
Phil: Talked about creating flows inside a grid cell
Phil: And assigning display types to the grid cell
Phil: This was about creating presentation-specific structure through
declaration of these grid cells, trying to remove concept form the
grid layout spec
Phil: We also added new paragraph about grid cell concept. We still have
logical notion of a grid cell, but it's just an alias syntax for
referring to a region of the grid.
Phil: But we're saying it's not stylable
Phil: It's just a way to name a spot on the grid
Phil: In section 6.4 , repeating columns and rows. We got some feeedback
that the named lines syntax we had didn't make sense inside repeating
syntax
Phil: Since it defined that only the first occurance of the name would be
honoree, and purpose of repeat syntax is to replay the grid lines over
Phil: Added issue as to whether to remove that ability from there
Phil: Any feedback, send it, otherwise we'll remove
Phil: We also had another isuse on the grammar, for grid columns and grid
rows
Phil: So we changed from ... to ...
Phil: I'll let you figure it out; trust me the new one is better.
Phil: Section 7.1 anonymous grid cells, we just added some language about
relation between grid cells
Phil: Now it's just logical container, what does it do to grid items inside.
Phil: Define them as containing block
Phil: And we said how they came into being, added language defining
dimensions of the grid cell etc.
Phil: Next is explicitly defined grid cells, 7.2 is gone
Phil: Defining grid cells with a template is still there
Phil: Still use the ascii-art syntax
Phil: Keeping around grid-cell property, just don't have pseudo-element
selector
Phil: Can still define grid, and put things in it
Phil: with that
Phil: Section 7.5 automatic placement of grid items.
Phil: It's no longer what we're thinking, so removed note
Phil: ...
Phil: Importance of automatic placement, some language about fixup of grid;
it matches language in flexbox
Phil: And we noted that if we don't have this fature, the fixup isn't useful
Phil: Everything just gets dumped into first grid row. We're planning to
leave in, so this is just an observation
Phil: I just renamed section 8.1 .. size of grid items.
Phil: Needs more work; need to specify box model calculations
Phil: So if going to be stretched, questions like whta if you have a replaced
element with intrinsic ratio ...........
Phil: 10 calculating isze of grid tracks. Don't know if anyone is
implementing, or thinking of implementing, but if so, we've published
some pseudo-code about sizing these bits of the grid.
Phil: Some bugs in it still
Phil: We'll update a few more times before pushing to WD
Phil: Lastly all these changes captured in Appendix A
Phil: That is everything we have changed. The biggest piece is obviously
the inability now to create these grid cells that you can give a
display inside to control how they layout their contents, does
anybody have objections to removing concept from the spec?
TabAtkins: Ok with it, majority of my use cases don't need it.
TabAtkins: But if I want to use this with regions, I need to now insert
dummy elements to position them with grid ...
TabAtkins: I greatly disagree that I should put dummy divs in my doc
Markus: We think that should be defined somewhere other than grid
TabAtkins: I hate put junk into my page for the sole purpose of styling.
Tab tries to explain the difference between semantic markup and stylistic
presentation to the MS folks
Steve: Aren't templates a little bit of both?
TabAtkins: As long as we keep in mind that we might want to do this more
generalized in the future, then I'm cool.
<bradk> If the CSS is creating the pseudo-elements, then conceivably more
regions can be created to accomodate more content.
Vincent: We have a resolution on this from the morning.
* fantasai agrees with Tab
...
Alex: One issue that we discovered ... which was that alignment in grid
is currently different from alignment in flexbox
Alex: What we discussed yesterday flexbox alignment, we kinda liked the
idea of what grid is doing now. We're going to come up with a
proposal that will make something consistent between the two.
TabAtkins: Don't think they need to be different when both flexing and
aligning stuff
Markus: Q for Peter, we experiment with named lines, and ended up with
very long strings.
Markus: Is there a way to shortcut this somehow? Authoring becomes awkward.
Phil: This example uses template
Phil: It only takes one letter to name a position
Phil: with named grid lines
Phil: You end up putting 4 strings for each item that you had
Phil: It gets a little verbose
Phil: I think in practice if you have a grid, and have a large number of
grid items
Phil: And don't want to renumber them, you probably won't use named lines
anyway
TabAtkins: What wins if you use grid-rows, grid-columns
Phil: If the grid cell exists, then it wins
TabAtkins: What properties apply to grid template?
...
Phil: You can only use ascii letters in grid template
Florian: Disallowing punctuation doesn't disallow Chinese characters or
accented characters...
TabAtkins: Most reasonable layouts won't use 26, but last year I was
looking at some very complicated layouts that were pushing it
Arron: I had 180 in a layout I did
TabAtkins: I think you should say any single character
fantasai: grapheme cluster
...
<dbaron> I wouldn't allow more than characters that are allowed to start
identifiers.
Phil: Would you use numbers ... ?
dbaron: That includes most of Unicode except some ascii punctuation and stuff
plinss: Where it gets unweildy with grid names, it's not so much where
they're defined as where they're used
<dbaron> template: "北北北北" "西中中东" "西中中东" "西中中东" "西南南东";
...
plinss: I'm not concerned about the verbosity of the grid columns declaration
plinss: If you line it up like that, I think it's readable
plinss: Later when you do the grid-column ...
Phil: You have up to for lines for positioning, so that's not too bad.
Phil: But if you have a lot of grid items, that gets quite large
plinss: Depends on how large your grid is
Phil: No issues open on it, these are just some comments we got back
plinss: Maybe you can have something that maps grid cells back into named
grid lines
plinss: Right now you can only do that with template.
plinss: What if you could define a grid-cell "foo" defined by these named
lines
plinss: You're not defining the grid template, so not single-letter names;
use multi-character names
Phil: We had ::grid-cell() pseudo that could do that
Phil: It was styleable enough that you could specify the ...
Phil: Ultimately we pulled that out
Phil: Anything else?
fr unit and flex
----------------
TabAtkins: Alex and I were talking about dropping the 'fr' unit and just
using the flex() function for flexbox
Alex: Flex function can do everything fr unit can do in flex, but fr unit
is just a shortcut for one of the use of flex function
<dbaron> Isn't 'fr' a shortcut for one of the uses of the flex() function
that requires all three arguments?
Alex: In a grid fr is a basic of how it is calculated
Alex: it would be .. also allow flex function in grid, in which case you
could replace fr unit with it or have both
Phil: right now we have minmax function, and can mix that with min-content,
max-content keywords
Phil: Would we introduce flex() function there?
Alex: flex function has flexibility and preferred size
Alex: ...
Alex: Auto and flexibility at once.. produces the same calculation ..
maximum, however preferred size of column based on content
Phil: There's just an issue we haven't resolved in the spec now
Alex: For flexbox you don't specify 50 values for an items, so flex()
being longer than a unit is not a big deal, but on a grid probably
wouldn't want to replace fr unit with flex
Alex: Make it even longer
Alex: So if in grid definition fr is shortcut for flex(), we could keep
it for flex
TabAtkins: I'm uncomfortable with two of us using different notions of flex
dbaron: fr right now is equivalent to flex() on a basis of 0, and 0 is
not the default for that third argument
TabAtkins: I changed flex() ...
TabAtkins: If you say flex(1), you start from zero
TabAtkins: That's not what my spec says right now
Alex: the omitted preferred width should default to initial value
TabAtkins: Ok, we need to discuss this
dbaron: I agree with Alex, but I think that's another reason to keep fr.
CSS Positioning
---------------
Arron: We submitted our proposal for floats and positioning, and we decided
to split those. Alex volunteered me to do the editing
<arronei> http://www.interoperabilitybridges.com/css3-positioning/
Arron: So you can take a look at it.Not too many differences from 2.1
Arron: Most of it's what 2.1 says, with some little clarifications of
handling our new value. So you won't see a lot of differences.
Arron: Will jump straight to some changes.
Arron: So our first change that we have here is page positioning.
Arron: What this defines is a way to go straight for the initial containing
block, much like fixed positioning does but without fixing on the page
Arron: So size and positioning based on initial containing block
Arron: It'll go all the way to the initial containing block, and positioning
off of that box.
Arron: That's the first part.
smfr: How is it different from position: fixed
Rossen: If we create a region each the size of containing block, you want
to have one positioned to the current region
Rossen: Don't want to rely on how many relative and abspos elements in your
ancestor chain
Rossen: Different from position: fixed because in scrolling media, it's
fixed to initial contianing block. So element scrolls along with
the rest of the content
Rossen: Similar to abspos content that has no positioned ancestor
Rossen: Whereas fixed replicates
Rossen: Position page was specific to design so you can target only the
current page, and unlike position: fixed; position: paged;
elements ... you can position negatively, and you can overflow,
and that's just fine, whereas fixed position that just clips
dbaron: So it's positioned on the current page relative to its placeholder.
fantasai: My concern is that you'll get a layout that makes sense on
paged media, but breaks in scrolled. Opposite problem of fixed
positioning.
fantasai: e.g. if you use this on a 15-page document, positioning 15-20
things throughout the document across the 15 pages, looks fine
fantasai: Load that into a scrolled view, and everything piles on top of
each other in the first screenful, and then scrolls away with
nothing in the rest of the document
...
Alex: We should have discussion of what are different aspects of paged media
Alex: Some means it's non-interactive, you're on paper
Alex: Some of it means you're paginated
Alex: From pov of layout, it's tempting to apply paged media to regions.
But it's not paged media
Alex: Should we have a new media type?
fantasai: I think so.
Arron: What I'm trying to get here is, we have this defintion right now,
it may need more work as fantasai points out.
Arron: What I'd like to do is put it up on W3C as an actual editor's draft,
so we can start to shape something that works
plinss: Anybody objecting?
RESOLVED: Put CSS3 Positioning draft on dev.w3.org
Arron: That's pretty much it. Please review once it's up
plinss: Some flexbox issues to get back to?
TabAtkins: Haven't had time.
Alex: Directions and alignment; need to ...
plinss: Meeting closed.
Received on Wednesday, 3 August 2011 05:51:21 UTC