[CSSWG] Minutes and Resolutions Tokyo F2F Fri: CSS2.1, box-shadow and border-image


   - Reviewed CSS2.1 Issue 86, dbaron wants to write more tests.

   - RESOLVED: Accept dbaron's proposal for CSS2.1 Issue 94

   - RESOLVED: Accept to copy css3-background wording for CSS2.1 Issue 100

   - Reviewed CSS2.1 Issue 101, dbaron to write more tests and propose text

   - RESOLVED: Replace "valid statement" with "non-ignored statement" for
               in section 4.1.5 for CSS 2.1 Issue 102

   - RESOLVED: Accepted to fix error reported in CSS2.1 Issue 103, exact
               edits to be determined by Bert Bos.

   - RESOLVED: Accept that widows and orphans can only accept integers >=1
               for CSS2.1 Issue 105.

   - RESOLVED: Accept proposal to copy :lang() wording from Selectors for
               CSS2.1 Issue 68

   - RESOLVED: For CSS2.1 Issue 85 make backslash followed by newline invalid
               outside of strings by changing "except a hexadecimal digit" to
               "except a hexadecimal digit or a newline (\n, \r, or \f)".

   - Chris to propose text for how box-shadow should work with border-image.
     Text should require using alpha channels of image to mask shadow and
     clipping inside padding box (outer shadows) or outside border box
     (inner shadows).

====== Full minutes below ======

   David Baron
   John Daggett
   Elika Etemad
   Sylvain Galineau
   Chris Lilley
   Anne van Kesteren
   Mike Smith
   Steve Zilles

<RRSAgent> logging to http://www.w3.org/2009/03/06-css-irc
Meeting: Cascading Style Sheets (CSS) Working Group F2F Tokyo
Date: 05 March 2009
Chair: Chris

