- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 15 Jul 2010 03:47:20 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- RESOLVED: Look into allowing justification combined with white-space
values in the future, but go with Proposal A for CSS 2.1
Issue 53.
http://wiki.csswg.org/spec/css2.1#issue-53
- Reviewed CSS2.1 Issue 138, leaning towards making floats only relpos
with their containing block.
http://wiki.csswg.org/spec/css2.1#issue-138
- Proposals for CSS2.1 issues 110, 158, and 166 assigned as required reading.
http://wiki.csswg.org/spec/css2.1#issue-110
http://wiki.csswg.org/spec/css2.1#issue-158
http://wiki.csswg.org/spec/css2.1#issue-166
ACTION Tab: Update 110 with link to proposal. (Meaning, if you're
reading this and it's not done, do it now. :)
- RESOLVED: Accept dbaron's proposal for CSS2.1 Issue 174
http://wiki.csswg.org/spec/css2.1#issue-174
- writing-mode spec sync with SVG deferred to September, when fantasai
has time to work on it
- RESOLVED: Add CSS Styling Attributes spec to 2007 Snapshot
====== Full minutes below ======
Present:
César Acebal
Tab Atkins
David Baron
Beth Dakin
Arron Eicholz
Elika Etemad (via IRC)
Simon Fraser
Sylvain Galineau
Brad Kemper
Peter Linss
<RRSAgent> logging to http://www.w3.org/2010/07/14-CSS-irc
Administrative
--------------
plinss: No additions to the agenda.
<fantasai> plinss, I would like to add the CSS Snapshot and the
Styling Attributes spec to the agenda
CSS2.1 Issues
-------------
plinss: Issue 53, spent a lot of time on it last week, not sure if
anything got resolved.
<plinss> http://wiki.csswg.org/spec/css2.1#issue-53
<fantasai> I remember why pre-wrap isn't justified in Mozilla
<fantasai> It's because of tabs
tabatkins: Conclusion from browser testing - anything with collapsed
whitespace can be justified, anything with preserved
whitespace can't be.
<fantasai> So I would suggest adopting Proposal A
bradk: How do the tabs come into it, fantasai?
<fantasai> How do you justify tabs?
<fantasai> They're supposed to push text to the next tab stop
<fantasai> but if spaces stretch or shrink
<fantasai> then the text moves around
<fantasai> and the tabs might need to push to the *next* tab stop
* TabAtkins thinks that Word still lets you justify with tabs.
<fantasai> so they have to be recalculated
<fantasai> and the text *has* to be rebroken
<fantasai> without the tabs problem, you never *need* to alter line
breaks due to justification
<fantasai> it's just an option that can sometimes make the results better
<bradk> I thought a tab was just a seres of spaces in HTML
<fantasai> bradk, no, it aligns to a tab stop
<fantasai> bradk, the tab stops are a multiple of 8 spaces apart
<fantasai> bradk, starting from the containing block edge
<bradk> Thanks, I didn't realize that.
<plinss> you can lay out the text with tabs, then justify from the
last tab stop to the end of the line
<fantasai> plinss, that makes sense. I like that definition.
<fantasai> plinss, seems like it would handle most cases
tabatkins: What plinss just suggested appears to be exactly what
word processors do.
* fantasai is happy with plinss's definition
<fantasai> I'll note that SteveZ was concerned about CR exit, so if
we go with this then we should mark justification of
pre-wrap text as at-risk
tabatkins: Going with plinss's definition, we'll still have no
implementations. Is that ok?
smfr: This question is specifically about CSS 2.1. What are we
going to do right now?
<fantasai> smfr, I don't think we have implementations to exit CR
with pre-wrap justification right now, and given the
implications with tabs, it's not as simple as throwing
a few switches
bradk: We could say "Not justified" right now, and then change it
in the future.
<fantasai> bradk, that works as long as we are clear about our future plans
<fantasai> bradk, we'd have to say that this may change in CSS3
plinss: [talks about new mode that collapses spaces but not tabs]
<fantasai> bradk, And probably remark that justification is allowed
if the UA supports it
tabatkins: Fine with just going with current behavior for CSS2.1
and fixing it in the future.
<smfr> phew
RESOLVED: Accept proposal A for issue 53.
<fantasai> If the intention is to allow justification in the future
then we need a resolution to allow for that
<fantasai> If the intention is not to allow justification in the
future, then I'd like a resoluttion for /that/
* fantasai wants to know whether to reraise this in CSS3 or just
copy from CSS2.1
RESOLVED: Look into allowing justification combined with white-space
values in the future, but go with Proposal A for CSS 2.1.
<fantasai> Thankyou
<bradk> does centering text with tabs in it also change the white space?
<fantasai> bradk, good question, I don't know what happens
<fantasai> bradk, it's a similar problem
<TabAtkins> It does something odd here in OOo Writer.
<TabAtkins> Not sure what the behavior is exactly.
<bradk> If so, then we should treat centering and justifying the same way...
<fantasai> bradk, well, we don't have implementations to do it in 2.1,
but since we're leaving it open for CSS3 we can do that in CSS3
<bradk> fantasai, OK, I can live with that
<plinss> http://wiki.csswg.org/spec/css2.1#issue-101
plinss: dbaron, you have any idea when you'll be able to look at 101?
dbaron: Not sure.
<plinss> http://wiki.csswg.org/spec/css2.1#issue-110
tabatkins: I pointed last week to the proposal that I was happy with
making. I need to edit the wiki and resend to the list
so people actually know what it is.
<plinss> http://wiki.csswg.org/spec/css2.1#issue-138
tabatkins: For dbaron's response on the list, I think the "float in
inline" was precisely what we were testing.
dbaron: The actual discussion on the list was about different things;
only some of them were about floats, and I think all of them
involved a float in a block in an inline.
dbaron: For the testcase I posted yesterday, it appears that floats
directly inside inlines are agreed by browsers to not relpos
along with the inline.
dbaron: If we want to say that relposing moves a float inside the
content tree but not in the containing block, we should say
that in general, not just in the case you have a
block-in-inline split.
<dbaron> ... but I don't think we should.
<dbaron> http://dbaron.org/css/test/2010/css21-issue-138-simple-float-test
dbaron: What I see in Gecko and Chrome is that the first line isn't
offset, but the second one is.
tabatkins: So in the block-in-inline case, the block is the containing
block for float?
dbaron: Yes.
<dbaron> I'm also not sure if there's anything in the spec that says
exactly what relative positioning affects...
tabatkins: That makes sense. I'd be fine with revising my proposal
to say that floats move with their containing block.
Then somehow making it clear that, in the block-in-inline
case, the block is what moves with the inline's relpos,
even though officially the inline is broken around the block.
sylvaing: In IE8 and IE9, both of them move 200px away from the edge.
tabatkins: If IE is moving the float, I'm a bit scared to change it,
just because I know that we authors count on floats doing
really odd things.
<dbaron> So I'd note that we should probably have a separate 2.1 issue
on nothing in the spec saying which descendants of an element
are affected by relative positioning.
tabatkins: So, I need to (a) change the proposal to make floats only
care about their containing blocks getting relpos,
(b) ensure that the block-in-inline case appropriately
moves the block if the inline is relposed, and (c) build
some confidence that this won't break IE.
tabatkins: My only solace is that Firefox does something substantially
different, so as long as an author tests in both FF and IE
they won't depend on this behavior.
bradk: Unless it somehow fixes a separate IE bug.
tabatkins: Right.
plinss: IE guys, are you theoretically okay with this change?
sylvaing: It makes sense to me to make floats move with their containing
blocks only, but I'd have to check with Alex to see what he
thinks re: compat.
sylvaing: Alex is in Moscow right now, so we'll probably have to catch
him on email.
ACTION Sylvain: Contact AlexMog to see if changing things for Issue 138
will hurt web compat for IE.
<trackbot> Created ACTION-245
<plinss> http://wiki.csswg.org/spec/css2.1#issue-158
<TabAtkins> Same as last week, the proposal is linked on the wiki and
just needs someone to review it for acceptability.
plinss: Anyone reviewed it?
[silence]
plinss: Everyone, read the proposal for Issue 158, and we'll discuss
it next week.
<plinss> http://wiki.csswg.org/spec/css2.1#issue-166
tabatkins: I have not reviewed this yet, though I like how few changes
there had to be.
tabatkins: Looks good at first blush, I just need about 10 minutes to
read it in depth.
plinss: Good. Everyone take a look at it so we can quickly resolve
on it next week.
<plinss> http://wiki.csswg.org/spec/css2.1#issue-167
tabatkins: Latest action on it is dbaron's feedback, but Zack hasn't
responded to it yet. I think dbaron needs to poke Zack
to respond.
dbaron: Ok.
plinss: We also had a note to get better testcases on this. Are our
testcases okay right now?
arronei: We have a couple. I'll look around and add them to the wiki.
plinss: Would be good to get together an idea of what we're doing and
what we want to do.
<plinss> http://wiki.csswg.org/spec/css2.1#issue-174
<dbaron> http://dbaron.org/css/test/2010/css21-issue-174
dbaron: I think this is a straightforward case of the prose disagreeing
with the grammar, and everyone following the grammar.
dbaron: I checked Gecko and Chrome.
<smfr> i confirm
<fantasai> Opera and Konqueror match FF
arronei: IE and Opera show the testcase
bradk: Safari too.
RESOLVED: Accept dbaron's proposed change to resolve issue 174.
<fantasai> If we're done with CSS2.1 issues, I'd like to propose adding
the CSS Styling Attributes spec to the 2007 Snapshot
<fantasai> Also, I'd like some guidance on what to do with that spec,
since it's in LC, and all issues were addressed, but the
SVGWG never confirmed whether they were happy with my responses.
<fantasai> http://dev.w3.org/csswg/css-style-attr/issues-lc-2009
tabatkins: Did that one just describe reality, or was it the one that
tried to allow scope and MQ and such inside of @style?
<fantasai> Just describes reality
<fantasai> no new features
<TabAtkins> kk, then I'm cool with i.
<fantasai> otherwise I wouldn't suggest backporting it to 2007 :)
plinss: I'm fine with it. Objections?
[no objections]
RESOLVED: Add CSS Styling Attributes spec to the 2007 snapshot
<fantasai> Second question then is, should we move to CR or action
someone to pester the SVGWG again for a response?
<plinss> http://lists.w3.org/Archives/Public/www-style/2010Jun/0644.html
<fantasai> plinss, For the writing-mode question, I suggest waiting
until end of September
<fantasai> plinss, because I won't have time to work on it until then
<fantasai> plinss, but I do intend to sync with SVG
<TabAtkins> fantasai, that's just an issue of whether to accept SVG's
shorthands, right?
<TabAtkins> fantasai, since we don't want to drop our bt-* ones.
<fantasai> it might be, it might mean other things
<fantasai> right, we'd make a superset
<fantasai> but there might be some changes to behavior also required
<shepazu> [the SVG WG intends to match CSS for SVG 2]
plinss: You okay with deferring this, Sylvain?
<shepazu> [please let us know if there are changes to behavior, of
course... but we're open to changes, if they make sense]
sylvaing: yeah.
Meeting closed.
<TabAtkins> shepazu, should we bug SVGWG more about Styling Attribute?
<shepazu> TabAtkins_: what's the issue?
<TabAtkins> SVGWG never confirmed if they were okay with the resolutions
to the CSS Styling Attributes spec LC issues.
<fantasai> http://dev.w3.org/csswg/css-style-attr/issues-lc-2009
<fantasai> issues list is there ^
<shepazu> hmmm. I thought we'd resolved that... I think Chris has the
ball. IF you would be so kind, write us another follow-up
email about the remaining issues, and we will resolve on it
for our next telcon
<shepazu> and send a clear response
Received on Thursday, 15 July 2010 10:48:02 UTC