

[CSSWG] Minutes and Resolutions Telecon 2010-11-17

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 17 Nov 2010 14:55:20 -0800
Message-ID: <4CE45D58.1090609@inkedblade.net>

   - RESOLVED: Mark the attr() function in Values & Units as at-risk.
   - RESOLVED: Make it explicit in CSS2.1 that other unicode linebreaking
               characters have undefined linebreaking behavior.
   - RESOLVED: Remove the concept of percentage intrinsic widths and heights
               from CSS2.1.
   - RESOLVED: Update CSS2.1 definition of clip to be physical in nature.
   - RESOLVED: Push 2007 snapshot to CR.
   - RESOLVED: Don't change the border-image shorthand.
   - RESOLVED: Proceed with publishing B&B to CR.
   - RESOLVED: Publish 2010 snapshot as FPWD.
   - Discussed remaining editorial issues with css3-writing-modes draft.



   tab Atkins
   David Baron
   Bert Bos
   Cathy Chan (Nokia)
   John Daggett
   Arron Eicholz
   Elika J. Etemad
   Simon Fraser
   Daniel Glazman
   Koji Ishii
   John Jansen
   Brad Kemper
   Chris Lilley
   Peter Linss
   Alex Mogilevsky
   David Singer
   Steve Zilles

   Someone Zakim identifies as "Tal"

<RRSAgent> logging to http://www.w3.org/2010/11/17-CSS-irc

Scribe: Tab Atkins

CSS3 Values and Units

   plinss: Any late agenda additions?
   arronei: My email about the attr() function.
   arronei: At the meeting I thought we discussed marking it at-risk,
            but I didn't see it in the at-risk list for Values & Units.
            Are there additional updates pending, or did we decide not
            to mark it at risk.
   plinss: Doesn't seem that anyone really remembers...
   arronei: I don't think anyone really implements it, except for a
            partial impl from us (and maybe FF).
   fantasai: There's no harm in marking something at-risk.
   <oyvind> I believe we (Opera) implement it too