CSS 2.1 issues

   <fantasai> http://wiki.csswg.org/spec/css2.1#issue-86
   <ChrisL> Proposal
   <ChrisL> Add "The position of the list-item marker in the presence of
            floats is undefined in CSS2.1." Ask web-designers about text-align.
   David: I don't remember why we couldn't come to an agreement about this,
          but not sure whether it's worth reopening.
   David: I think we were converging on behavior, though...
   Elika: I think we should leave undefined for 2.1.
   ACTION: David to test how interoperable we are on
           for both floats and text-align

   <fantasai> I actually prefer option 3 rather than 2
   <fantasai> (which doesn't conflict with that example either)
   dbaron: I think option 2 was the original intent
   dbaron: The problem is we have a shorthand property that accepts values of
           its subproperties in any order, and two of the three subproperties
           take the value none, and only the initial value of one of them is
   <fantasai> actually I meant to say i prefer 1 :)
   dbaron: We have convergence on 2, since I fixed Gecko to match Opera
   dbaron: since Gecko was pretty wacky
   dbaron: Opera matched 2, and Webkit only sort-of matched 1
   <dbaron> http://lists.w3.org/Archives/Public/www-archive/2008Dec/att-0028/list-style.html
   Chris: Thoughts on the proposed text.
   David: I'm for it, of course.
   howcome, Sylvain: ok with me
   Steve: abstain
   RESOLVED: dbaron's proposal accepted for issue 94

   David: I think we broke this recently... in the 2004 CR it mentions
          propagating 'background'
   Elika: are people happy with the css3 text?
   Anne: In theory we should use lower case element names.
   David: I agree with the proposal.
   RESOLVED: accept proposal for issue 100

   dbaron: I recently rewrote some float code in Mozilla
   dbaron: The old code was so incomprehensible that I tried to understand
           it by writing test cases
   dbaron: I made a change to follow the spec, and that broke web pages
   * shepazu reads backlog... yay on resolution to publish css transforms,
       hope animations will be published too
   * fantasai pokes shepazu just 'coz
   dbaron: We have this long list or rules for positioning floats
   dbaron: There are 3 rules for horizontal positioning... 3 5 and 7?
   * shepazu cries like a lil babby
   dbaron: Here's a left float
   dbaron draws a big box with a rectangle on the lefthand side
   and draws arrows pointing left to show that it is a left float
   dbaron draws another smaller box halfway down the empty space on the right
   dbaron: This box is a normal flow descendant of the big box
   dbaron: It has margins big enough that it doesn't touch the float
   dbaron: http://www.w3.org/Style/Group/css2-src/visuren.html#float-position
   * myakura tries to imagine what it looks like
   dbaron: The rules that deal with horizontal positioning are 3, 5, 7
   dbaron: So sometime circa 2003 or so, hixie wrote a testcase for rule 5
   dbaron: In the intervening years browsers fixed their bugs to follow rule 5
   dbaron: but not rules 3 and 7
   dbaron: So now we're in the situation where browsers do 3 with added
           "and its horizontal coordinates intersect the horizontal coordinates
           of its containing block".
   dbaron: don't ask me whether it's border box or content box
   <ChrisL> _DSC2186
   dbaron: http://lists.w3.org/Archives/Public/www-style/2009Jan/0445.html
   * ChrisL tells myakura that the filenames are photos which will appear in
       the minutes
   dbaron: So the question is do we want to change the spec or get the
           implementations to change?
   dbaron says something about really complicated
   it's not about testing combinations of the rules
   it's about the case where the float doesn't ....
   dbaron: I'm not really happy with any of the options
   dbaron: The spec is simpler. But I did get a bug report one day after
           changing this in a nightly build
   sylvain: IE8 matches FF3.1 beta
   dbaron: here's the fun part
   dbaron: the bug is not the rule 3 case and not the rule 7 case
   dbaron: It's actually the replaced elements getting pushed around floats case
   dbaron: because the rule 3 case and the rule 5 and rule 7 cases were
           suppose I put a float inside this big box
   dbaron: But the ? is about putting a wide repalced element inside the big box
   dbaron: e.g. put a box with overflow auto next to the float that
           "doesn't fit"
   dbaron: even if the fact that it doesn't fit doesn't have anythign to do
           with the float
   dbaron: Maybe that's web compat and the others aren't
   dbaron: I don't really know
   * fantasai is so confused
   anne: There are 4 impl matching each other, right?
   dbaron: We need better tests to tell if they're really matching each other
   dbaron: e.g. I wasn't testing border-box vs padding-box vs content-box
   anne: I note that nobody volunteered reviewing those tests either :)
   dbaron: I suppose I could take an action to write more tests and propose
           changes to the spec
   fantasai: I have no opinion
   dbaron: My guess is Bert would have an opinion
   fantasai: Does anyone here have an opinion?
   howcome: You're never going to be able to test all cases
   dbaron: For the past 3 years we'd thought we'd gotten this down
   Chris: ...
   dbaron: what rule 7 is saying, if you're next to a float..
   dbaron: so if you have a left float that's wider than its container
   dbaron: it's a left float that's sticking out of its container
   dbaron: it's next to a float
   dbaron: we should push it down
   dbaron: so in some sense you could see these new rules as an improvement
   dbaron: but we do push it down for the 5 case, since someone wrote a test
   dbaron: of course the real-world testcase was someone using width 100%
           on a float that had a 2px border
   dbaron: when I found this issue it was one of those realizations where I
           thought we were done with issues like this
   dbaron: I guess I have an action for this
   ACTION: dbaron to write testcases for issue 101 (e.g., see if we're
           interoperable on content-box vs. border-box) and come up with
           a proposal

   Sylvain: 1a { too: early; } @import "foo.css";
   Sylvain: We discussed this on the telecon
   Sylvain: On one hand the parser is supposed to ignore it. On the other
            hand we're supposed to throw out the @import
   Sylvain reads from the spec
   Sylvain: There were 2 things in the discussions
   Anne: my issue was that "valid statement" is ambiguous
   Sylvain: In this case we wanted the @import to fail
   Sylvain: But we also wanted new @rules to be allowed before @import
   fantasai: So we wanted to totally ignore invalid @rules
   fantasai: but for other junk to recognize that there's junk there (which
             could be future selectors) and not process the @import after
             the junk
   dbaron: So is it really our goal to prevent authors from doing hacks like
   dbaron: Would that prevent us from introducing new syntax in the future?
   dbaron: I don't think that's the most important issue
   dbaron: I think the important issue is whether us introducing an @import
           in the future will cause the @import to be ignored
   anne: valid statement is ambiguous
   dbaron: I think the intent is "stuff that you can process"
   dbaron: That's how I interpret it
   anne: Opera interpreted is as syntactically valid per the core grammar
   anne: I do know that we ignore the @import if there's bogus things before it
   dbaron and anne and sylvain test Opera
   anne: I propose replacing "valid statement" with "stuff that is not ignored"
   <dbaron> It sounds like anne is actually ok with the Firefox behavior, he
            just thinks the spec is ambiguous and Opera developers interpreted
            it differently.
   dbaron: If we change 'valid' to 'non-ignored' would that work?
   dbaron: It sounds like we want that testcase to be a correct test case
   <sylvaing> in 4.1.5 At Rules
   <sylvaing> instead of
   <sylvaing> CSS 2.1 user agents must ignore any '@import' rule that occurs
              inside a block or after any valid statement other than an
              @charset or an @import rule.
   <sylvaing> use
   <sylvaing> CSS 2.1 user agents must ignore any '@import' rule that occurs
              inside a block or after any non-ignored statement other than
              an @charset or an @import rule.
   anne: In Section 4.1.5 replace 'valid statement' with 'non-ignored statement'
   <sylvaing> Any @import rules must precede all other rules (except the
              @charset rule, if present).
   <sylvaing> (from 6.3)
   <dbaron> that should say "all other non-ignored rules"
   <dbaron> er, probably shouldn't change since it's authoring conformance,
            not implementation conformance
   * fantasai loves csswg meetings
   discussion of the difference between authoring conformance reqs and impl
     conformance reqs
   RESOLVED: anne's proposal accepted for issue 102
   <dbaron> (which is to change 4.1.5 only)

   dbaron: I was writing a test for this section and realized that it was
           incorrect despite having read this section at least 50 times before
   dbaron: 10.3.1 is a really short section
   dbaron reads 10.3.1
   dbaron: This section is incorrect for relatively positioned elements
   dbaron: My proposal is to remove left and right from 10.3.1
   dbaron: Earlier in 10.3 there's a reference to 9.4.3
   dbaron: we should clarify that that applies to relatively positioned elements
   dbaron: and that when the position is static the values are zero
   RESOLVED: Accept to fix error, exact edits determined by Bert

   RESOLVED: accept that widows and orphans can only accept integers >=1

   RESOLVED: accept proposal for issue 68

   Anne: You should update the reference to BCP47
   <anne> http://www.faqs.org/rfcs/bcp/bcp47.html
   Steve argues against referencing the latest version
   everybody else disagrees
   ACTION fantasai: update Selectors with BCP47

   <anne> http://lists.w3.org/Archives/Public/www-style/2008Nov/0035.html
          raises the actual issue
   fantasai explains that the sentence in
            conflicts with the tokenization
   <fantasai> that sentence allows \ followed by newline as an escape
   <fantasai> whereas the tokenization doesn't
   <fantasai> Also, I don't think newlines and spaces should be treated
              differently here
   <fantasai> So my preference is to keep the prose and fix the tokenization
   <dbaron> I think we should just change the prose: change "except a
            hexadecimal digit" to "except a hexadecimal digit or a newline
            (\n, \r, or \f)"
   Three options:
   1. Follow the prose and fix the grammar, so \ followed by newline is
        treated as a literal newline
   2. Make it invalid, triggering a parse error
   3. \ followed by newline is treated as if neither are present
   Firefox drops the sequence
   Safari treats it as invalid
   IE8 treats it as valid but doesn't drop the sequence
   Opera treats it as invalid
   General preference for Firefox behavior
   Needs a change to prose to except newlines and then specify that such
     escapes are dropped
   dbaron lists changes to tokenizer: removing nl production and merging it
     into escape
   dbaron: Ok, I retract my position, I want to go the other way
   dbaron: An escaped newline in the middle of a number is a pain
   dbaron: I want to make it invalid
   RESOLVED: make it invalid, add "except newlines" to sentence about
             Any characters
   <anne> change "except a hexadecimal digit" to "except a hexadecimal digit
          or a newline (\n, \r, or \f)"

