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

[CSSWG] Minutes and Resolutions 2010-02-17

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 17 Feb 2010 14:00:19 -0800
Message-ID: <4B7C66F3.3010108@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Summary:

   - Discussed CSS2.1 test suite status.

   - Discussed Yves' comment about background shorthand syntax for background-size
       http://lists.w3.org/Archives/Public/www-style/2010Jan/0248.html
     fantasai to write up proposal for using 'as' instead of '/' to indicate the
     background-size (as opposed to background position) in the shorthand.

   - Discussed new API for computedStyle values. People seem happy in general with
     the direction Anne is going in his drafts. See
       http://lists.w3.org/Archives/Public/www-style/2009Nov/0335.html

   - Discussed standardizing serialization of computedStyle values. Consensus is
     that having a spec for serialization is a good idea, although converging
     existing behavior to spec may be difficult and there is no consensus on
     whether we should push for converging existing implementations (due to
     backwards-compat concerns).

   - Reviewed some new information about scientific notation in CSS.

   - Started (but did not finish) discussion on image-fit issues recently raised
     on www-style: http://lists.w3.org/Archives/Public/www-style/2009Sep/0304.html

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

Present:

   CÚsar Acebal
   Tab Atkins
   David Baron
   Bert Bos
   Arron Eicholz
   Elika Etemad
   Sylvain Galineau
   David Singer
   Anne van Kesteren
   Steve Zilles

<RRSAgent> logging to http://www.w3.org/2010/02/17-CSS-irc
Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
Date: 17 February 2010
Scribe: TabAtkins

Bert: I'm chairing today, at request of glazou and plinss, as they can't attend.

CSS2.1 Test Suite
-----------------

   Bert: First item on agenda is testsuite.  What's the status?
   fantasai: Status is, I'm working on build script and trying to fix some
             of the errors in html generation.  Nothing else new to say.
   Bert: You're confident that will work fine shortly?
   fantasai: I hope so!
   Bert: Anything more coming up after that to be done?
   fantasai: My current build-script issues list:
     * preserve doctypes across conversion
     * munging sgml comments, shouldn't do that
     * htaccess merging
     * need structured directory support
     * build scripts need to filter html-only vs xhtml-only
     * adding support for reftests

background shorthand syntax for background-size
-----------------------------------------------

   Bert: Second topic, issue in background property grammar, raised by Yves Lafon.
   Bert: I just sent a reply.
   <Bert> http://lists.w3.org/Archives/Public/www-style/2010Jan/0248.html
   fantasai: We can add more restrictions on where this can be placed.
   fantasai: Or alternatively, if it hasn't been implemented/deployed yet,
             we might be able to change the syntax to not use a slash
   Bert: That sounds like a big change.
   <fantasai> something like background: url(foo.png) as 2em 2em
   Bert: There are two questions in the email from Yves.
   Bert: First, / at start isn't compatible with appendix G.  I don't think
         that appendix applies to CSS3.
   Bert: Second is if we want to allow starting with a slash. Elika, you say
         we might not want that.
   Bert: Anyone have opinions on it?
   TabAtkins: I've never used it, so I can't comment on it.
   sylvaing: What does it actually do?
   Bert: It separates size from position.  Behind slash, it's a size,
         not behind, it's a position.
   sylvaing: What happens today with it?  Ignored, or what?
   Bert: It's new in B&B3, so I'm not sure what it does today.
   anne: Per css2.1 it should be ignored.
   Bert: Elika, you had a specific idea to make this better?
   fantasai: I don't know impl status, but one alternative is to change the
             / to "as", like "url() as <size>".
   * dbaron didn't like allowing the thing before the '/' to be omitted in
            the first place
   Bert: That would maybe work, but it would be a pity to take it out of CR.
   fantasai: We may need to do that anyway, for gradients.
   sylvaing: I don't like having the separator, and being able to skip
             what comes before it.  If the slash is there, it should
             have something on both sides.
   Bert: So you want there to be a position every time there is a size?
   dbaron: Sorta, yeah.  I've lost this argument before, but...
   Bert: You have another chance to convince people.  The cost is that
         we need to change a CR.
   sylvaing: If it's not widely implemented it's not costly, it's just
             editing the spec.
   fantasai: Since it's only been CR for a few months, if we can talk
             to impl and see it's not implemented, we can change it.
   Bert: We have implementors here.  Has it been implemented?
   dbaron: We (mozilla) haven't done the shortcut yet.  Just
           background-size itself, not the shorthand.
   sylvaing: We (microsoft) haven't implemented it yet.
   <dbaron> just did background-size as -moz-background-size
   Bert: 1) change slash to something else, like a keyword
         2) require a position when you specify a size
         3) leave it as is.
   Bert: I hear some support for #2.  Would the size have to be in a
         particular place, or just *somewhere* before the slash?
   fantasai: Anywhere before the position, by current spec.
   Bert: Preferences?
   dbaron: My position is that, if you have a slash, there is a size
           right before it, and a position right after it.
   szilles: Is there an example elsewhere of a slash without something
            before it?
   dbaron: It only appears in the font shorthand, and there you need
           two things.
   <anne42> <ratio> from css3-mediaqueries requires both sides too
   Bert: A slash doesn't have to be a 'separator', it could just be
         punctuation.
   sylvaing: Are we just trying to support a pattern that no one will
             want to use?
   anne: Best to require a style that is consistent, so authors can
         read it more easily.
   sylvaing: Agreed. Dangling separators all over the place is no good.
   Bert: So I'm hearing some consensus on #2.
   Tab: I'm ok with requiring both, although I prefer using 'as'
   szilles: I echo Tab.
   szilles: Basically keeping / requiring a pair makes things easier
            to do things.
   szilles: But since in many cases you *dont'* need a position, it
            might be better to have size as an independent thing.
   fantasai: Slight preference for the keyword as well.
   Bert: So, how to proceed?  Should we have someone draw up the grammar?
   * TabAtkins missed what sylvain just said, because of th ephone beeping
   fantasai: The keyword sort of directs you more towards that the
             number is doing something to the image.
   <fantasai> background: url(foo.png) as 100%
   sylvaing: As long as a / has things on both sides I'm fine, so I'm
             fine with either 1 or 2.
   Bert: So, consensus seems to be around the keyword, unless people
         have preference for a slash?
   Bert: Okay, then someone should write up the proposal for the new
         text/grammar.
   fantasai: I can do that.
   <fantasai> ACTION: write new text/grammar for using keyword
   Bert: Do we need to come back to this?  Or is the change simple enough
         that we can just accept it?
   dbaron: I think it would be useful to see what the proposal actually is.
   fantasai: Also we should check in with webkit and opera (re:
             implementing the / in the shorthand already).

