- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 10 Feb 2010 11:27:47 -0800
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- 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
implications.
* Whether overall usability is increased or decreased by introducing scientific
notation in CSS is debatable.
No resolution was reached.
====== Full minutes below ======
Present:
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
Administrative
--------------
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
cafeteria.
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
it"?
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
everywhere.
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
whateveer.
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
differences.
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
it.
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
"number".
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
implementations.
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