- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Sun, 16 May 2010 00:45:23 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- Reviewed status of CSS2.1 test suite
- Discussed the rest of CSS3 Fonts issues in Bert's email
<http://lists.w3.org/Archives/Public/www-style/2010Mar/0553.html>
- Dealt with a couple editorial Selectors 3 issues
- Reviewed review of View Modes spec
- Discussed representation of media queries in the OM
- RESOLVED: change CSS3 so @media accepts no media after the keyword.
- Discussed definitions of spread and blur radius for box-shadow
====== Full minutes below ======
Present:
Tab Atkins
David Baron
John Daggett
Arron Eicholz
Elika Etemad
Simon Fraser
Sylvain Galineau
Daniel Glazman
Brad Kemper
Chris Lilley
Peter Linss
David Singer
Steve Zilles
<RRSAgent> logging to http://www.w3.org/2010/05/05-CSS-irc
Scribe: Tab Atkins
Test Suite Status
-----------------
peter: Anything on the agenda?
peter: First topic: test suite status
arronei: I've made good progress on tagging all test cases, and am still
on track to have them all tagged/checked in this friday.
fantasai: I talked with Richard about the i18n tests. He's in India
right now, and he'll get back to me next week. For now I'm
going to work on getting the reftests in, then I'll work on
getting Hixie's test into a format we can use. The conversion
shouldn't take too long, but there may be some missing files
somewhere.
arronei: I may be able to find them. We'll figure it out.
peter: Sounds like progress is being made.
CSS3 Fonts Issues
-----------------
<jdaggett> http://lists.w3.org/Archives/Public/www-style/2010Mar/0553.html
jdaggett: We went through a bunch of these.
jdaggett: We got through part of Bert's comments last week, through point G.
jdaggett: Remaining ones are h through k.
jdaggett: H is titling-caps. It's not really ideally specced, it's
really "titling form".
jdaggett: There was a suggestion from John Hudson about how to rewrite that.
jdaggett: Part I, I went through and changed some of the values from
e.g. lining-nums to lining-numerals
jdaggett: ChrisL, you said you think just doing nums would be fine?
ChrisL: Yeah, I think it's fine.
peter: I think in general we should spell things out. If it's a
well-known abbreviation or shortening, ok, but otherwise
lets just use the long form.
szilles: I think that "num" is an abbreviation for "number", not
"numeral", and the two things are different.
fantasai: I don't see a difference, but I'm not a typographer.
<bradk> lining-numes?
jdaggett: So, steve, you'd prefer "numeral" to be spelled out?
<dsinger> a number is the idea of 2, whereas numeral might be roman
<dsinger> ie it is the representation
jdaggett: I'll leave it as "num" for now, until someone has stronger
objections.
jdaggett: Point j is wrong, the fraction is a unicode feature.
jdaggett: Point k I put in to describe what it was, though it's really
something for the webfonts group to talk about.
jdaggett: I just didn't see why Bert thought this violated the web
architecture.
jdaggett: I don't think this is something to go into at great depth;
the fonts group will talk about it, and then we can clarify
it in our spec.
jdaggett: I'll leave it to bert to respond as he is so inclined.
(Since he's not on the call.)
<sylvaing> thinks that CSS3 Fonts can't make same-origin normative;
that's up to the Web Fonts WG. But it's relevant info for
the spec so i like to have it there
<jdaggett> http://lists.w3.org/Archives/Public/www-style/2010Apr/0000.html
jdaggett: Next is szilles comments on character-transform.
jdaggett: I think this works; I think it's probably better.
jdaggett: Only caveat is that, the way this is worded now, if an OT
font has a sub/super glyph it is used, otherwise the
rendering is "as it is today".
jdaggett: I think it would be best to specify that it falls back to
an auto-generated sub/super.
jdaggett: But that might have issues with nested elements.
jdaggett: The tricky thing with doing OT sub/super scripts is that
they can contain other elements that aren't in a typeface.
jdaggett: They need the adjusted baseline and such, frex.
jdaggett: I think we should come back to this after experimenting,
and seeing if we need to change the fallback.
jdaggett: Final issue is what to call the feature. I don't see an
ideal term here.
jdaggett: I think the most accurate was "relative-script", but other
people said that was awful.
szilles: I proposed character-shift and use-font-shift.
ChrisL: I'm not sure about the shift thing, it makes it sound like
a baseline shift.
jdaggett: If nested elements are involved, it's more like a baseline
shift.
szilles: I liked the "use-font-*", because you weren't faking it,
you were using the font data.
szilles: Or alternately, a font-variant-*? Maybe font-variant-shift.
jdaggett: For now I'll put in character-transform, and we can think
more about the name.
szilles: I can live with that.
smfr: I wanted to follow up on the discussion about turning on kerning
everywhere.
smfr: In webkit if you go down the complex kerning-on path all the
time, it significantly slows down our page performance.
jdaggett: I'm not sure that should be classified as a webkit bug.
We fun on the same platform and we don't see it.
smfr: I think david said that you only turn on kerning above a certain
size.
jdaggett: On Windows. On Mac we run with kerning on all the time.
smfr: Curious. I guess we can improve it somewhat, but I'd like to
wait for some data that it's okay.
jdaggett: I think we left that the default was 'auto', which is defined
by the UA.
fantasai: I had a comment on character-transform.
fantasai: I think, in order for nesting to work you need
character-transform to not be inherited.
fantasai: Suppose I have <sub>foo<span>bar</span></sub>.
fantasai: If it's inherited, both sub and span have
character-transform: subscript.
fantasai: I can't tell if the span is supposed to be a further sub of
the foo, or if it's suppossed to be at the same level as
everything else.
jdaggett: That's something I should play around with.
Selectors
---------
peter: Next is the Selectors stuff. Anne's not on the call.
tabatkins: I had an issue that doesn't involve anne. In Selectors,
:nth-child says that the number can be omitted if a is
1 or -1. It can't always be omitted for -1.
dbaron: You can omit the "1", but not the "-".
tabatkins: Okay, so editorial issue then, that passage is very
unclear if that's what's meant.
fantasai: I can fix that.
<dbaron> fantasai, when fixing the editorial issue, the rules
should end up saying that the sign cannot be omitted for
-1, but the sign still can be omitted (as the previous
paragraph says) for +
<dbaron> fantasai, since :nth-child(+n), :nth-child(n), and
:nth-child(-n) should all be valid
<fantasai> I'm just going to say the <code>1</code> can be omitted
<dbaron> fantasai, ok, sounds good
<fantasai> fixed - http://dev.w3.org/csswg/selectors3/#nth-child-pseudo
fantasai: Daniel sent me a message on an editorial note and I've
replied to it, but haven't gotten a response yet.
glazou: Since Anne's not here, I'm going to review the "serializing
selectors" and post detailed comments, because otherwise
it will flounder.
View Modes Spec
---------------
peter: Next topic, View Modes comments from WebAppsWG.
glazou: There was confusion last week about this.
glazou: We got two requests to review 2 documents.
glazou: First was the View Mode spec, second was the View Mode
Interface spec.
glazou: This request is the first one.
glazou: I posted comments a while ago when the first draft was released.
glazou: I didn't have time to review it completely today, but it seems
that all the changes I requested were done.
glazou: Mainly it clarified a bit what is a "windowed"/"floating"
application, and the prose is much better than it used to be.
glazou: Other than that I have no comments.
peter: anyone else taken a look at this?
tabatkins: I have, and I'm reasonably happy with it now that glazou's
comments have been accepted.
peter: So our formal response at this point is that we're happy and
have no comments?
glazou: Let me reread it again in detail, but probably yes.
tabatkins: Deadline for comments is the 18th.
Media Queries OM
----------------
peter: Next topic, empty MQ and the DOM.
peter: There was some additional discussion on the list.
peter: Where do we stand on that?
glazou: david sent a message about that, and I and Sylvain posted
followups.
glazou: IMO I think that we have 2 options.
glazou: First is to keep the syntactic rule unchanged, and change
only the OM side. But that means we have to serialize the
empty list to "all".
glazou: I don't really like the fact that you can't serialize back
to what you got if you reparse.
glazou: Second option is to change the syntax, and allow @media
with no media before the {
glazou: I spent some time thinking about it, and I think that
even if it's a change, allowing @media without a media
is better.
<fantasai> I note that we discussed this twice and both times
reached the same conclusion to make @media { } invalid
glazou: It's probably not in CSS2.1 right now, but it should be
our goal. Otherwise it's just too complex and will lead
to edge cases.
<dbaron> I think I agree with glazou.
tabatkins: I've no objection, and I like being able to serialize
back and forth cleanly.
smfr, sylvain: Like.
dbaron: FF3.6 accepts @media with no media type.
glazou: And has it mean "all"?
glazou: We just need to make sure that @media without media is a
known hack, such that we will break pages if we change this.
dbaron: Yes, "all".
dbaron: In 3.6, if you have a media rule that has media types,
and you dynamically remove all of them, that is equivalent
to "not all"
dbaron: I suggested a possible change to MQ spec.
* fantasai thought that was only if one of them was invalid
glazou: That's a different issue.
tabatkins: Yeah, but it's a confusing issue so that something needs
to be resolved.
glazou: I think a decision is needed here. So, the proposal is to
change @media in CSS3, and allow no media after the keyword,
meaning "all".
peter: Fine with me as long as we can reconcile it with the OM.
glazou: There's nothing to reconcile. We have nothing to do on the
OM side.
sylvaing: As to it being a hack, I doubt it is, since the behavior
has changed for browsers across versions. It's not
stable enough to set up as a good hack.
glazou: So no objections?
RESOLVED: change CSS3 so @media accepts no media after the keyword.
dbaron: Can I talk about the weird FF OM thing?
dbaron: I think that behavior is relatively logical from the spec.
<dbaron> http://lists.w3.org/Archives/Public/www-style/2010Apr/0592.html
dbaron: In my post I pointed out 2 statements in the spec.
dbaron: If there's a query with an unknown media feature, or just
a media feature value, it is ignored.
dbaron: And then if all the media are ignored, it's equivalent to
"not all".
dbaron: So the weird thing is that you have to track what is ignored
to see if what you have is an "all list" or a "not all list".
dbaron: So if we want to make this interoperable, we have to figure
out exactly what you have to track.
dbaron: So if you have a list and you start removing a bunch of
queries, what exactly happens. And is it possible to
remove the queries that are ignored.
dbaron: Another way is to say that rather than the whole list is
"not all", each individual ignored query is equivalent to
"not all". And I think that's simpler for the OM as a
whole.
ChrisL: That sounds better. What was the whole "ignored queries"
thing supposed to achieve?
dbaron: It's supposed to match declarations, where if you don't
understand part of it you drop it all.
Sylvain: You assume that an unknown query doesn't match.
<fantasai> you want @media unknown-query { body { color: red; } }
to not apply
dbaron: I'd like to hear what Anne thinks about this.
fantasai: I think he might have suggested it at some point.
dbaron: I think the "not all" for the whole list came from Anne.
sylvaing: So if you have queries that are ignored, and you serialize
it, will you have "not all"s in the various places?
dbaron: I think so, yes.
peter: Do you want that, or do you want to preserve what was there
when you reserialize?
glazou: I have to think about that.
peter: Otherwise you try to edit a stylesheet in an editor that
happens to not understand the new media queries, you'll
lose things.
fantasai: That's how declarations work now.
tabatkins: But we want to change that.
peter: Basically the difference between "treating it as not all"
and "changing it to not all".
dbaron: It's different from what we've always done for properties
and rules, but I think it might make sense.
peter: Don't have to make a decision on it right now; just throwing
it out there.
peter: Get someone to ping Anne.
ACTION Tab: ping anne about the MQ stuff re: empty media and ignore medias.
peter: Next topic, Tab revived a decades-old display-split issue.
fantasai: Can we skip that for box-shadow first, since we can go to LC with them resolved?
box-shadow
----------
<fantasai> http://lists.w3.org/Archives/Public/www-style/2010May/0023.html
<fantasai> http://lists.w3.org/Archives/Public/www-style/2010May/0022.html
fantasai: If we like what the wording that's in what I typed, I can
add it to the spec.
bradk: I like the new wording.
dbaron: How does it match existing implementations?
bradk: I don't think anyone matches the current spec fully.
sylvaing: I like it, but I'll circle back with Brian.
smfr: What would negative value of spread do if they would cause the
height/width to go below 0?
fantasai: I think at that point the shadow doesn't exist.
bradk: I think still missing is a bullet point saying what the shape
is if there is no spread or blur.
fantasai: The shape should be the shape fo the border box, in the
draft currently.
bradk: [issue with some of the prose concerning shape of the shadow
versus where it is drawn]
bradk: I was somewhat confused when it talks about altering the shape
before it even says what the shape is, and then it immediately
talks about drawing.
fantasai: I can move the shape part up.
smfr: Question about negative spread, will it transform a curved corner
to sharp-edged?
tabatkins: Yes.
smfr: In many cases won't negative spread just make the shadow not
appear?
bradk: Not if you use offset.
tabatkins: Or an inset shadow.
fantasai: A negative spread on an inset shadow will increase the size
of the box.
smfr: I think we might come to weird behaviors where the shadow
disconnects from the edge of the box.
fantasai: Spread changes the position of the shadow's edge.
fantasai: It doesn't make the shadow move.
smfr: The way shadows are implemented, you take the box, blit it to
a bitmap with whatever color, then apply a gaussian blur.
smfr: Then spread changes the shape with some not very well-defined
algorithm.
fantasai: Now the algorithm should be quite good.
<fantasai> http://lists.w3.org/Archives/Public/www-style/2010May/0022.html
smfr: My problem is that spread isn't a transform on the box, it's
some additional change on the box.
smfr: We can't map that to an efficient hardware implementation.
smfr: Ideally we'd want to push this to the GPU, but we can't map
spread to the GPU.
tabatkins: Would a scale rather than a spread allow pushing to the GPU?
<bradk> I got dropped
sylvaing: Yeah, a scale with the border-radius proportional allows
you to easily do it in the GPU.
<bradk> Scaling is not spread
tabatkins: Brad's the only one with sufficient experience in
Photoshop et al, I think, so we just need to know if
spread is *so useful* over a scale that it's worth
the more difficult/slower implementation.
ChrisL: Scale and spread are different in general, but for rounded
boxes they're much more similar.
sylvaing: I trust Brad to know if spread radius is more important
to designers than a scale.
<bradk> Im not on the call any more, and can't get in again
* tabatkins I'm minuting as we talk, Brad. ^_^
<bradk> Scale would just be a completely different thing.
peter: So move to mailing list until next week.
fantasai: So is the question about whether people like/dislike
spread, or if we want spread at all?
<bradk> What I was starting to say is that the shape with spread
applied is really no different that a shape with an extra
border applied
smfr: If we have spread, we'd like it specified in a way that
allows hw accelaration.
<bradk> or an outline
smfr: Using scale would probably be the only one.
<bradk> except that the border-radius affects the inside radius
of that fake border
ChrisL: If you take the raster image, blur it, then do a threshold
operation you'll get a spread.
smfr: That's two blurs, though, which is expensive.
<bradk> If you want it to be a raster effect, then you don't get
sharp corners
tabatkins: Brad's pointing out that a spread is just like increasing
the border. Is that okay?
fantasai pastes the proposed definition from the email into the IRC log
smfr: That might be okay. Sorta confusing with inset.
<bradk> In PhotoShop, there is a filter called "minimize" that has
that sort of effect
fantasai: I will draw pictures for you.
fantasai: Or maybe Brad can draw pictures.
<bradk> For inset, it is like figuring out the shape of the content
box in the presence of padding
<bradk> sort of
<glazou> BTW, IE9p2 has MQ ! congrats MSFT
<ChrisL> I noticed that too but have yet to test it
Meeting closed.
* sylvaing only looks at images in specs..
* tabatkins sylvain, crap, that means I have to draw more pictures.
<bradk> I've been meaning to draw a diagram anyway...
<fantasai> bradk: We'll need two, I think.
<bradk> outer and inner?
<fantasai> bradk: One for the strict definition of spread
(perpendicularly outward/inward)
<bradk> OK
<fantasai> bradk: And one for the approximation
<fantasai> bradk: which alters the width and the radii
<fantasai> bradk: they're not quite the same
<bradk> Im not sure I understand what approximation that's different
<fantasai> So, if you take an ellipse
<fantasai> and you stroke it with the inner edge of the stroke being
the ellipse edge
<fantasai> the outer edge will not be an ellipse
<fantasai> Strictly speaking, that's what you want for spread -- an
offset, perpedicular to the edge, of the spread amount
* bradk is still parsing that sentence
<fantasai> Imagine an ellipse with arrows pointing outward from the edge
<fantasai> like a sun, except elliptical :)
<bradk> OK
<fantasai> If the arrows are all the same length
<fantasai> and you draw a shape connecting their tips
<fantasai> you will not get an ellipse
<fantasai> You will get something that looks almost like an ellipse,
but is not an ellipse
<fantasai> in the strict mathematical sense
<fantasai> in other words, you can't get it by defining slightly
different elliptical radii
<bradk> Umm... That is pretty much how Illustrator 88 used to do it,
I think.
<fantasai> Strictly speaking, that outward offset of the edge is what
you want for a spread
<bradk> sweeping a 1px line around the path to get a border
<fantasai> or 5px or whatever
<fantasai> yes
<fantasai> But since that's not an ellipse
<fantasai> it might be hard to calculate
<fantasai> So that's why there's an alternate definition there
<fantasai> that allows you to approximate the shape by altering the radii
<bradk> Do you mean because the "connect the dots" part is not a
smooth curve?
<fantasai> no, make it a smooth curve
<fantasai> # arrows -> infinity
<fantasai> It's not about the smoothness, it's about the geometry
<fantasai> For a circle, if you do that, you will get a bigger circle
<fantasai> but for an ellipse, you don't get an ellipse, you get
something that looks like an ellipse but doesn't match its
mathematical form
<bradk> OK. I think I have seen this, come to think of it. I will
play around and see if I can recreate the difference.
<bradk> The idea of just scaling the elipse instead of offsetting the
path is more palatable to the implementors?
<bradk> I have to go. Will try tinking with clear diagrams/illustrations
of the concepts tonight or soon thereafter.
<tabatkins> Yeah.
<bradk> OK. Bye.
Received on Sunday, 16 May 2010 07:46:31 UTC