CSSOM Values API and Serialization
----------------------------------

   <anne42> Bert, if I have to leave beforehand, I'd basically like people
            to look at the email and give some feedback, some kind of
            approval or disapproval at the minimum would be cool
   Bert: Next, CSSOM issues, per anne's request.
   Bert: Property value api.
   anne: Currently all apis in cssom are string-based, so every time you
         query for a property you get a string back which represents the
         value.
   anne: the idea is that instead of a string you get a more specialized
         object back.
   http://lists.w3.org/Archives/Public/www-style/2009Nov/0335.html
   anne: We discussed the idea briefly at tpac.
   anne: It would look like a string, but also have typed properties for
         the values the property supports.
   anne: Frex, the background property would have a url property
   anne: Or, frex, length values, if you wanted to animate the length,
         you could just increase the value of the length using style.width.px
         or whatnot, rather than asking for a string, parsing it, changing it,
         sending the string back, and making the browser turn it back to a value.
   anne: Which is a lot more work than should be necessary.
   sylvaing: It makes a lot of sense in principle.
   sylvaing: It's kind of amazing that authors have to reparse css that's
             parsed by the browser.
   TabAtkins: Agreed, the bit of work I've done in pure css manipulation
              has been very annoying due to the string handling.
   sylvaing: Yeah, the javascript libraries often take away that difficulty,
             so we're all just spinning cycles.
   anne: The specific way I'm talking about it, there may be cross-compat
         issues.  It will no longer do strict equality, and typeof will
         return something new.
   anne: So we might need, say, a new accessor on the style object.
         style.superAwesomeTypeObject.width.px
   anne: Best is to get an experimental impl in a browser and see what happens.
   szilles: You said you won't get string equality.
   anne: Like, if you get a string that's "0px", and use === to test, it
         would fail, because the object isn't a string (though it will
         act like one in some cases).  == equality will still work.

   anne: Also, some more tpac issues - the getComputedStyle API, specifically
         the concept of resolved values.
   anne: Also, about how individual components get serialized to a string.
   anne: These are for the string apis.  Currently everyone does something
         different.  We'd like some convergence, and I'd like some feedback
         on exactly what should happen here.
   Bert: Current API, or new?
   anne: Current api.
   anne: Frex, if you used stylesheet value to go over the stylesheet rules,
         you get strings, but evereyone has a different canonical form for
         these string values.
   anne: I'm trying to define how these should be serialized.  But since
         everyone does different...
   sylvaing: Yeah, even if you get convergence, you'll probably be breaking
             compat with older versions of each browser.
   sylvaing: I'd like a separate api on the side that can do something new
             so we don't have to worry as much about painful compat issues.
   anne: This is also something that new css drafts should take into account
         in due course.
   anne: Frex, <image> type, like gradients, how they should be serialized
         to string.
   sylvaing: It would be good to document, if for no other reasons just to
             see how much damage would be required to converge.
   sylvaing: So we can see if possibly the property value api might be
             easier and cheaper for everyone.
   anne: Yes, but I think we *also* want interop on the string level.
   dbaron: I agree we should try to converge on string serialization.
   dbaron: I've been making changes to our serialization where we might be
           returning different precisions, etc.
   dbaron: There were occasional compat problems, but they weren't horrible.
   fantasai: I think some serializations might be harder to change than others.
   fantasai: At very least, for things that are less common to be parsed,
             they can converge.
   fantasai: Having a spec will help new implementations also.
   sylvaing: In the property value api, the main thing is that you *don't
             have to* parse anymore.
   sylvaing: If you no longer have to parse, what's the reason for converging
             the strings except prettiness?
   anne: Authors will still depend on it.

   anne: I also think that once we start property value api, we may not do
         all types at the start, just the most common, eg length, color
         manipulation.  maybe not time and frequency.
   sylvaing: I agree.  It's not hard to change, we just have a lot of
             corporate customers depending on existing behavior.  It's
             why we end up with modes
   dbaron: Back to anne's point, I agree we shouldn't try and make the
           value api cover everything.
   dbaron: times and frequencies i'm not worried about, it's the complex
           data types i'm worried about.
   dbaron: A lot of times when adding new properties, i have *no idea*
           what data structure to use underneath.
   dbaron: Many of our new property values, even ones in css2, still
           don't have a sensical mapping to the value api (style level 2)
   Bert: Have you thought about that, anne?
   <dbaron> for the DOM Level 2 Style value api that we implement only
            for getComputedStyle