Getting 2.1 done

   plinss: How's work on RC4 coming?
   fantasai: I haven't worked on the testsuite since TPAC, so that's
             my plan today and the rest of the week.
   JohnJan: Does this friday still seem like a doable deadline?
   * alexmog likes Daniel's proposal for named gridlines
   fantasai: Not Friday.  I think Monday was the deadline?  Maybe.
   fantasai: I'm sure I can fix all my tests, but I'm not sure how
             many Hixie/Moz/etc. tests I'd need to update.
   JohnJan: So the expectation is for vendors to review your changes
            by Dec 3rd...
   JohnJan: If you could get them done before Thanksgiving, I could
            spend some time over thanksgiving weekend doing reviews.
   plinss: is there anyone else who can help with that?

   plinss: Any CSS2.1 issues?
   fantasai: The white-space property says linebreaks are only caused
             by linefeed chars, but that doesn't include the lineseparator
             character, which isn't collapsed and which has different bidi
   fantasai: So maybe we should change 2.1 to say that any noncollapsed
             characters that, per unicode, should force a linebreak,
             should force a linebreak.
   bradk: Any danger that people might accidentally have them in their source?
   fantasai: Probably not - they're pretty hard to type.
   tabatkins: It feels like any breakage that would occur would be
              extremely minor.
   bradk asks if they would be copy-pasted from e.g. InDesign
   Tab doesn't think so
   tabatkins: Changing this would mean we need new tests?
   fantasai: I'm already using them in a bidi testcase right now, so it's
             already there.
   plinss: So are we willing to make that change?
   tabatkins: I'm probably not in a good position to make the decision,
              but since we already are testing for it incidentally, I'm
              okay with it.
   plinss: Do we have any passes on the relevant tests?
   fantasai: No.
   fantasai: I think it's important to have going forward, because HTML5
             needs the disctinction in linebreaking characters to handle
             some of its bidi bugs.
   plinss: If nobody passes a relevant test yet for it I'm uncomfortable
           actually requiring it, but I'm okay with leaving it undefined.
   tabatkins: Elika, are you okay with changing the text to explicitly
              say that the linebreaking behavior of other unicode
              linebreaking characters is explicitly undefined?
   fantasai: Yes.  It makes it hard to test some bidi things, but oh well.
   RESOLVED: Make it explicit in CSS2.1 that other unicode linebreaking
             characters have undefined linebreaking behavior.

   plinss: With RC3 of our testsuite, we need 800 more passes.  770 or so
           them we just need more results for.
   <plinss> http://test.csswg.org/harness/results?s=CSS21_%HTML_RC3&f=29
   tabatkins: As soon as RC4 publishes I'll do another full IR for Chrome.
   plinss: What bothers me is that we have about 100 tests that nobody
           passes right now.
   plinss: So this worries me.  We need to determine if the tests are wrong,
           or if impls are wrong, or change the spec, or argue that we can
           live with this failure and defend it somehow.
   arronei: I know a fair number of the cases hinge on RC4 updates, and
            browsers pass after the tests are fixed.
   JohnJan: I think we also need to look at ones that only 1 browser has passed.

   smfr: One criteria on impl is that the build must be at least a month
         old.  Does this mean that if we make a change to fix a pass, we
         have to wait a month?
   plinss: One of the IR requirements is that the feature must have been
           stable  for at least a month, to guard against a custom nightly
           to pass a test that doesn't make it into main stream.
   plinss: That doesn't affect whether or not we can use super-recent builds,
           it just means we'll have to wait a month to report the results.
   plinss: It's really just a restriction meant to keep people from gaming
           the system.

   plinss: arron, do you know how many blocking tests have been changed?
   arronei: Not off the top of my head.
   plinss: I'd like to get this list on the wiki so people can start doing
   JohnJan: Seems right to me.
   plinss: So who can commit to making the page?
   arronei: I was going to start working on that data anyway, so I can
            work on that page.
   arronei: I can get at least halfway today - definitely all the tests
            listed, not necessarily all of them with details.
   JohnJan: That would be a great start.
   plinss: Ideally by next week I'd like to have a list of testcases where
           we need to start discussing spec changes.
   <arronei> http://wiki.csswg.org/test/css2.1/results
   plinss: So everyone dig into this and start reporting status for these tests.

   Topic: Percentage intrinsic widths and heights
   plinss: Last week we wanted to remove percentage intrinsic widths and
           heights, but were waiting for feedback from Apple.
   plinss: We got that now, and they're okay with it.  Any other objections
           before we resolve?
   RESOLVED: Remove the concept of percentage intrinsic widths and heights
             from CSS2.1.

   Topic: clip() logical vs physical
   arronei: clip in the spec is defined logically, so in other writing modes
            it will rotate, but all impls instead do physical.
   arronei: I think we just need to change the spec for it.
   arronei: If we changed impls to be logical it would probably break spriting
   dbaron: I think the original intention was to make it logical wrt overflow,
           or something like that.
   dbaron: But there's been a ton of change in this section, so I'm not
           even sure anymore.
+howcome; got it
   smfr: I talked to Hyatt and he thinks it should by physical.
   RESOLVED: Update definition of clip to be physical in nature.
   arronei: And now we'll have to think in CSS3 if we want to define a
            logical version.  ^_^
   plinss: Do we have tests currently testing for this behavior?
   arronei: No.  I created a test for the mail, but we don't actually
            have a test testing for logical/physical.  I can convert
            the test I wrote into one for the testsuite.
   plinss: If it falls out of your work, do it; I was just wondering
           if there were any tests needing to be changed.

