- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 14 Dec 2011 14:59:03 -0800
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- Discussed Bucharest F2F logistics
- RESOLVED: indicate in CSS3 Text that "full-size-kana may be replaced by a
generic @text-transform mechanism" as an issue
- RESOLVED: move other features proposed in fantasai's mail to L4
http://lists.w3.org/Archives/Public/www-style/2011Nov/0395.html
- 'appearance' property dropped from CSS3 UI
- Grammar error in CSS2.1 to be fixed:
http://www.w3.org/mid/20111206221126.GA13407@pickering.dbaron.org
- RESOLVED: move ideographic advance unit to Level 4 of css3-values
- Tab and fantasai to review all functional notation in CSS to evaluate
extensibility and syntactic consistency and recommend any necessary changes
- Discussed whether to drop 'pointer-events' or how to keep it without
destabilizing CSS3 UI
- Discussed publication of CSS3 Exclusions and Shapes FPWD and the fact
that certain high-level design concerns were not noted in the draft.
- RESOLVED: update css3-exclusions spec prose to reflect positioning
dependency issue reported by dbaron
====== Full minutes below ======
Present:
Glenn Adams
Rossen Atanassov
David Baron
Kimberly Blessing
Bert Bos
Tantek Çelik
John Daggett
fantasai Etemad
Simon Fraser
Sylvain Galineau
Daniel Glazman
Vincent Hardy
Koji Ishii
John Jansen
Brad Kemper
Håkon Wium Lie
Chris Lilley
Divya Manian
Eric Mueller
Edward O'Connor
Anton Prowse
Florian Rivoal
Alan Stearns
Daniel Weck
<RRSAgent> logging to http://www.w3.org/2011/12/14-css-irc
Scribe: sylvaing
F2F Scheduling
--------------
vhardy: so we need to choose whether we want to book early or make other
arrangements. an email poll will follow
vhardy: i.e. do we go ahead with bucharest at those dates or do we change
the dates and/or the locale
vhardy: the wiki page has information. we recommend sticking to the plan
and booking as soon as possible
glazou: please send the WBS questionnaire asap
appearance property
-------------------
https://lists.w3.org/Archives/Member/w3c-css-wg/2011OctDec/0312.html
jdaggett: tantek removed it from the spec so I don't think there is any
discussion needed
<jdaggett> http://lists.w3.org/Archives/Public/www-style/2011Nov/0395.html
'appearance' dropped from CSS3 UI
Moving Text features to L4
--------------------------
http://lists.w3.org/Archives/Public/www-style/2011Nov/0395.html
<jdaggett> http://lists.w3.org/Archives/Public/www-style/2011Dec/0022.html
jdaggett: the text-transform property is L3 but the @text-transform rule
is moved to L4
<jdaggett> http://wiki.csswg.org/ideas:at-text-transform
jdaggett: I think Florian's approach is a better way to go as it generalizes
the feature
florian: regarding that proposal, this is not something that meant to be
ready soon
florian: but it is intended to demonstrate we can generalize the feature
jdaggett: I think there are two issues; one mail was about splitting features
between L3 and L4. But I'd like to agree on a way to resolve the
underlying issues vs. which subset is resolved in which level
fantasai: I don't think @text-transform is as mature as many other features
we want to keep in the spec
fantasai: @text-transform has all the issues raised against text-replace,
for instance
fantasai: so I want to have this in L3. If we want to defer resolving
full-sized-kana I'm fine with that. but I don't want to hold up
Level 3 Text on the @text-transform feature
howcome: I think we'd like to make sure we don't have a fork with EPUB who
has a dependency on this feature
florian: how soon do we expect the spec to move forward?
fantasai: hopefully a couple of months
sylvaing suggests EPUB dependencies should check for actual use and
implementation
howcome: my concern is that if we do not solve this EPUB will define their
own version of it
fantasai: I do not think that's a concern. EPUB will not include
@text-transform in their September spec
fantasai: I'm not arguing against defining a generic mechanism; only that
if the feature is not ready at this point it's holding up the
rest of the spec. i'd rather move it to the next level
jdaggett: I think we should just explicitly mark this issue in the spec
for now
florian: we could also remove it and re-introduce it later if ready
* sylvaing scribe having trouble with sound quality....
jdaggett: why don't we use our wiki page wording for the spec to identify
the issue clearly and move forward
<jdaggett> i think we should simply add in the @text-transform rule
<jdaggett> and mark it with an explicit issue
florian: the concern seems to be about how fast we can achieve consensus
<jdaggett> the full-size-kana value should be explicitly marked as an
alternate
[ ... ]
<fantasai> Florian proposed marking the issue as "full-size-kana may be
replaced by a generic @text-transform mechanism"
<fantasai> I agree with this proposal
<fantasai> I would like to go with that.
RESOLVED indicate in CSS3 Text that "full-size-kana may be replaced by a
generic @text-transform mechanism" as an issue
RESOLVED move other features proposed in fantasai's mail to L4
<fantasai> http://lists.w3.org/Archives/Public/www-style/2011Nov/0448.html
florian: I am not a fan of line-break. i think it's improved but i still
don't like it
jdaggett: should we let fantasai do all the edits and resume the discussion
from a fresh draft
general agreement
<glenn> prefers line-break be defined (not removed)
error in @page grammar
----------------------
http://www.w3.org/mid/20111206221126.GA13407@pickering.dbaron.org
dbaron: I think this is just a mistake in the draft
glazou: I did not understand why the presence of RULESET in the media
production was an error. For page, maybe, but for media?
dbaron: you're right.
glazou: otherwise I agree that RULESET is incorrect here. The grammar
should be fixed
ACTION Bert to fix the grammar per dbaron's post
http://www.w3.org/mid/20111206221126.GA13407@pickering.dbaron.org
<trackbot> Created ACTION-412
CSS3 Values
-----------
http://www.w3.org/Style/CSS/Tracker/products/8
http://lists.w3.org/Archives/Public/www-style/2011Dec/0342.html
fantasai: the first issue was defining ranges for CSS. This is on arronei
for next week
fantasai: the next was about whether we add an ideographic advance unit
<fantasai> http://lists.w3.org/Archives/Public/www-style/2011Oct/0888.html
jdaggett: I think this is very undefined
jdaggett: it's not clear from the proposal what this means from an
implementation standpoint
jdaggett: I think this feature is a candidate to move to L4; and in L4
I'm concerned about the definition
jdaggett: specifically the algorithm to use to calculate this metric
<kojiishi> text-transform: full-size-kana
<kojiishi> http://www.microsoft.com/typography/otspec/baselinetags.htm#ideoembox
* sylvaing scribe not hearing koji so this may appear one-sided...
jdaggett: i don't think this is specified yet
jdaggett: i think this needs to move to L4 unless we get a better definition
soon
RESOLVED: move ideographic advance unit to Level 4 of css3-values
<fantasai> http://www.w3.org/Style/CSS/Tracker/issues/204
fantasai: the next issue is about the attr() syntax
fantasai: we're trying to align the attr() syntax with the model of
radial-gradient()
fantasai: the proposal is to drop the comma between the attribute name
and the type keyword
dbaron: we do have other functions that use commas as well such as counter()
howcome: we do use the comma in multiple places and I don't see a full
proposal on how this will be replaced consistently
glazou: I would also expect attr() to be extended in the future
fantasai: right, so Tab and I thought about ways to extend attr() and
concluded this is the right way to go
fantasai: We could, for example, allow checking multiple attributes. But
because the fallback value could contain commas, we can't do
that by adding more comma-separated arguments. You'd have to
nest attr() instead.
<howcome> a::after { content: "(see page " target-counter(attr(href, url), page, decimal) ")" }
<tpod> Commas or spaces? This is not about clip right? ;)
ACTION fantasai and Tab to look at functional notation extensibility in general
<trackbot> Created ACTION-413
howcome: regarding css3-values, it no longer specified fr but Grid still
uses it
fantasai: we suggest Grid should define fr
fantasai: once it's clear the unit needs sharing across specs then we can
pull it into Values & Units L4
pointer-events and css3-ui
--------------------------
<tantek> note: I've made what I think are the last necessary edits to
publish a second LCWD of CSS3-UI, including postponing
'pointer-events' to CSS4-UI because it has had the most issues
of any feature for this draft, and because it requires documenting
the previously undocumented hit-testing model. Per the desire to
move more mature features more quickly, it didn't make sense to
hold up the rest of CSS3-UI for 'pointer-events', so it got bumped
to CSS4-UI.
<tantek> (cont'd) I'd intended to check in these edits before the telcon,
but didn't quite make it.
<tantek> (cont'd) And I wanted to give a heads up here in the channel
before I sent email to www-style stating that in my opinion CSS3-UI
is ready for another LCWD and I'm asking the WG to resolve on this
matter and publish it as such before year-end.
<tantek> editor's draft is up to date: http://dev.w3.org/csswg/css3-ui/
<dbaron> tantek, I think 'pointer-events' is one of the more important things in the draft
[Tantek can't be heard clearly, so fantasai translates]
fantasai: tantek noticed that pointer-events raises a lot of issues and
proposed moving it to css4-ui
dbaron: I think this is one of the most important issues in css3-ui so
I'd like to look at the issues list first
dbaron: I think we can define some things without defining everything
ACTION dbaron to review css3-ui pointer-events issues list
<trackbot> Created ACTION-414
<tpod> Problem is hit testing not prev defined
Publication of Exclusions and Shapes WD
---------------------------------------
discussion of dbaron's objection to the FPWD publication sans certain notes
howcome: issues reported at the f2f are missing from the draft
rossen: we agreed to add all the issues to the spec. we did that. we also
agreed to use bugzilla to track all of the issues
rossen: as to the format of the actual issues, if you want an inline verbatim
dbaron: I think we explicitly discussed describing the issue in the spec.
this ended up as a link to a bug number. I also cannot find the
issue I'm looking for. specifically building exclusions on top of
the positioning model instead of floats
vhardy: clearly dbaron and howcome have a problem and we should update
bugzilla to account for their issues. I'd like an agreement on how
we track issues though as it helps me as an editor
vhardy: I'd rather not maintain issues in two places (in the spec and in bugzilla)
vhardy: maybe we can tool this
vhardy: but I'd like to have an agreement
vhardy: and that agreement should not be specific to just these two specs
<dbaron> I don't think we need to turn everything into a general problem:
the issue here was that a bunch of people wanted one particular
issue to be noted in the prose of the spec so that readers were
all aware of it.
<sylvaing> dbaron, was that resolved in minutes?
<dbaron> sylvaing, I thought it was
<dbaron> sylvaing, though the minutes weren't as clear as they should have been
<sylvaing> right. i recall the discussion.
sylvaing: In general you can follow the guidelines and track issues
elsewhere, but occasionally there's a major issue that people
want to be noted directly in the spec. This is one of those
occasions.
RESOLVED: update spec prose to reflect positioning dependency issue
reported by dbaron
fantasai: I suggest dbaron take an action item to propose the exact wording
of this issue. I note that the minutes from the F2F do not reflect
this.
ACTION dbaron to propose the prose he wants to see in Exclusions
<trackbot> Created ACTION-415
Received on Wednesday, 14 December 2011 23:02:09 UTC