<Zakim> +smfr

   anne: My idea was to have a base type, which is effectively a
         DOMString which has a cssText property.
   anne: each property would at least return the base type, serializes
         to a string.  cssText would return whatever we agree the
         serialization rules should be.
   anne: For other properties, we'd have an object that inherits from
         this base type, and also exposed additional properties, eg
         color property object as r,g,b properties, maybe alpha, etc.
   anne: So you'd at least get back the string, and some would expose
         a little more.
   anne: And if we have properties that really need this api, we can
         start defining this at that point.
   anne: And hopefully CSSOM can modularize as well, so each new css
         spec can have a cssom part that explains how to serialize
         the property, and possibly value apis.
   TabAtkins: So is the idea that the DOMString object contains the
              current legacy browser serialization, and cssText
              contains the agreed on proper serialization?
   anne: No, if you call toString on the object it will just return
         the cssText property.
   anne: I don't think we should expose the [something something
         something].  Frex, background-image would right now return
         just the url property, but later on when we change it, it
         would return a urlList property.
   Bert: I think we hear some encouragement for the approach, at
         least, with some caution about possible difficulties. Is
         this what you wanted to hear, anne?
   anne: This is a start.  It would be nice to have the specific
         emails on www-style get input.
   sylvaing: Is there anything in your thoughts about api and design
             that *couldn't* be done with javascript, so we could
             experiment with it?
   anne: I don't think you can extend DOMString.  You may be able to
         change getComputedStyle itself to return a custom object.
         You could probably get pretty far there.
   fantasai: As far as css specs giving serialization rules, could
             you post some examples of how that would look in an
             actual draft? I have no idea what to put in my specs.
   anne: Sure, in section 7.4 it returns serialization as a generic
         concept.  I'm hoping to deal with properties that accept
         multiple components to give instructions.
   anne: ie, if it's comma separated, serialize it in this way, etc.
   anne: It can be very simple.  Frex, something that takes a time
         in seconds it serialized as a number followed by "s".
         Or urls serialzied as "url('" followed by literal string
         followed by "')".
   fantasai: What about properties that take multiples values?
   anne: For those my plan is to define that there should be at
         most 1 space between components, if they're comma separated
         the comma is adjacent to the previous value and followed by
         a space, etc.
   fantasai: So for most properties we'd just have to specify the order?
   anne: Yeah.  And for things with multiple orders, like background
         position, there you'd say it is in a specified order.
   anne: Frex with margin you'd have a rule that when components can
         be omitted you omit as much as possible, so frex
         "margin: 2px 0 0 0" serializes as "2px 0 0".
   Bert: All right, so what you going to do now, anne?
   <anne42> http://dev.w3.org/csswg/cssom/
   anne: I will update the document further.
   anne: I need to finish some more details on serialization and how
         it maps to getComputedStyle.
   anne: Next step is to draft the property value proposal, and draft
         a few samples like the color interface, and get feedback.
