- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Mon, 09 Mar 2009 01:37:34 -0700
- To: www-style@w3.org
Summary:
- Reviewed CSS2.1 Issue 86, dbaron wants to write more tests.
http://wiki.csswg.org/spec/css2.1#issue-86
- RESOLVED: Accept dbaron's proposal for CSS2.1 Issue 94
http://wiki.csswg.org/spec/css2.1#issue-94
http://lists.w3.org/Archives/Public/www-style/2009Jan/0255.html
- RESOLVED: Accept to copy css3-background wording for CSS2.1 Issue 100
http://wiki.csswg.org/spec/css2.1#issue-100
- Reviewed CSS2.1 Issue 101, dbaron to write more tests and propose text
http://wiki.csswg.org/spec/css2.1#issue-101
- RESOLVED: Replace "valid statement" with "non-ignored statement" for
in section 4.1.5 for CSS 2.1 Issue 102
http://wiki.csswg.org/spec/css2.1#issue-102
- RESOLVED: Accepted to fix error reported in CSS2.1 Issue 103, exact
edits to be determined by Bert Bos.
http://wiki.csswg.org/spec/css2.1#issue-103
- RESOLVED: Accept that widows and orphans can only accept integers >=1
for CSS2.1 Issue 105.
http://wiki.csswg.org/spec/css2.1#issue-105
- RESOLVED: Accept proposal to copy :lang() wording from Selectors for
CSS2.1 Issue 68
http://wiki.csswg.org/spec/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)".
http://wiki.csswg.org/spec/css2.1#issue-85
- 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 ======
Attendees:
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
http://wiki.csswg.org/spec/css2.1#issue-86
for both floats and text-align
<anne>
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%3Cul%20style%3Dtext-align%3Acenter%3E%3Cli%3Ex
http://wiki.csswg.org/spec/css2.1#issue-94
http://lists.w3.org/Archives/Public/www-style/2009Jan/0255.html
<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
none
<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
http://wiki.csswg.org/spec/css2.1#issue-100
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
http://wiki.csswg.org/spec/css2.1#issue-101
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?
silence
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
case
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
that?
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)
http://wiki.csswg.org/spec/css2.1#issue-103
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
http://wiki.csswg.org/spec/css2.1#issue-105
RESOLVED: accept that widows and orphans can only accept integers >=1
http://wiki.csswg.org/spec/css2.1#issue-68
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
http://wiki.csswg.org/spec/css2.1#issue-85
http://lists.w3.org/Archives/Public/www-style/2008Dec/0125.html
<anne> http://lists.w3.org/Archives/Public/www-style/2008Nov/0035.html
raises the actual issue
fantasai explains that the sentence in
http://www.w3.org/TR/CSS21/syndata.html#characters
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
<anne>
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3Cstyle%3Ebody%2C%20%5Btitle%3Dx%5C%0D%0Ax%5D%20%7B%20background%3Alime%20%7D%3C%2Fstyle%3E%3Cbody%20title%3D%22xx%22%3Ex
<fantasai>
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3Cstyle%3Ep%2C%20.tes\%0At%20{%20background%3Alime%20}%3C%2Fstyle%3E%0A%0A%3Cdiv%20class%3D%22test%22%3Etest1%3C%2Fdiv%3E%0A%3Cdiv%3Etest2%3C%2Fdiv%3E
<fantasai>
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3Cstyle%3Ep%2C%20.tes\%0At%20{%20background%3Alime%20}%3C%2Fstyle%3E%0A%0A%3Cdiv%20class%3D%22test%22%3Etest1%3C%2Fdiv%3E%0A%3Cp%3Etest2%3C%2Fp%3E
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
<anne>
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3Cstyle%3Ep%2C%20.te\%0Ast%20{%20background%3Alime%20}%3C%2Fstyle%3E%0A%3Cdiv%20test%3D%22te%26%2310%3Bst%22%3Etest1%3C%2Fdiv%3E%0A%3Cp%3Etest2%3C%2Fp%3E
<anne>
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3Cstyle%3Ep%2C%20[test%3Dte\%0Ast]%20{%20background%3Alime%20}%3C%2Fstyle%3E%0A%3Cdiv%20test%3D%22te%26%2310%3Bst%22%3Etest1%3C%2Fdiv%3E%0A%3Cp%3Etest2%3C%2Fp%3E
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
opaque.
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