- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 27 Jan 2011 13:50:06 -0800
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- RESOLVED: Accept proposal to defer 'display: run-in' from CSS2.1 to CSS3.
http://lists.w3.org/Archives/Public/www-style/2011Jan/0542.html
- RESOLVED: Drop 'vertical-align' from the required list of properties that
apply to ::first-line.
- RESOLVED: Make interaction of bidi and white-space trimming undefined for
CSS2.1 due to lack of implementations. (Leave current behavior
as a suggestion.)
- RESOLVED: Make containing block formed by positioned inline split across
multiple lines undefined.
- RESOLVED: Have spec allow two possible margin collapsing behaviors in the
margin-collapse-clear case: the hypothetical position before
clearance is applied may be calculated either with respect to
the parent block, or with respect to the containing block
formatting context.
- RESOLVED: publish css3-images WD after Brad approves issue edits
- RESOLVED: Publish css3-writing-modes as WD
====== Full minutes below ======
Present:
César Acebal
Tab Atkins
David Baron
Bert Bos
Tantek Çelik
Arron Eicholz
Elika Etemad
Daniel Glazman
Koji Ishii
John Jansen
Brad Kemper
Hĺkon Wium Lie
Peter Linss
Steve Zilles
Many hours earlier in a timezone far away ...
<karl> http://www.w3.org/TR/html5/rendering.html#css-extensions
<karl> it doesn't seem to have been proposed yet to the CSS WG.
<karl>
http://www.w3.org/Search/Mail/Public/search?keywords=%27%3A%3Acue%27+pseudo-element&hdr-1-name=subject&hdr-1-query=&index-grp=Public_FULL&index-type=g&type-index=
<karl> Maybe in the plans?
<karl> >A CSS user agent that implements the text tracks model must implement
the '::cue' and '::cue(selector)' pseudo-elements, and the ':past' and
':future' pseudo-classes.
Later that morning/afternoon/evening/night ...
ScribeNick: fantasai
CSS2.1 Test Suite
-----------------
plinss: Yesterday a bunch of us went through tests. We have passes
or plans for each one
plinss: some issues resulting
plinss: first item, we have a number of run-in tests that fail, no
plans for implementations for those tests
plinss: plan is to move run-in and its tests to a css3 module
plinss: any objections from the phone? we have consensus here
<Bert> Disappointing that such a basic tupography still doesn't work. :-(
But in the interest of finally getting rid of CSS 2.1...
http://lists.w3.org/Archives/Public/www-style/2011Jan/0542.html
plinss: do not plan to remove it, do not plan to prefix it, just move
definition and tests to css3
howcome: I wouldn't take it out.
plinss: Give us a proposal that gets us out of CR within a month
RESOLVED: Accept http://lists.w3.org/Archives/Public/www-style/2011Jan/0542.html
fantasai: Drop vertical-align from required properties for ::first-line
dbaron: Gecko is the only browser that implements it. Spec doesn't
particularly describe how it's supposed to work other than
"it's mostly like an inline element"
dbaron: Spec lists MUST properties and has MAY for all other properties
dbaron: so our impl would end up in the MAY category
http://lists.w3.org/Archives/Public/www-style/2011Jan/0541.html
RESOLVED: Drop 'vertical-align' from list of ::first-line required properties.
plinss: Bidi, were going to leave the interaction of spacing undefined
fantasai: What's failing is that impls trim leading and trailing white
space on a line before bidi reordering instead of after, so
we have test bidi-004 failing in everything
fantasai: But that's clearly the right behavior, so we shouldn't change
the spec, just leave the definition for CSS3
fantasai: And make undefined for CSS2.1
<fantasai> "Then, the block container's inlines are laid out. Inlines are
laid out, taking bidi reordering into account, and wrapping as
specified by the 'white-space' property. When wrapping, line
breaking opportunities are determined based on the text prior
to the white space collapsing steps above. "
<fantasai> That's followed by the trimming steps in question.
<fantasai> So we would remove the mention of bidi reordering and add that
a sentence saying that the interaction with bidi is undefined
with the steps below.
<fantasai> (but not above, 'cuz we have interop on that)
<dbaron> could also say ... but implementations may follow them, or
something like that
RESOLVED: do that
fantasai: other issue was the containing block formed by an relpos'ed
inline element
fantasai: that breaks across multiple lines
fantasai: proposed to make resulting containing block undefined
fantasai: so would remain defined if inline is all on one line
fantasai: just not if it's split across multiple lines
http://test.csswg.org/suites/css2.1/20110111/html4/containing-block-032.htm
RESOLVED: make containing block formed by inline split across multiple
lines undefined
plinss: We had a test that passes in one impl, but if you split the test
then we have two impls per piece
dbaron: Splitting the test doesn't help with our exit criteria because
it's per-feature, not per test
dbaron: But we could make a convincing argument about implementability
dbaron: because there are two impls of each part of the feature
dbaron: and one impl that is capable of implementing both
dbaron: Suggestion is to keep the test, but also make split versions
plinss: Question for Daniel, Bert - do you think we can defend that?
Daniel: Seems bad to have a red line in the impl report
dbaron: Our exit criteria are per feature anyway, not per test
Arron: Doesn't seem like we would get a fixed impl soon enough
Bert: I think you can argue about test suites. MathWG has done the same,
for example.
Bert: You can do that. But it is work: you have to prepare those explanations.
Bert: So I think it depends how much you want the original tests to stay
in the test suite.
plinss: I could go either way.
plinss: I think we're more honest to not remove the original.
SteveZ: can you flag the test yellow?
plinss: Yes, we're adding some concepts to the test suite about
parent-child tests
plinss: Daniel, you on board?
Daniel: Yes, that's fine.
dbaron: I don't want to remove the parent because I can imagine a case
where impl passes both children, but fails the parent
plinss: OK. We have a plan.
plinss: Other issue is margin-collapse, if we want to discuss that now.
dbaron: I wrote an email to hixie, which I should probably repurpose to
an email to www-style
dbaron: Briefly, hyatt proposed changing the margin collapsing rules in 2007
dbaron: To prevent a counter-intuitive behavior, of elements moving up
and margins disappearing.
dbaron: We resolved to fix that.
dbaron: However, if you read the spec very carefully, the fix didn't
actually work
dbaron: The tests are for what the spec was intended to say
dbaron: But implementations have not changed
dbaron: And IE claims there are web-compat issues
Arron: Also Acid2 is affected.
dbaron: Although I think if we tell hixie to fix Acid2, he'll fix Acid2
Arron: We have two implementations of the intended behavior, from Antenna
House and WebToPDF.
Arron: So we have the passes we need
Arron: If we don't change the spec, but change the tests, then we have
passes from all the browsers.
fantasai: We also noted that there are existing patches for Gecko and
Trident that would implement the intended behavior, if that
was chosen.
plinss: So we're not blocked on this issue
dbaron: It's easier to leave as-is, but I'm not sure that's good for authors.
fantasai: Could also leave it undefined for now -- allow both behaviors --
and lock it down after testing in a beta cycle
Arron and John Jansen are in favor of leaving the behavior.
fantasai is not happy with margins, however large, mysteriously disappearing.
fantasai: I think we should just list the two behaviors and allow one or
the other. Decide later once we have better chance to check web
compat
<dbaron> I think I prefer fantasai's suggestion.
fantasai: Can have two controls within the same test to test for that.
RESOLVED: Have spec allow either margin collapsing behavior in this
margin-collapse-clear test
plinss: going to split some bidi tests up, and fix a few erros, but other
than that we're mostly done here
CSS3 Image Values
-----------------
Tab: I have some pending notes to put in about gradient issues, I will
put in as issues in the working draft.
Tab: Leif raised a few small issues
Tab: Leif wants object-fit: none;
dbaron: I really don't want that
Tab: I would like to go to WD
Brad: I have some notes I want captured.
RESOLVED: publish css3-images WD after Brad approves issue edits
CSS3 Writing Modes
------------------
fantasai: No major substantive changes. Mainly lots of editorial edits,
and lots of tweaking of details e.g. in box model section.
http://dev.w3.org/csswg/css3-writing-modes/
fantasai: Just want to publish an updated WD for comments
RESOLVED: Publish css3-writing-modes as WD
CSS3 Text
---------
http://dev.w3.org/csswg/css3-text/
fantasai: A lot of changes to this draft, some major, others minor
fantasai: I updated the changes section last night
http://dev.w3.org/csswg/css3-text/#recent-changes
fantasai: CVS logs available (with comments) for anyone who wants more
detail http://dev.w3.org/cvsweb/csswg/css3-text/Overview.src.html
howcome: I sent in comments on this one, I don't think we should change
the names of the hyphenation properties, particularly the main
switch
howcome: We reached consensus on the name in 2007
... ok with changing lesser-used properties, mainly concerned about hyphens ...
<Bert> (I have the feeling there are too many line/word breaking properties,
with too many interdependencies, but I haven't had time yet to work
through all combinations...)
<fantasai> (It's a mess, and I agree, but there isn't much I can do about it.)
howcome: I don't think the new names are better or worse, think we should
hear back from implementers
fantasai: Murakami-san liked the new hyphenation-limit names. Haven't
heard back from Michael Day.
plinss: Where are we?
fantasai: I think I need to add hyphens property back in and nothing else
howcome: And clarify word-break behavior for non-CJK scripts
smfr: we implement some of the hyphenation properties
* scribe didn't catch everything smfr said
smfr: hyphenate-character we support auto or a string
<smfr> webkit supports hyphens, hyphenate-character, hyphenate-locale
(with prefixes)
howcome: I don't see any use cases for the second character
howcome: I didn't find anything
fantasai: I think there are two advantages to publishing with two strings
right now and removing it in the next draft. One it's marked as
an issue, we might get feedback. Other is if an implementor wants
this functionality, they have some idea of how to do it.
SteveZ: I have a colleague who believes that text-trim and/or hanging-punct
doesn't match the Japanese requirements
Koji: I talked with Nat about this, and I think I explained that the way
we do it is different from what InDesign does, but we have some
current level of consensus.
Koji: CSS3 Text is only subset of what InDesign does
SteveZ: My concern is not the subsetting, but that the way it was done
does not match Japanese requirements.
SteveZ: Feedback was from someone other than Nat, btw.
SteveZ: Don't object to publishing WD, just wanted to note this issue.
Koji: I met with Yamamoto-san and Nat on Monday
SteveZ: My understanding was that values would pick things out of a table.
Koji: My understanding was the request was a little too much for this level.
Koji: I will talk about that with Adobe at our next meeting
plinss: Do we have consensus to publish with suggested changes?
plinss: Or do we need to come back and review?
howcome: I would like to have consensus from implementors first.
CSS3 Speech
-----------
plinss: Daniel Weck is preparing to request LCWD for CSS3 Speech, so
please review
Meeting closed.
Received on Thursday, 27 January 2011 21:50:42 UTC