- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 02 Dec 2009 12:03:21 -0800
- To: www-style@w3.org
Summary:
- Mozilla and WebKit have both implemented pointer-events applied to HTML (not just SVG).
Only two values are supported: auto and none.
- fantasai sent and Tab will send comments on Doug's Spec Conventions proposal.
http://lists.w3.org/Archives/Public/www-archive/2009Nov/0027.html
There were no other comments.
- RESOLVED: Publish css3-color as CR or PR without proposed 'color-correction' addition.
- Reviewed implementation status for CSS Namespaces based on Chris's report:
http://www.w3.org/Style/CSS/Test/CSS3/Namespace/20090210/reports/implement-report
Only http://www.w3.org/Style/CSS/Test/CSS3/Namespace/20090210/syntax-013.xml does
not have two passes.
- RESOLVED: Add 'start' and 'end' values to 'float' (CSS3 Box Model)
- RESOLVED: Publish Snapshot as CR along with css3-color CR or PR
- RESOLVED: Snapshot will replace /TR/css3-roadmap, and will also be the target
of /TR/CSS3 and /TR/CSS, pending the Director's approval.
====== Full minutes below ======
Present:
Tab Atkins
Bert Bos
Elika Etemad
Simon Fraser
Sylvaing Galineau
Daniel Glazman
Brad Kemper
Peter Linss
David Singer
Steve Zilles
<RRSAgent> logging to http://www.w3.org/2009/12/02-CSS-irc
Scribe: fantasai
Pointer Events
==============
glazou: Mozilla has implemented pointer-events property
glazou: And extended it to HTML
smfr: WebKit does that too
only 2 values are implemented
glazou: The two values are auto and none
glazou: First item is percentage height calculations
<glazou> http://lists.w3.org/Archives/Public/www-style/2009Nov/0286.html
glazou: dbaron is not on the call, so we may want to defer
Feedback on Spec Conventions
============================
<glazou>
glazou: Discussed that last week, feedback from group is welcome
Tab: I went through thread and agree with everything fantasai said
Tab: Also, Schepers is using <em> in some cases for no other reason
except to get italics
Tab: He's using it for italics, not for emphasis
Tab: He should be using <i>
Tab: That's the only comment I have; the rest seems acceptable
glazou: Do you want to send that yourself?
Tab: I can send it myself
glazou: Please also say that the group has no other comments
2007 Snapshot
=============
<glazou> http://lists.w3.org/Archives/Member/w3c-css-wg/2009OctDec/0148.html
fantasai wrote:
I propose the 2007 Snapshot as a topic for this week's telecon
http://www.w3.org/TR/css-beijing/
Originally, I was going to request publication of the snapshot
as CR when Selectors went to CR or PR, but we're talking about
adding new features to css3-color that will not qualify for
the snapshot until css3-color hits PR. (CR will be insufficient
because the snapshot assumes implementation experience even if
the spec itself is not totally stable.)
The question is, what should we do here?
- Delay the snapshot until color-correction is adequately
specced, implemented, and tested?
- Push color-correction into a css4-color spec or a
css3-color-profiles spec and take css3-color to the
nearest of CR or PR?
- Drop css3-color from the snapshot?
- Something else?
It's clear to me from the number of questions that the snapshot
answers that it's important for us to take it to CR and thereby
post it as a replacement for the outdated /TR/css3-roadmap and
as a target for /TR/CSS3. I was expecting that with Selectors
finally out of Last Call, this would be possible by the end of
the year. Since that is no longer the situation, I would like
us to come up with Plan B.
fantasai summarizes the options here
Tab: Were there other features we could include in the module with
color-correction?
fantasai: There were some color profile related features that were
dropped earlier in the cycle for css3-color
Tab: Then I'm mildly in favor of doing that
sylvaing: From the options you presented, I would be more inclined
to leave color-correction for later
sylvaing: and just complete css3-color as-is
sylvaing: I don't think it's that interesting of a feature to hold
up the snapshot
glazou: I agree
brad: You're talking about dropping color-correction, not css3-color?
sylvaing: Right.
brad: Then I agree with that. Seems like the best option to me too
Bert: Sounds good to me too. I'm in the mood for finishing specs,
so let's finish some specs
fantasai: do we have implementation reports for the rest of css3-color?
Bert: We have tests, but test reports..
<ChrisL> sorry to be late - got a storming headache today :(
<Zakim> +ChrisL
<dsinger> are we saying that css color would be silent on correction,
or require none, or...?
fantasai: If we don't have implementations, then I propose we publish
css-color as CR
fantasai: and the snapshot as CR along with it
http://www.w3.org/Style/CSS/Test/CSS3/Color/current/reports/
dsinger: What would the css3-color spec say about color correction
then? Nothing?
glazou: correct
dsinger: If css3-color is specified in srgb, then it's implied you
should color correct
dsinger: but doesn't say anything about how
dsinger: I'm fine with that
<fantasai> Opera passes system colors, but nobody else does
glazou: so we can aim for CR only at this time
RESOLVED: Publish css3-color as CR
<ChrisL> opera10 passes
http://www.w3.org/Style/CSS/Test/CSS3/Color/20080721/xhtml1/t0302-opacity-offscreen-with-alpha-c.xht
<szilles> fantasai, if you are removing color correction do you not
have to do another last call?
<fantasai> szilles, we never published color correction
<szilles> Ok
<post-meeting>
dbaron believes we have implementations for PR
dbaron updates some tests to make pass criteria clearer
dbaron notes that the last call comments have not all been addressed yet
so we should hold off and publish PR when those are cleared
</post-meeting>
Namespaces
==========
<glazou> http://lists.w3.org/Archives/Member/w3c-css-wg/2009OctDec/0149.html
chrisl: I sent an email with a link to an implementation report
<fantasai> http://www.w3.org/Style/CSS/Test/CSS3/Namespace/20090210/reports/implement-report
chris: which has passes for every test except one
chris: I thought the test was wrong, but then bzbarsky pointed out the
part of 2.1 that makes it correct
chris: this was news to Safari, which is why they failed it
chris: I believe the test is actually correct, just a bit underdocumented
chris: It still means we have one test where we only have one pass
chris: I just wanted to know what the situation was, wasn't proposing
any action
Peter: I ran that test in FF3.5 and it didn't pass
chris: Oh. I might've been using 3.6 then. I'll check it
test in question - http://www.w3.org/Style/CSS/Test/CSS3/Namespace/20090210/syntax-013.xml
glazou: That test is fully green in Firefox 3.7
chris: But the CSSWG doesn't accept nightly builds
fantasai: We do, under certain conditions
Peter: It has to be not an experimental implementation, and publicly available
Peter: basically not something someone wrote to pass a test
* oyvind checks opera mini
<sylvaing> cool. is that criteria written down and documented anywhere ?
<fantasai> sylvaing, http://www.w3.org/blog/CSS/2008/04/04/resolutions_17
glazou: Did we need a clarification?
chris: I guess it's clear enough, just requires reading through it carefully
glazou: other topics were messages from dbaron, so deferring for now...
<dsinger> I think we can handle the comments, actually
glazou: Next one is about CSSOM, but anne sent regrets
Float values
============
<glazou> http://lists.w3.org/Archives/Public/www-style/2009Nov/0336.html
glazou: Last item is about float values, some discussion on www-style
glazou: Peter noticed a subthread about the behavior of overflow
regarding floats in ltr vs rtl
peter: I think dbaron was actually bringing that one up
<ChrisL> (Opera10 has a bunch of extra passes for color, i will send in a test report)
<glazou> http://lists.w3.org/Archives/Public/www-style/2009Nov/0343.html
<plinss> http://lists.w3.org/Archives/Public/www-style/2009Dec/0009.html
<TabAtkins> http://css-class.com/test/css/bidi/float-left-right-edge-rtl.htm
<TabAtkins> http://css-class.com/test/css/bidi/float-right-left-edge-rtl.htm
Tab: the original part, ignoring the overflow business, was just
about float direction based on text direction
Tab: Instead of being absolute left or right
glazou: So 'start' and 'end'?
Tab: Yes. I think that's a fine idea
glazou: I think it's useful for bidi
fantasai: I agree.
glazou: I think we should add it
<szilles> i agree also
glazou: Other opinions?
Bert: I have no problem with adding it, not so sure it's useful
glazou: If you want to build web apps using floats in the bidi world,
then you need it
glazou: It's useful, because you have to reverse everything.
Bert: That's the problem, you don't have to reverse everything, only
some things
Tab+Chris: Right, so you use start and end when you need them to reverse,
and left and right when you don't
Brad: This would be useful for drop-caps
Bert: So we're editing the Box Model, my spec
RESOLVED: Add start and end values to float
ACTION Bert edit box model to add start and end to float
CSSAnonRule
===========
glazou: Got an email from several people about dropping anonrules
glazou: because they want to implement an html editor
glazou: same problem I mentioned a long long time ago
Chris: This is what happens when stuff doesn't display
Chris: We could have rules that display in the dom, but have an ignore
property which says the property is currently ignored
glazou: It's not only that, chris
glazou: When the processor sees a style rule it cannot parse, it
drops the rule
glazou: It doesn't appear in the dom at all
fantasai: You also have the case that in some implementations, if
the same property appears more than once in a declaration
block, the earlier ones get dropped at parse time (rather
than stored and ignored during the cascade)
...
chris: Get a property value as a string
Tab: Right now the way you do this you have to parse the style sheet
yourself with JS
glazou: The WG discussed that question a very long time ago and the
answer from the vendors was we don't want to preserve style
rules that we are not using because it impacts the footprint
glazou: I hope the vendors are going to change their view on this
point, otherwise its pointless to discuss it
glazou: I'm seeing more and more requests on this topic
glazou: If we really want to have cross-browser applications ...
it's a point we need to solve
sylvaing: The reason this whole thing came up is the whole marking
things obsolete at DOM2
sylvaing: ... defining it as obsolete, or hold off on that until we
have a resolution
glazou: Given the way CSS parsing works, it is unusued
...
sylvaing: Just want to know, is what we're implementing in the
future going to be like anonrule, or something else is
going to replace it?
glazou: It is not useful as defined.
glazou: It's only for at-rules and style-rules that are dropped
glazou: You can only use it in some cases, not in all
Tab: It's used for at-rules
glazou: yes, it's too limited
glazou: it doesn't help with declarations that are dropped
sylvaing: Ok, so it's good to drop
Snapshot (cont.)
================
fantasai: Do we want a resolution to publish the Snapshot as CR, or
wait until css3-color is CR?
Bert: maybe we can decide to do them together, at the same time?
glazou: That would be cool
RESOLVED: Publish Snapshot as CR along with css3-color CR or PR
Proposed: Use it to replace /TR/css3-roadmap, also have /TR/CSS3
and /TR/CSS point to it
Bert: /TR/CSS3 will require the director's approval, the rest
should be easy
Chris: /TR/CSS currently points to 2.1, you intend to replace that?
fantasai: yes
fantasai: /TR/CSS2 points to 2.1
<szilles> +1 for Snapshot CR and roadmap replacement
RESOLVED: Proposal accepted, pending director's approval
<fantasai> I note that /TR/CSS should probably be a redirect,
not an alias...
ACTION fantasai make Disposition of Comments for Snapshot (even
if it's empty)
Meeting closed.
More on css3-color:
<smfr> fantasai: how do the color tests work?
<smfr> specifically, what makes
http://www.w3.org/Style/CSS/Test/CSS3/Color/20080721/xhtml1/t040501-system-colors-a.xht fail in webkit?
<fantasai> smfr: I have no idea, ask dbaron. Maybe it passes now;
those reports are not the latest latest
<smfr> the test says "there should be no red", and that's true in our result
<dbaron> css3-color is fine for pr if we don't worryr about color-correction
<dbaron> the system colors thing is just hard to test
<ChrisL> dbaron - yes, its hard to test. or rather, its hard to write a
test that its possible to fail
<dbaron> sorry, couldn't dial in
<dbaron> can we un-resolve to publish css3-color as CR?
<smfr> we kinda hate system colors anyway, since they are too closely
tied to Windows
<fantasai> dbaron: I'm pretty sure we can
<fantasai> dbaron: if you say we're ready for PR and we have the
implementation reports for it
<dbaron> except for the sRGB issue, yes, I think we are
<dbaron> it needs a little arguing about system colors
<dbaron> which are pretty broken to begin with, and the reason I judged
the implementation reports as "failing" is because colors
aren't good enough to represent the system appearance
<dbaron> which is why they're deprecated
<dbaron> however, we also don't have a draft to publish
<dbaron> there's a whole bunch of comments that I need to address
before we publish
<dbaron> even without color-correction
<fantasai> ah, ok
<dbaron> (it just cuts the number of comments that need to be addressed
from 26 to 25
<fantasai> when do you think you'll have that done by?
<dbaron> I probably won't have time this week or next.
<fantasai>how about mon/tues the week after?
<dbaron> I can try...
<fantasai> dbaron, that'd be great
<ChrisL> smfr, could you mail a screenie of what webkit does on that test?
<smfr> ChrisL: sure
<smfr> ChrisL: sent
<ChrisL> simon, i don't see anyting there that would indicate a fail
<dbaron> I probably won't have time this week or next.
<dbaron> smfr, what makes it fail is that it doesn't actually "look
like a raised button... in the operating environment"
<ChrisL> david, in that case the test is badly phrased. it would fail
on anything that uses non-rectangular buttons for example
<smfr> dbaron: ok
<dbaron> ChrisL, well, it's the *spec* that's badly phrased, really,
since the features presume that...
<dbaron> I suppose maybe the test should say "look like the closest
thing to a raised button in the operating environment that
can be represented by ..."
<smfr> dbaron: seems like the worse issue is that ActiveCaption and
CaptionText are both black, resulting in unreadable text
<ChrisL> david - yes, that would be better wording
<dbaron> ok, I checked in new wording for the system colors test
...
<fantasai> dbaron: let me know when you want a new copy published on w3.org
<smfr> the other two webkit failures are related to line height,
not rgba colors
<fantasai> maybe you can patch the tests to not rely on that
<dbaron> probably the easiest patch for that is to make them use
the Ahem font
<dbaron> though, actually, I think the thing to do just mark WebKit
as passing those tests, since it's passing the relevant
parts of them
<dbaron> and it just doesn't do 'line-height: 0' correctly
<dbaron> I really don't know any other way in CSS 2.1 + css3-color
to make two boxes of the same element overlap each other
<dbaron> which is what that needs to test
<fantasai> That seems reasonable to me. So WebKit and Firefox will
get us to PR
* fantasai likes ChrisL's Namespaces implementation report, it makes
this kind of comparison really easy :)
More on publications:
<dbaron> Also, was the publication of css3-transitions, css3-2d-transforms,
and css3-3d-transforms permanently cancelled or just delayed?
<fantasai> dbaron, delayed, I believe
<myakura> 2d-transforms and transitions were published yesterday.
<dbaron> myakura, ah, ok, good
<myakura> not sure about 3d-transforms, though.
<fantasai> I don't think we had a resolution to publish 3d-transforms
<dbaron> I still have a bunch more transitions issues, but we can
publish again in a few months...
<fantasai> :)
<smfr> right, we have not
<fantasai> smfr, anyone on your side interested in writing a blog post
to announce the drafts?
<fantasai> smfr, or should I just say that we published new WDs and
leave it at that?
<smfr> i think that's fine
Received on Wednesday, 2 December 2009 20:04:05 UTC