W3C home > Mailing lists > Public > www-style@w3.org > May 2010

[CSSWG] Minutes and Resolutions 2010-05-05

From: fantasai <fantasai.lists@inkedblade.net>
Date: Sun, 16 May 2010 00:45:23 -0700
Message-ID: <4BEFA293.5090402@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>

   - Reviewed status of CSS2.1 test suite
   - Discussed the rest of CSS3 Fonts issues in Bert's email
   - 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 ======

   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
   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

   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
   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
   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
   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
   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.


   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
   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
   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?


   <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
   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
   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

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:46 UTC