border-image double slash grammar

   <Yves> http://lists.w3.org/Archives/Public/www-style/2010Nov/0078.html
   Yves: The issue is the same as the previous one for background shorthand.
   Yves: In background, it was possible previously to have a background
         starting with a /.
   Yves: Now in border-image there is the possibility of having two /s
         in a row with no content between them.
   Yves: Since / is used as a separator, it means that if you have a
         parser you'll get nothing in between, which causes a problem
         in the grammar.
   tabatkins: That's just an empty group, right?
   Yves: It causes a loop in grammar-based parsers.  I suggest a value
         to indicate that there is supposed to be nothing in the group.
   dbaron: I don't understand the problem with the slashes.  Is it a
           technical problem, or is just something you don't like to
           look at?
   Yves: In CSS2.1 it says it's a separator.
   dbaron: What part of CSS says it's a separator?
   Bert: In the non-normative appendix only.  In the normative grammar
         it's just a token.
   dbaron: So I don't believe this is really a grammar issue.
   Bert: Depends on how strongly you believe in Appendix G.
   fantasai: We did mark it non-normative.
   <dbaron> I think Appendix G was also intended to be for CSS 2 and
            not forward-compatible.
   Bert: It might be easy to use a different separator.
   fantasai: The current syntax has already hit CR.
   Yves: I think that what you want is not really a separator, but rather
         something that indicates the next section is not what you would
         have expected, but a group higher up.
   Yves: If it was not a separator, but some other character without that
         meaning in CSS2.1, it would be better.
   * glazou notes that CR is NOT an excuse for a potentially problematic syntax
   Yves: This issue was raised when we talked about background properties;
         it's been around for a while.  It's just that only background was
         fixed at the time, not this one too.
   * fantasai doesn't see this as problematic, though. It doesn't violate
       the core grammar, nobody else has raised an implementability concern.
       It only violates the non-normative appendix grammar that is specific
       to CSS Level 2
   <glazou> Yves does raise an implementability concern right now
   <sylvaing> I'd rather not change background syntax now
   <Yves> it's not problemaic if you create a css3 parser or a css21
          parser, but one that needs to read both... it's different :)
   Bert: I agree it looks kind of ugly to have two slashes, but I don't
         think it's a fundamental problem.
   <dbaron> I think the "implementability concern" would also mean we'd
            need to remove most of css3-selectors.
   <Yves> not background, border-image
   Yves: It's an issue if you want to parse both 2.1 and 3.
   fantasai: Why can't you change the parser to parse the / per CSS3?
             What in 2 wouldn't you be able to parse by making that change?
   Yves: Basically it would mean changing most of it.
   Bert: Only one place uses that right now, the font shorthand?
   sylvaing: Why do we need one parser that can read both, as opposed to
             two parsers?
   <jdaggett> howcome: maybe we should have double-slash comments?
   Yves: That's the code I have right now, and there's no version indicator
         in CSS to switch off of.
   <ChrisL> sylvaing - because there is no verson ihfo in css files, and
            they can contain a mix of syntaxes from different levels
   bradk: You can't just parse "//" as "/initial/"?
   <sylvaing> ChrisL, so what ? you can run it through 21 and do 3 if
              that fails.
   * fantasai doesn't understand why Yves cannot change '/' to parse as
       a normal token instead of something special
   tabatkins: So what's the problem again?  This is a CSS3 property, not
              a 2.1 property.  Why does it matter?
   Yves: The way the parser/grammar works, it doesn't know this is a CSS3
         property yet and so just registers a general parse error.
   dbaron: I think the problem is the parser using Appendix G.
   Yves: If the / isn't used in CSS2.1 I can deal with this.
   * glazou this is another proof we don't have levels but versions...
   fantasai: it's used only in the font shorthand.
   Yves: I can see about that, but I'd like it removed from the Appendix too.
   <ChrisL> @version 2.1;
   <Bert> :-)
   <Yves> if / was used as a separator in CSS3, then it won't be a different
          version ;)
   <glazou> plinss:  move to next topic ?
   Bert: We talked about removing the appendix entirely, because it
         confuses people.
   plinss: So any quick wrapup on this?
   * fantasai suggests treating '/' as a unary operator
   <fantasai> or something similar
   <Bert> (Anybody has engineers with free time to help update the
   tabatkins: The fix is just to change Appendix G, right?  That doesn't
              affect anything else in CSS.
   <glazou> ChrisL: this level/version thing plagues us
   <ChrisL> glazou, i agree it does
   dbaron: The point of Appendix G is *just* for CSS2.1.
   <glazou> plinss: let's move on for jdaggett 's sake :)
   <ChrisL> and it would be lovely to tie the validator to css-beijing
            or snapshot or whatever
   tabatkins: [stuff about it only mattering for validating CSS2.1]
   * ChrisL tired of removing orange or ::before from stylesheets to
            pass pubrules
   fantasai: I suggest *not* using the Appendix G grammar, and just
             changing the grammar the impl is using to match what you need.
   * bradk likes the slash, and thinks it is used elegantly in border-image
   Yves: i can look at that, but I'd want appendix G grammar to be updated
         for forwards-compatibility.
   <glazou> TIME !!!
   fantasai: What we're trying to tell you is the appendix G is *not*
             meant to be a forwards-compatible grammar, it's *only*
             for CSS2.1.  The more restrictive and specialized for 2.1
             it is, the better it is at its goal.  That is not your goal,
             that's okay.
   <Yves> usure, thanks for your time!
   plinss: let's take the rest of this discussion to email.

