- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 17 Feb 2010 14:00:19 -0800
- 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 UTC