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

[CSSWG] Minutes and Resolutions 2010-02-10

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 10 Feb 2010 11:27:47 -0800
Message-ID: <4B7308B3.5060509@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
   - CSS2.1 testing:
         Reftest documentation added to testing wiki <ttp://wiki.csswg.org/test>
         Build scripts still need a rehaul
   - Next F2F March 29-31. Agenda: <http://wiki.csswg.org/planning/cupertino-2010>
   - RESOLVED: Richard Ishida will be editor of CSS Ruby spec.
   - RESOLVED: CSSWG has no problem with deprecating DOMActivate
   - Discussed scientific notation again, because apparently SVG already uses it.
     Concerns include:
       * Confusion about where exactly SVG allows scientific notation and in which
         versions this is allowed.
       * Allowing it in CSS would require changing the core grammar, which is supposed
         to remain stable.
       * Allowing it would create a new syntax for all CSS properties that accept
         numbers and lengths that will be accepted by newer implementations but
         rejected by older implementations. This has backwards-compat and browser-hack
       * Whether overall usability is increased or decreased by introducing scientific
         notation in CSS is debatable.
     No resolution was reached.

====== Full minutes below ======

   CÚsar Acebal
   Tab Atkins
   David Baron
   Bert Bos
   Beth Dakin
   Arron Eicholz
   Elika Etemad
   Simon Fraser
   Sylvain Galineau
   Daniel Glazman
   Brad Kemper
   Chris Lilley
   Peter Linss
   David Singer

<RRSAgent> logging to http://www.w3.org/2010/02/10-CSS-irc
ScribeNick: TabAtkins


   plinss: Anything extra for the agenda?
   * sylvaing dares not add anything to the agenda that would take over the whole meeting again :)

CSS 2.1 test suite

   plinss: Anything interesting?
   fantasai: Just fixing glitches in some of the publications
   arronei: I'll send in a few more errors I found.  Simple stuff.
   fantasai: Any progress on metadata?
   arronei: I started it, but got sidetracked.
   fantasai: I put up documentation on reftests on the wiki: what it is,
             how to write one
   fantasai: There no reftests in the alpha right now, because there's no
             sensical indexing method right now.
   fantasai: Plan for the next day or two is to list everything that's wrong
             with build scripts so we can fix them.
   ChrisL: Since we can't have reftests at the moment, should we still be
           making them?
   fantasai: Yes, it's a good format, and we'll get it published.
   fantasai: You can also write a test that is both a reftest and a
             self-describing test.
   plinss: Anything else in the test suite?

FtF - reconfirming dates

   <dsinger_> Yes
   plinss: Current have March 29 - 31.  Still the plan?
   ChrisL: I thought that one was fine, but the *next* one had a request to
           change it?
   fantasai: Yeah, we did.
   glazou: I wanted it on the agenda so the SVGWG would know about the
           firm date we have.
   dsinger: How do I get the official announcement out about location/suggestion
            to stay?  How do I get people to announce they're coming so I can
            arrange everything?
   ChrisL: Just do a WBS form, it's easy.  And you'll be on the CC list so
           you'll see when people register.
   fantasai: Or just email the WG and say "respond if you're coming".
   glazou: If you could publish a list of hotels asap, it would help.
   plinss: There's a page on the w3c server with a bunch of pertinent information
           from previous meetings.
   dsinger: I assume it'll be a small enough group we can do lunch in the
   ChrisL: Sounds fine.
   plinss: and if we do a joint meeting with SVG, can you handle that on site?
   dsinger: How many people are likely to join us?
   glazou: I think Doug said the SVGWG was fairly small, maybe 6-7 people
   dsinger: Ok.
   plinss: Do we want to set the 31st as the joint meeting?
   glazou: I suggest we ask the SVGWG what's most convenient.
   plinss: We're okay with dedicating one day of our meeting?
   glazou: Yes, I think so.
   plinss: Elika, can you set up a wiki page for the agenda, so we can start
           posting suggested topics?
   fantasai: Will do.

   <fantasai> http://wiki.csswg.org/planning/cupertino-2010

Richard Ishida editor for ruby

   several: in favor
   <sylvaing> very in favor
   ChrisL: Not only would he be a good editor, but he'll make tests and
           write tutorials and such.
   glazou: Does Richard know about it? ^_^
   ?: Yes
   fantasai: Is the ruby spec on dev.w3.org, or doees it need to be moved?
   Bert: I think it's already there, but he knows how to move it if necessary.
   ChrisL: I'm sure he doesn't have a huge patent portfolio, but still, might
           as well have him join.
   RESOLVED: Richard Ishida will be editor of CSS Ruby spec.