Transition requests

   <fantasai> http://lists.w3.org/Archives/Member/w3c-css-wg/2010OctDec/0180.html
   plinss: Elika entered 4 requests.  First was 2007 snapshot transition to CR.
   RESOLVED: Push 2007 snapshot to CR.

   plinss: B&B
   plinss: Yves issue is the only one that was raised, apparently?
   fantasai: There were others raised.
   <ChrisL> Can't rejoin. I support the publication requests
   plinss: The others were all addressed?
   fantasai: Yeah.
   plinss: So for the // issue am I hearing that we aren't accepting it
           as an issue?
   fantasai: It's past the deadline, but I can add it to the list.
   RESOLVED: Don't change the border-image shorthand.
   RESOLVED: Proceed with publishing B&B to CR.
   * sylvaing yay CR !
   <szilles> +1 to publish B&B

   <dbaron> Is there a draft of the 2010 snapshot somewhere?
   <fantasai> http://dev.w3.org/csswg/css-2010/
   <fantasai> sorry, forgot to send it to the list
   plinss: Now, 2010 snapshot as FPWD.  Everyone okay with that?
   RESOLVED: Publish 2010 snapshot as FPWD.

   plinss: Now, Writing Modes.
   howcome: In Opera I'm seeing an end-of-comment marker before the
            end of section 7.
   howcome: So I'm not certain if something is supposed to be commented
            and is not, or what?
   <dbaron> I see end-of-comment markers both right before section 7 and in the middle of 6.1
   <jdaggett> http://lists.w3.org/Archives/Public/www-style/2010Nov/0151.html
   howcome: 6.2.5 (?) is different lengths in Opera and Firefox
   jdaggett: <describes above email>
   jdaggett: section 4.1 (especially second bullet point), section 6.1
   jdaggett: it would be good to say:  In CSS 2.1 we have sections 10.3
              (widths) and 10.6 (heights), and those algorithms are inverted.
   jdaggett: I see a lot of things that are weird editorially.  I see
             references to old writing-mode values (section 2 ex. 1,
             several in 6.1.1)
   jdaggett: Also, I think list of references is needed.
   jdaggett: Also, this and grid alignment spec behave very strangely with
             wide screen; illustrations fall behind examples.  Was default
             style sheet changed?
   fantasai: I just made it float.
   jdaggett: Seems to be causing a problem.
   jdaggett: I'd like to see more text that points people in the right
             direction of what calculations you're talking about.
   fantasai: I can list those as examples but I can't be exhaustive.
   jdaggett: I'm not looking for exhaustive list in FPWD.
   jdaggett: But I think a lot of people have been confused about whether
             we're doing logical properties are not, and I think the
             current text is confusing about answering that confusion.
   jdaggett: I think referring to CSS 2.1 spec and saying which algorithms
             are switched, etc., would help.
   fantasai: Would adding ... ?
   <fantasai> "For example, the rules in 10.x are used to calculate the
              height instead of the width, and the rule sin 10.y are used
              to calculate the width instead of the height"
   jdaggett: There are places where things don't say how it relates to 2.1;
             I don't think it needs to be more than one sentence.  But I
             think there are cases where the used value and computed value
             can be confused.
   fantasai: (reads)
   fantasai: I can give examples; can't say these are the only calculations
             needed to consider.
   jdaggett: I think the spec isn't really capturing the background material.
             It would help if the first section (introduction or section 2)
             gave more real documentation on what it is we're trying to solve.
   jdaggett: Are we trying to solve vertical text, or also solve cases of
             mixtures of scripts in various writing modes (which makes problem
             more complicated).
   fantasai: There's a reference from UTN22.
   fantasai: I could copy examples from UTN22 into the spec if necessary.
   jdaggett: That would be great... to copy enough examples to show the complexity.

fantasai and Bert work out what the preprocessor is munging and fix the
markup problems
Received on Wednesday, 17 November 2010 22:55:57 GMT
