- 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