<Zakim> -anne

CSS3 Values / Scientific notation
---------------------------------

   Bert: Next topic, css3 values.
   Bert: The agenda says scinot, but the emails talk about other things.
   dbaron: I haven't gotten a chance to write my proposal calc
           (regarding min/max) yet.
   Bert: I just sent an email with an example grammar this morning.
   Bert: We may want to talk about that later, once people have a chance
         to read it.
   Bert: So, back to scinot.
   Bert: Any actions from that last week?
   sylvaing: Only concerns, which I introduced, was that it would become
             a new CSS hack to separate browsers.
   sylvaing: But it turns out that IE already does this, so the hack has
             been out there already.
   Bert: Explain the hack?
   sylvaing: Once a new browser supports scinot, you can use it to
             exclude older browsers from parsing that rule.
   sylvaing: I don't think it's a serious issue, since Selectors already
             allows that, and Selectors-based ones are more powerful anyway.
   sylvaing: So I don't think scinot is much of a hack in practice anyway.
   sylvaing: But given that the hack is *already out there* in IE if you
             want it, I think the issue is moot.
   Bert: I understand for the selectors hack, but what's this about IE
         notation already doing the hack?
   sylvaing: in IE, you can already specify "width:1e2px", and it will
             work in IE but not other browsers.
   sylvaing: So the argumeent that we shouldn't introduce this notation
             because it would introduce this hack is bogus, since it's
             already supported.
   Bert: In fact it seems to make the hack impossible to use, since legacy
         browsers already use it.
   Bert: Is anyone going to write up examples?
   szilles: I think Chris got tasked with some of that; this is based
            just on reading the minutes.
   Bert: So no new information?
   TabAtkins: Apart from the knowledge about the ie hack, no.  We might
              want to ping Chris about it.
   sylvaing: What are the details of exactly how SVG allows it?
   TabAtkins: It was explained on the list; I forget the exact details,
              but some types of values allow it, but not all.
   sylvaing: So like Hakon's talking about allowing it when necessary?
   TabAtkins: Not quite.  it's not property-specific, but rather value
              specific.
   TabAtkins: Also, HTML5 and JS all rely on the ecmascript serialization,
              which uses scinot.  So we could align with HTML as well.

image-fit
---------

   Bert: All right, so leet's move to a simpler topic for now. Image fit?
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2009Sep/0304.html
   fantasai: I want to write up a response to the most recent image-fit email.
             Some things I agreed with, some I didn't.
   <Bert> http://lists.w3.org/Archives/Public/www-style/2010Jan/0476.html
   Bert: Ok, let's just look at the message detailed in the agenda.
   <shepazu> (I think image-fit would be a good topic for discussion in the FXTF)
   bert: 4 issues in the email.
   Bert: When dealing with overflow on replaced elements.
   fantasai: I think last time I discussed this with Hyatt, we suggested
             always clipping.
   Bert: That's different from what's in the email, which suggests overflowing
         and letting overflow apply.  You're suggesting always clip?
   szilles: That seems dangerous if you're losing content.  Best might be
            scrollbars; some kind of warning that you're not seeing all
            the image.
   Bert: I do see examples in practice of people using a wrapper to force
         clipping the image.
   TabAtkins: I've done precisely that.
   fantasai: [something about default behavior]
   fantasai: contain triggers no scrolling, just cover.
   Bert: As soon as you use that, you're assured you will get clipping.
         That's sort of explicit?
   fantasai: And then image-position lets you specify exactly which part
             gets shown.  I don't think it makes sense to combine that
             with scrollbars.
   szilles: As long as it's clear that it's a conscious decision to force
            the clipping.
   Bert: I like this idea, but are there any other ideas?
   Bert: No dissent.  We may need to come back to this topic, since there
         are more issues anyway.
   Bert: I suggest we continue on image-fit next week.

Miscellaneous
-------------

   Bert: anything else to be said?
   dsinger: I sent an email to peter/glazou on hosting the meeting, but i
            haven't heard anything back from them.  who should I send it to?
   bert: Send it to me.

Meeting closed.
Received on Wednesday, 17 February 2010 22:01:00 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:24 GMT