Backgrounds and Borders

Scribe: dbaron

   summary of issue:
   dbaron: Brad Kemper vehemently believes that box-shadow should be ignored
           when border-image is on
   ...because he thinks they're useful in combination only as fallback
   fantasai: [draws on whiteboard about issue of what to shadow]
   fantasai explains how box-shadow draws a shadow around the box itself
     without considering the content of the border box regardless of the
     transparency of the latter
   fantasai explains alternative proposal and its inconsistencies
   <ChrisL> so we have three options
   <ChrisL> a) never allow drop shadow and border image together (no what
               authors want)
   <ChrisL> b) use the existing drop-shadow with border-image and have the
               resulting ugliness (not whats wanted either)
   <ChrisL> c) state that, when border-image is specified, drop-shadow works
               by forming an offset mask from the alpha channel (what authors
               probably expect)
   Steve: One other option to get rid of box-shadow.
   Chris: But it does the job it's designed to do for basic rectangular borders.
     Chris: It should be clear I'm proposing the third option.
   Elika: if (c), then (1) do you clip inside the padding box, and
          (2) for inset shadows, do you clip inside the padding box?
   Chris: (1) yes, (2) no
   David: dashed, dotted, double, border-radius?
   Elika: You do follow border-radius (as you do for backgrounds).
   Elika: But you don't mask for dashed/dotted.
   Elika: We're just taking the concept of the CSS border box and making it
   David: I wonder whether box-shadow is actually useful given how many ways
          there are of doing shadows and how many box-shadow covers.
   ACTION Chris to propose text for how box-shadow should work with border-image
   fantasai explains the difference between spread and making the shadow bigger

Meeting closed

<anne> http://www.w3.org/TR/xml/
<anne> (example spec that references BCP47)
* myakura thanks all. really enjoyed yesterday
<myakura> http://eclecticdreams.com/blog/safari-4-quickfire-aria-testing
<myakura> yes, we need fallback color for background :)

Received on Monday, 9 March 2009 08:38:21 UTC