Deprecating DOMActivate event

   <plinss> http://lists.w3.org/Archives/Member/w3c-css-wg/2010JanMar/0009.html
   plinss: Schepers sent an email a while back.
   ChrisL: How does that affect CSS directly?  Are there any pseudoclass defs
           that explicitly mention DOMActivate?
   plinss: There's a note about a potential issue with the :active pseudoclass.
   plinss: But I don't believe it's the same concept.
   plinss: Not hearing any objections, so I assume we should just say "Go for
   RESOLVED: approve deprecating DOMActivate

CSS3 values

   plinss: One thing we were etalking about is accepting scinot in numbers
   ChrisL: That relates to a response I made about the style attribute.
   plinss: And they were saying it would be nice to accept scinot across the
           board rather than special-casing it for SVG.
   ChrisL: I agree.  Special-casing is harder to work than just doing it
   plinss: There were some questions about precision, and roundtripping, and
           so on.  I think it makes sense to allow scinot across the board.
   Bert: I don't see why we need scinot in, say, typography.
   plinss: It will probably come in handy in transforms.
   howcome: I don't quite see the use-case either.
   plinss: Do you see sufficient harm in including it?
   howcome: There's a compatibility issue.  Can someone point me to a use-case?
   <dbaron> In CSS1 and CSS2, '3.6e-10' is a dimension, where '3.6' is the
            number and 'e-10' is the unit :-)
   smfr: [Gives example with transformations]
   howcome: What does this look like?  2.6e4 or the like?
   smfr: Yes.
   howcome: The notation has nothing to do with the precision.  It has to do
            with what people type.  I don't think people have to type e4 or
   ChrisL: Are you going to object?
   howcome: I'm not going to object *yet*, but I'm not sure of the use-case.
   * TabAtkins Hrm, I may have gotten some of howcome and bert mixed up.
   <dbaron> It also means reading things like '2.6e4em'
   plinss: The only thing it really precludes is us ever having a unit named "e".
   dbaron: Or starting with e and followed by numeric characters.
   howcome: My issue is really readability.  I don't think it's intuitive.
   plinss: The use-case isn't really when it's like 2.6e-4, it's like 2.6e-30,
           which is way easier to read than .00000...26
   bert?: In what cases is that not 0?
   <dsinger> is allowing scientific notation *harmful*?
   plinss: In matrix transforms it's not equivalent.
   <dsinger> it may be unusual, but does that matter?
   * fantasai doesn't really care, but thinks it's unfortunate that SVG-derived
              properties and CSS properties have different allowed syntaxes
   * smfr hopes that this topic doesn't take the rest of the call
   * dsinger wonders who doesn't have a scientific notation parser
   ChrisL: We've already had apple and mozilla already say they want to do it
           to harmonize CSS and SVG.
   [argument about readability of scinot]
   sylvaing: We have a way of writing large numbers.  When you get large enough
             it's no longer comfortable to use normal numbers.
   <dbaron> I'd note there were a few fun (though far from insurmountable)
            issues with implementing scientific notation  (see Mozilla bug
            302971):  it requires more pushback in the tokenizer than anything
            else does (with the possible exception of URL, depending on how
            you implement it); according to SVG it's only allowed for <number>
            and not <integer>;
   fantasai: My problem is that SVG and CSS properties have two different
             syntaxes. I don't care about the details as much.
   glazou: Proposal is to add scinot to values in CSS.
   <dbaron> If my memory is correct, the issue with SVG and CSS accepting
            different syntaxes applies only to SVG attributes and not actually
            CSS in SVG.
   fantasai: If it's an issue with SVG attributes only, I don't think it's as
             much of an issue.
   ChrisL: No, you can do things like put it in a style attribute, and it's
           weird for people to mix it with normal CSS and not be able to use
           notation broadly.
   fantasai: But if it's not there yet, it's not an issue yet.
   ChrisL: It is there yet.  The problem is that the Style Attribute spec
           now disallows it, but before it was allowed to mix the notations.
   fantasai: the issues wrt css-style-attr is a totally separate issue
   ChrisL: It's a blocking issue for SVG.
   ChrisL: 1) allow it everywhere, anywhere there's a number 2) disallow it
   * TabAtkins didn't catch that there weree ethree separate things
   fantasai: Anywhere there's a number, or numbers and dimensions
   dbaron: There's 3 things: number, integer, and dimension. SVG doesn't allow
            it for integer, but doees for the other two.
   ChrisL: If CSS wants to allow it for all 3, I'd be willing to take a change
           request back to SVG to harmonize it.
   dbaron: I'd rather avoid it for integers.
   glazou: 1) Allow it only where it's permitted. 2) Allow it where SVG does.
           3) Disallow it.
   * dbaron didn't follow (1), at least as Tab minuted it
   ChrisL: Only allow it where the individual property says it's allowed.
           Second option is to allow it everywhere that takes a number/dimension.
   glazou: In favor of 2
   <dbaron> (1) is allow it when the property says it's permitted, and
            (2) is allowing it for all <number> / <dimension>
   ChrisL: 2 for me as well
   plinss: 2
   <sylvaing> 2
   <bradk> 1
   smfr, tabatkins: 2
   <@arronei> 2
   fantasai: I'm in favor of whatever dbaron's in favor of
   <dbaron> I think if we allow it we should do (2).
   * dsinger I support smfr and dethbakin
   <bradk> 2 is OK with me, but I think 1 would be more intuitive
   howcome: I don't think we should allow it.  I think it's more readable and
            easier to parse.
   howcome: 3
   <Bert> 3 (It's just too costly, there are tons of implementations of CSS...)
   <dethbakin> 2
   ChrisL: Brad, would you be happy with 2?
   bradk: 2 is fine
   fantasai: This is for css3 only, right?
   ChrisL: It would be for css3 only, but currently the style attribute for
           *any* language says you must align with css2.
   fantasai: We'll deal with that separately.
   Bert: What do you mean "css3 only"? This is a grammar question, not a
         property question.
   fantasai: What I mean is, I'm strongly against changing the css2.1 grammar
             to allow scinot.  I'm ok with it in a new css3 grammar.
   <sylvaing> so we are implicitly OK with 'new' style sheets tripping up older
              UAs right ? since the new values will not be limited to new
              features such as transforms...
   Bert: The grammar in css2.1 says it's *the* grammar for CSS.
   ChrisL: Right, the forward-compatible grammar allows it, css2.1 will disallow
           it.  We've had those problems before.
   Bert: No, we only have 1 *core* grammar.
   sylvaing: Once you make the change you'll have UAs failing stylesheets with
             the new value.
   TabAtkins: Yeah, but that happens with any new property.  Legacy UAs will
              just drop that property.
   sylvaing: I hate to point it out, but IE6 is still out there.
   Bert: There are other implementations.
   glazou: I don't like that the first SVG harmonization effort is sidetracked
           by a large discussion over this small issue.
   fantasai: It's not small.
   <fantasai> and it's not the first
   TabAtkins: Still not seeing why this is any differenet from a new property
              being dropped in legacy UAs.
   sylvaing: It's not just new properties.  I could do width:100e1px and have
             it ignored in old browsers.  Is that fine?
   howcome: Is this change worth what you get back from it?
   howcome: This is a huge change in the core, and I don't see that it's worth it.
   glazou: If you look at new pages using transformations, it's a big deal.
   ChrisL: Are we saying that Apple should go home with it's transitions spec
           because it requires us redefining the value of "number"?
   howcome: It's a change for *everywhere*, though.  It's a huge change, and
            I don't think it's worth it for everything.
   sylvaing: So you want it only for the properties that specifically need it?
   howcome: I think that's a more reasonable proposition.
   sylvaing: You'll have to look at a property when you parse a number?
   Bert: You have to do that already, like with an+b
   glazou: Right, but it doesn't require you to look at the context.
   Bert: You can say in the grammar that we can find a specific use-case for
         that property.
   ChrisL: So you're proposal, Bert, is to change SVG to something new so you
           don't have to change CSS?
   Bert: SVG is an xml spec, css isn't.
   ChrisL: Then I'll take that back to the SVG, and we'll drop saying that the
           style attribute spec is for SVG.
   dsinger: I think the objection is "scinot is ugly and I don't want to see it".
   Bert: That's one objection, the main one is that it requires changing the
         core grammar
   TabAtkins: All the UAs that handle SVG *already* handle the notation.
   glazou says something about millions of users
   howcome: Nobody's asking for scinot in the width property.
   howcome: If it's per-property, then that's easier to swallow
    ChrisL: If particular-property is required, that's okay.  But we can't just
           say something new that requires changing all of SVG.
   <sylvaing> i understand that the new notation can be used as a css level hack.
              (I raised it). but if the alternative is property-specific grammar
              and preserving arbitrary differences between SVG and CSS, it's a
              risk worth taking imo
   [discussion about required stability of the grammar]
   howcome: Bert points out that the Core Grammar has been stable, it's one of
            the core pillars.  You need really good arguments to change it,
            and I haven't seen them.
   ChrisL: Where do we go from here?  9 votes for option 2, 2 votes for option 3.
           There's a lot hanging on this.  Changing the CSS grammar, or requiring
           SVG to use a slightly different Style Attribute with subtle
   sylvaing: Is this something we want to discuss ftf? Are there other things.
   fantasai: It seems there are a lot of things that SVG allows in their syntax
             that are incompatible with CSS and 5 years later we find out about
   howcome: There's a consensus route, where we just allow it in properties that
            specifically allow it.
   sylvaing: That's specific grammars.  Is that okay with you?
   howcome: I don't think that's something new, with the specific grammars we
            use in different properties.
   smfr: Then you need a new length, in addition to a new number.  It will
         spiral out of control.
   plinss: The other side of your argument is that I don't know if it will make
           Bert happy.  Bert, would you accept scinot in specific properties?
   Bert: I don't like it, but I wouldn't object if it was localized enough.
         I don't know where you'd need it, but sure.
   ChrisL: So you don't see any place where you need it?

   Bert: The argument you gave, that I hear, is all about getComputedStyle.
   plinss: People would like to have something from getComputedStyle and
           roundtrip it back to a stylesheet.
   fantasai: Just have getComputedStyle return something proper for roundtripping
   fantasai: We discussed this a few weeks ago and concluded that we should
             specify a minimum accuracy.  The first round will have some
             truncating, but after that there's no problem.
   smfr: Yeah, the only real problem is that you may end up with a long series
         of 0s.
   dsinger: You'll be given a number in scinot, and you'll convert it to a
            number *wrongly*.  It would be better to auto-translate it.
   Bert: I'd still like to see an example of where this is needed.
   Bert: Even if I don't use it, it's still there.  It's on the books.
   howcome: It can be used in harmful ways, for obfuscation or as a switch
            for browser compatibility.
   smfr: I talked about getComputedStyle when I first brought it up, but the
         real problem is that there's no number value api that doens't involve
         converting through a string.
   smfr: We don't strictly need scinot, but it's good to have it roundtrip
         through javascript.
   howcome: I think we should define that api.

   ChrisL2: That fixes that part of the problem, but not all of it.
   plinss: A very important part of the proposal is harmonization with SVG,
           and that's very important.
   plinss: This is the very first thing we're getting into here, we're going
           to say "No"?
   howcome: So are you saying that we'll just say "yes" to every single
            harmonization effort?
   dsinger: Right, but if the w3c was moderately consistent about what is a
   plinss: We're not talking about svg coming up with a "foobar" property,
           that we can just say "Eh, keep it yourself".  We're talking about
           SVG having to define a new language.
   sylvaing: What is the benefit for authors and implementors to have different
             grammars for numbers?
   sylvaing: What is the difference?  Why not use the supersete?
   howcome: Because you make it more difficult to implement CSS.
   sylvaing: It's already implemented, though.
   howcome: Yeah, that's an argument for Opera, but not for everyone.
   TabAtkins: The only major browser that doesn't do SVG is IE, and sylvaing
              is in favor.
   Bert: We're not talking about browsers, we're talking about CSS
   Bert: If we harmonize the language, CSS would become an xml language.
         There will always be important details.
   <ChrisL2> strawman, no-one suggested that
   TabAtkins: But I don't think "how to write a number" is something that
              people expect to be different between languages.
   sylvaing: I still want to answer to what the benefit is for authors to have
             them work differently.
   sylvaing: Why should it be different?  It's confusing for authors.
   howcome: I think the pain is minor to when people read stylesheets that used
            scinot to create browser-switches.
   plinss: I don't think obfuscation is a strong enough argument.
   howcome: I think the browser-switch is strong.
   howcome: It's a change in the core grammar.
   sylvaing: I understand that, but if the problem is having property-specific
             grammars, I think it's worse.
   plinss: discussion going nowhere at this point
   howcome: We see the problem that IE comments has caused.
   plinss: This isn't going to be resolved.  We'll pick it up later.
   howcome: I still think best is to use it where we need it.
   sylvaing: We should get SVG into this conversation as well.
   glazou: Can ChrisL write it up, since he has interests on both sides?
   ACTION ChrisL: summarize the discussion about scinot on www-style.

Meeting closed.
Received on Wednesday, 10 February 2010 19:28:24 UTC

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