- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 02 Apr 2008 12:19:32 -0700
- To: www-style@w3.org
Meeting: CSS Working Group Meeting, San Diego, CA
Chair: Daniel Glazman, Peter Linss
Present:
David Baron Mozilla
Bert Bos (Staff Contact) W3C Staff
Tantek Çelik Invited Expert
Aaron Eicholz Microsoft
Elika Etemad Invited Expert / HP
Ming Gao (observer) Hewlett-Packard
Daniel Glazman (Chair) Disruptive Innovations
Molly Holzschlag Invited Expert
Chris Lilley W3C Staff
Peter Linss (Chair) Hewlett-Packard
Alex Mogilevsky Microsoft
Jason Cranford Teague AOL
Anne van Kesteren Opera Software
Steve Zilles Adobe
<RRSAgent> logging to http://www.w3.org/2008/03/27-css-irc
<dbaron> RRSAgent, make logs public
ScribeNick: jason_cranfordtea
Minutes
-------
Elika: are we ready to start with public disclosure of the minutes?
Result: Yes
RESOLVED: Minutes will be public starting from now
Next F2F
--------
Alex: proposes sites for next Ftf
Cabridge, UK
Moscow, Russia
Redmond, WA, US
Discussion by group
RESOLVED: Cambridge, UK is first choice
Alex discusses dates
24th of July
or anytime in August
group discussion
<glazou> I prefer august
<glazou> Steve available only 3rd week of august
August 20 -22nd (Wednesday-Friday)
RESOLVED: August 20 -22nd (Wednesday-Friday) Tentative
Plenary Meeting for Fall
------------------------
Plenary is October 20th-25th
Group discussion
Preference for Monday Tuesday
Steve: Can we meet Sunday?
Peter: Are there other groups we want at the planary?
<glazou> SVG and SMIL
<Bert> For Oct ftf: SZ has conflict with AB (Th/Fr), ask for extra day
on Sun? joint with SVG (filters)? joint with UWA (layout)?
Discussion about needed Apple participation to discuss their proposals
Steve will talk to contacts at Apple
ACTION: Steve talk to contacts at Apple wrt participation at F2Fs
Discussion about talking to Internationalization Group
Avoid overlap with Internationalization Group
Peter will but in request for previous Sunday meeting
2009 Conferences
----------------
Bert: talks about meeting next summer as cross between technical plenary
and Web conference
Steve: ALA wants to do a co-event with W3C in Balogna (sp?) Italy for Web
designers
Steve: event target Europe rather than US designers
"An Event Apart"
http://aneventapart.com/
This even would be similar but for Europe
Bert: In principal, are we interested in participating?
Bert: We can have an F2F at the same place the week before/after
Molly: Opposed to being too closly aligned with any specific conference
Steve: wants to take discussion off-line for W3C input.
Jason: Agrees that there should not be any perception that we are aligned
with any other conference
Jason: But does see benefit in showing that we are involved in the wider
Web community
<glazou> Bert and I don't live far away, we can make it for the conf if
necessary
<glazou> now, I don't feel confortable with aligning a CSS WG ftf meeting
with a conf, we don't have to give a marketing stamp to a
privately held conf IMHO
Mobile Profile to CR?
---------------------
Is Mobile Profile ready to go to CR?
Bert: Can we publish?
Elika: No problem
Group discussion about current status
Bert: there is a test suite
Tantek: concern over bugs
Steve: Q for Tantek: are they CSS bugs or just bugs?
Tantek: Simple dumb bugs in test, NOT in CSS
Elika: People running test will complain, so we can catch that way
Tantek: opposite happening
Tantek: if marquee properies are not ready, not ready for CR
Danial: Do we have an agreement on the Mobile CSS profile?
Tantek: I do not see stuff that in the test suite but not in the profile
<Bert> The MWTS WG's harness for the CSS Mobile Profile:
http://www.w3.org/2007/03/mth/harness?test=start&ts=cssmp
Bert: There is nothing in the profile that we do not have agreement
Bert: but marquee is in WD
Elika: Some items in Box Module need more review
Elika: rewriting of vocab, etc.
Elika: split marquee and overflow to move Mobile profile forward
Elika: Box model needs more review
Elika: Suggestion create CSS overflow Level 3
Discussion about specifics of splitting out overflow
Elika: we need results
Q: Can we move Mobile forward to CR?
Tantek: Wants list of at risk to move forward to CR
RESOLVED: Mobile profile can move to CR as long as marquee and overflow
are tagged as at-risk
Steve: They are at risk because their current document status of overflow
and marquee would not allow the CR doc to go to PR
ACTION: Bert Inform Svante to make decided upon edits
Media queries
-------------
TOPIC: Are Media quarries ready to move to CR
Anne: discusses current status and tests
Anne: test need to be updated because of incomplete parsing rules
Davis: This is the second CR?
Anne: first in 2002. This is 3rd CR with further clarifications
Discussion of font size and root element
Decide to use default font
<dbaron> em and ex units in media queries need to be relative to initial
values of font properties (not values on root element, since
style sheets can change those)
ACTION: Anne update media quarries - syntax, grammar, changes to parsing
rules of HTML 4, grid feature
<fantasai> (and 'em' 'ex' definition)
ScribeNick: anne
CSS Website Update
------------------
Jason: Bert, Elika and I discussed updating the site some time ago. More
organized, user friendly for different audiences.
... Make it easy to find what you're looking for.
Peter: PHP can be used and MySQL.
Jason: Structured the page around primary tasks.
... Specifications will be the primary focus.
... CSS 2, errata, CSS 3, current work, and validation.
... Profiles are also linked.
... May want to change the profile links.
... Also have links for contributing, tests, etc.
... A search box, next to the navigation.
... Also a list of languages that the site has been translated into.
... (Initially hidden if we don't get the translations.)
... "What is CSS?" block to give people a quick introduction.
Daniel: Was it not on the lefthand side of the screen?
Elike: it is the first in the source
Jason: it will be given more visual prominence
Jason: for a smaller screen the "What is CSS?" block will be on top
Jason: it will be using media queries
Elika: it will be using some cutting-edge features
Daniel: since only Opera and Safari do media queries, maybe it's not good
enough to base on that
Jason: the non-mediaquery browsers will get the "What is CSS?" block on top
... which seems acceptable.
... Below the "What is CSS?" block we have a "What's new?" and "The world
of CSS"
... News stories, about us, etc. "The world of CSS" contains pointers to
books, articles, etc. outside the W3C/CSS WG
... Might want to break it down further.
Molly: so this is clearly identified as "elsewhere"
Jason: yes
Jason: we don't have a CMS in place. Though now PHP / MySQL seems possible
maybe there are options.
Jason: could use WordPress
Elike: I'd like to move the blog to WordPress
Bert: what's wrong with Emacs?
[laughter]
Ming: Vi!
[more laughter]
Peter: I'd like a real CMS.
Jason: Yeah, that's possible. We can use WordPress for all of that.
Tantek: WordPress does have more IT-requirements unfortunately.
<tantek> as anything with a database backend does
Elika: We can wait a little bit with WordPress.
Elika: Shouldn't block redesign on that, can switch later if we want
Jason: we may want to add an image. Definitely need contact information.
Jason: [goes through secondary pages]
Jason: charter, about, contact, etc.
Jason: "mood": flowing, transparent, layered, professional, informed
(in a spiral)
Steve: maybe add stylish
Jason: new CSS logo idea
Jason: uses "Futura"
Jason: also used on the first moonlanding
Jason: uses transparancy so it can be used on all kinds of colored
backgrounds
[some discussion on logo details; scribe hopes it's not too relevant
for future generations]
[new angle: use the logo or do a contest for designers]
[part of the WG seems slightly bored]
RESOLVED: we're doing a contest for the CSS logo
ACTION: Jason write up requirements for logo contest
RESOLVED: use logo with no missing squares as placeholder
<fantasai> so we don't have to hold up the web site redesign waiting
for the logo
Topic: CSS Website colors
[muted or vibrent]
Steve: I don't like the green
[some votes for muted]
Elika: I'd go halfway between the two.
Topic: CSS Website Fonts
s/colors/Colors/
Jason: no image replacements, as pure CSS as a possibly can
* Bert likes classic sand background and black text with red for emphasis...
* anne ... and emacs :p
<molly> VI dammit
* anne ... jason haha
Daniel: what about fonts on Linux?
Molly: depends on the build
Jason: I'll look into that
... Georgia have a slightly older feel. Might replace Futura with Georgia
... I think it comes down to font size, paragraph width
... We'll be using lots of max- and min-width[s]
Bert: can Gill Sants be mixed with Futura
Jason: yes
Jason: for the paragraph font I can use Gill Sants
Bert: on the website we mostly use sans-serif
Steve: Future and Trebuchet have different lengths
Jason: I think for Future Medium and Trebuchet MS Bold this is ok
Topic: site design
[presents vibrant / muted]
Jason: I'll provide weekly feedback
Peter: check accessibility guidelines
Daniel: one of the key entry points of the W3C is the validator
Daniel: having information from the CSS group on the validator page
would be good
Jason: feel free to e-mail feedback
Box Module
----------
ScribeNick: molly
Bert: I took the text from 2.1. This is very complicated stuff, I'd
like people to look it over and see if it works. Request anyone
who understands height/width calculations to specifically look
at the text
<Bert> http://www.w3.org/Style/Group/css3-src/css3-box/
Bert: So marquee split off / overflow
Fantasai: properties stable
Anne: There are at least four user agents that have implemented
overflow-x overflow-y
Bert: we need to be sure that overflow x/y are going to stay
Anne: Web sites depend on them, they stay
Bert: Okay, we'll put them in and find a way to make it work
Alex: we treat x and y as width and height and we treat x as horizontal
Alex: Top Left Width Height are physical
Fantasai: We could introduce the start and end properties for
margin/border/padding/etc
Bert: Percentage on height property - auto if no defined height?
Fantasai: Must be undefined because of table interactions
David: For min/max height the same undefined way
David: and then when we go define it for height, min/max will pick up
the definitions
Bert: Intrinsic sizing
Bert: there were some open sections - David?
Bert: Section 10
Bert: I think I've made a mistake somewhere, I'll check it out
David: I'll need to look over this
Bert: Are you going to give me more text about float and clear?
David: On my list
Box-sizing
----------
Bert: Box sizing wasn't handled yet
Fantasai: I had a proposal there
<fantasai>
http://idreamincode.co.uk/css/css3/the-css3-box-sizing-concept-a-solution-to-a-longstanding-problem
discusses box-sizing
<fantasai> http://lists.w3.org/Archives/Public/www-style/2008Feb/0141.html
is my proposal
Bert: Box sizing already exists
David: You can have both
ScribeNick: Bert
Jason: Is there a precedent for a "mode" keyword in a value?
Fantasai: Yes, text-indent with hanging.
Steve: It's more similar to shorthands.
Molly: Is the order of the keywords important?
several: no
Fantasai: Point is that this works well with cascading.
Steve: What is the computed value?
Fantasai: it includes the keyword, thus length + keyword
David: This is useful for authors. The alternative is setting box-sizing
globally. Anything else is confusing.
Jason: Can still override it later for a specific element, by using width
again without a keyword.
Tantek: But it does change a fundamental assumption of how properties work.
David: What does?
[people trying to understand each other...]
<dbaron> width: 50% border-box;
<dbaron> width: 50% content-box;
<dbaron> width: 50%; /* uses box-sizing */
Elike gives example:
.class1 {width: border-box: 50%}
.class2 {width: 40%}
class 1 gets border box even if box-sizing property is set differently.
And class2 gets what box-sizing set, without the need to set box-sizing in
class1, which may potentially influence class2 as well.
Jason: What is the alternative?
Steve: Alternative is to be careful with box-sizing; basically set it
everywhere you set width.
David: It's pretty easy to support both box-sizing and Elika's proposal.
Steve: So there is a value without a name that indicates neither border-box
nor content-box, but means "use border-sizing"
Molly: This is difficult to understand for designers.
Anne: What about replaced images with 'width: border-box auto'?
Anne: There was an unwanted interaction between setting box-sizng globally
and replaced images.
<tantek> after discussing with David I understand what he is proposing and
what David Baron is proposing makes sense to me.
Alex: The proposal affects the CSSOM. Currently width is a single value.
Anne: Width is already a string-valued property.
Alex: How about a proeprty 'border-box-width'?
Molly: How does all this work with cascading?
Fantasai: My proposal is designed specifically for help with cascading.
[More people not understanding each other]
[The important thing to remember is David's three lines above]
Steve: I would prefer thata there were an explicit keyword 'box-sizing' as
well.
<tantek> as long as we make it work the same way that border-color and color
work, I think it's fine.
<tantek> there is an explicit keyword currentcolor
Anne: But backwards compatibility with scripts that rely on there being
just a length...
David: But it's slightly different from color/currentcolor, because color
didn't have an explict value at all, while width still has a length
as value.
[Fantasai explains difference between her keyword solution and Alex's extra
property solution]
<dbaron> The situation that "required" currentColor was worse because it
was a situation where border-top: medium solid gave
'border-top-color' (a property) a value that couldn't be specified.
Tantek: Designers usually want to use border-box on both width and height.
Also an extra property is more difficult to use than an extra value.
Alex: Seems a redundant solution either way.
Tantek: there are cases where people normally think about boxer-box (forms...)
and where they normally think about content-box.
Jason: It makes sense in some cases to specify the content width, in others
the border width.
David: Currently designers have to do the math.
Steve: What does getComputerStyle return?
David: Always the content width, I think.
<tantek> my point about the extra property was stating that we don't need
border-box-width and border-box-height vs. just box-sizing
<tantek> about "extra property is more difficult" - adding extra properties
is an unnecessary complexity
David: getComputedStyle has to work on used value.
<dbaron> used content-box value
Steve: Should not break existing scripts.
Jason: Confused about border box width vs border width. I refer to visual
width, usually.
[The terminology is from CSS1]
[Some discussion about need for padding-box and margin-box as well, Tantek
claims no. David can see use cases for margin-box]
David: Can accept the proposal and still ask for better names.
Peter: Should be consistent names between box-sizing and width keywords.
Molly: Nomenclature is very important. Designers don't use the CSS1
terminology.
* alexmog understands motivation but is still very uncomfortable with
'width' not being a length
* Bert notes that width won't be a length much longer, because of calc(),
anyway
Strawpoll: 8 in favour
<glazou> daniel, tantek, david, jason, steve, arron, elika, peter
<anne> +anne
<glazou> 1 abstain, molly
<glazou> 1 against, no answer
<glazou> correction, 1 no anwer is Bert
<glazou> 1 against Alex
Peter: Also applies to min-width?
<Bert> several: yes
RESOLVED: Names must be consistent with box-sizing
<dbaron> applies to min-width, max-width, width, min-height, max-height,
and height
<dbaron> and does not change the behavior of auto, fit-content, min-content,
and max-content, and none
<anne> yeah, so box-sizing:border-box works in Opera
<anne> without prefix
<anne> (padding-box doesn't)
<anne> (nor margin-box)
<glazou> ==== LUNCH ====
Centering
---------
* tantek volunteers to take minutes
ScribeNick: tantek
<tantek> Any other issues on box model?
Bert: Vertical centering
Tantek: agreed.
Elika: possible to extend vertical align to other boxes?
Jason: we have text-align and we have vertical-align
Jason: text-align center I can never figure out when it is going to center
Elika: depends on whether your image is inline or block
Elika: there are 2 centering discussions to have. 1 is horizontal alignment.
Elika: ... that is having a property to do horizontal centering rather than
relying on margin:auto
Elika: ... and 2. there is vertical alignment/centering
Jason: maybe I need box align vertical and box align horizontal
Jaosn: I want a way to say center this box vertically in the page and
horizontally in the page
<Bert> I was wrong. The applies-to of vertical align doesn't say it applies
to blocks. So we *can* generalize vertical-align.
Elika: centering absolutely positioned elements is different than centering
in flow elements. You can't tell a box to vertically center itself
in its containing block without taking it out-of-flow; in normal flow
you can only tell a parent to center its contents.
Alex: GCPM (page) floats and float-offset covers some of these scenarios
GCPM = generated content paged media
Elika: if we extend vertical-align to boxes other than table cells I think
it will be awesome
Steve Zilles: it's not clear that's what you want
Tantek: I think if you try to extend vertical-align to apply to blocks you
will run into TONS of compat problems - existing pages that happen
to set vertical-align on blocks, and having that all of a sudden do
something will break those pages.
Steve: it is unfortunate that vertical-align applies in table cells both to
the alignment of the cell and the alignment of lines in the cell
Alex: there are three problems that are related
Alex: 1)Horizontal center for blocks: ‘block-align:center’
Alex: 2)Vertical align for blocks: ‘block-vertcial-align:middle’
Alex: 3)Centering and overflow: shift or still center?
<Bert> (XSL uses display-align: http://www.w3.org/TR/2006/REC-xsl11-20061205/#display-align)
<fantasai> http://csswg.inkedblade.net/ideas/centering#alignment-property
Elika: if you want to design an alignment property, here are the issues you
need to apply
Steve: so how do we make progress on this?
<fantasai> Markus started a discussion about an alignment property to
standardize on syntax to implement <CENTER>. The property affects
the alignment of boxes, not of text within the boxes, and it
inherits. Unsettled details include:
<fantasai> * Whether the property affects the element's alignment within
its parent or its descendants' alignment within itself.
<fantasai> * What alignment possibilities are represented as values.
Proposed that the left/center/right/start/end set be adopted.
<fantasai> o One set: left | center | right
<fantasai> o Another set: left | center | right | start | end
<fantasai> o A more complex set that includes top and bottom values
that apply in vertical layout. (Such a set should
allow specifying e.g. both top and left at the same
time, where one takes effect in vertical text and the
other in horizontal text.)
<fantasai> o Any of the above sets with percentages as an added
possibility.
<fantasai> * What the property is named. alignment is the working name.
An alternative would be horizontal-align, to be consistent
with vertical-align.
<fantasai> * Whether alignment triggered by this property is "true"
alignment, or if it only affects blocks smaller than their
containing block.
<fantasai> o If the property triggers "true" alignment, then a
value that triggers current behavior must be the
default. The disadvantage of this is that most
authors will not realize use of this property can
cause their content to become inaccessible in some
window configurations.
<fantasai> o If the property does not trigger "true" alignment,
then an additional keyword (or several keywords)
could be defined to trigger true alignment (e.g.
alignment: left vs. alignment: true left). In this
case both alignment behaviors are possible, and the
default behavior emphasizes accessibility.
<fantasai> * How this alignment interacts with the current margin
calculations. Possibilities include:
<fantasai> o alignment trumps auto margins: auto margins are set
to zero and then the box is aligned as specified.
<fantasai> o alignment defers to auto margins: it only affects
blocks without auto side margins. (Note that the
default margin is '0'.)
<fantasai> * How alignment interacts with specified margins
<fantasai> o alignment replaces specified side margins with auto
as appropriate to effect specified alignment
<fantasai> o alignment shifts the margin box, leaving specified
margins intact
Bert: I would like to see a decision on how to do vertical centering alignment.
Tantek: I suggest something visual
Elika: I suggest something that works like vertical-align on table cells but
applies to blocks
<glazou> the new property would align vertically the contents of the cell,
but w/o relationship to other cells
Alex: whatever applies to vertical align should have some symmetry for
horizontal align
Alex: perhaps a shorthand property block-align for handling both
Bert: yes, it is possible but it is a mess, quite complex
Alex: combinations of <center> element, text-align, and margin:auto causes
as much complexity already as if we would have to do a block-align
property
David: the easy solution is that margin:auto wins
Alex: we solve this with an additional set of hidden margins
David: you center the margin box within its containing block
Steve: that gives you the most control so you can adjust the item that is
being centered
<dbaron> margin:auto wins isn't quite adequate, actually, since it's really
like a second set of margins that handles the case when neither
margin is 'auto'
Alex: I like property that has specific effect
Alex: the <center> element is pretty weird in that sense
Tantek: I reraise request for someone drawing something visual
Tantek: while we discuss alignment, centering etc.
(Steve Zilles gets up to the whiteboard)
Anne: <center> element appears to apply to children but not itself.
<center> element doesn't center itself, but centers its children.
Steve: write example on whiteboard:
Elika: Can do that with center > * { block-align: center; }
<div><p>Hi</p></div>
div { height: 200px; width: 200px }
p { block-align:center }
Anne: the HTML <center> element centers its descendants
Daniel: How to center vertically the content of a block if that content
is only text?
<anne>
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0A%20center%20{%20border%3Adotted%201px%3Bwidth%3A200px%20}%0A%20div%20{%20width%3A50%25%3B%20border%3Asolid%20}%0A%3C%2Fstyle%3E%0A%3Ccenter%3E%3E%3Cdiv%3E%3Cdiv%3Ex%3C%2Fdiv%3E%3C%2Fdiv%3E%3C%2Fcenter%3E
Steve: are we talking about horizontal or vertical
Peter: yes.
David: call it (holds up a coin) heads means horizontal
David: the toss is heads - horizontal
* glazou thinks this doubles the duration of this topic
Steve: it is too difficult to discuss both at the same time, thus it
is easier to discuss one at a time.
Steve: if auto margins worked, we wouldn't be discussing this.
David: the one element case is a case where you can
Steve: the problem is when the container is smaller than its child
Bert: currently you are unable to align things
<anne> (<div align=center> is equivalent to <center> in centering behavior)
Daniel: if you center the block then it's easy, you center the block inside
its parent
Elika: do it like background
Elika: if we want true center alignment, the author should have to make a
conscious choice of what happens when it overflows.
Tantek: Jason what do you think?
Jason: I'm thinking.
Alex: you should have both options
Tantek: I disagree, only options for which there are known use cases.
David: everybody wants one thing out of this property and it is different
for each person.
Bert: I didn't actually want to discuss this. I was asking about vertical
alignment
Jason: What is happening with these two boxes?
Anne hooks up his laptop to the projector to show examples
Anne: The job of the center element is not to center itself, but to center
its descendants
Anne: text is also centered, but that should be left to text-align
Anne: shows example that all block descendants of <center> are centered
Anne: inline text is also centered, but that's already handled by text-align
Anne: also, <div align="center"> works the same as <center>
Bert: is the requirement to reproduce this?
Anne: authors are used to this behavior, and thus perhaps it would be good
to have an equivalent for <center> in CSS
Bert: this seems like it affects too many things at once
Anne: this can be handled by simply defining a UA style sheet rule for the
<center> element
Bert: should it be inherited?
David: what authors want is to just center align everything, and thus is is
easier if you just make it inherit
Elika: it is hard to undo inheritance
David: it is harder to undo universal selectors if you are forced to use them
Steve: if you have to override it then you have to fix all child siblings
<glazou> you can use #topmost { block-align: center } and
#topmost * { b-align: inherit } and the property does not apply to
all decendents
Bert: it does seem we want a separate property
Steve: we are going to need it for vertical
Steve: and not having the same thing for horizontal would be confusing
Bert: are there any other values?
Anne: left and right
Bert: that's handled by margin auto
Tantek: unintuitive and hard to teach people
Bert: do we need start and end?
Daniel: yes
<fantasai> left | right | center | start | end
<fantasai> default is start
Tantek: I thought the start end thing was orthogonal, that that applied to
lots of properties
Jason: sounds like to me we need something like clear for alignment
Jason: so that you could assign an element to stop aligning
Anne: that would be block-align:initial
David: if it inherits
Peter: what happens if there is a sibling to the inner div (in the example
on the whiteboard)
<Bert> 'block-align: left; margin-left: auto' is that left or right aligned?
Currently it is right.
if it is not inherited, we couldn't use this to handle div align=center
David: if it is not inherited, we couldn't use this to handle div align=center
David: it would be too inefficient
David: we need to use the fast mechanism of inheritance for this
Tantek: I tend to agree with David
Alex: you can control them separately
Anne: the question is you have a block box
Anne: h1 and div that are siblings
Anne: if you want to align the h1 to the left
Anne: and the div to the right
Anne: that would not work with block-align that only works to its children
Steve: the same problem will arise vertically.
Steve: maybe we should give up on horizontal as unnecessary to solve at this
point and look at vertical
Anne: I think it is clear because of the way div align="center" works
Steve: it may not match the way we want to go in the future
Steve: if we are going to introduce block align vertical we should try to
make it compatible with block align horizontal
Arron: are we comfortable with how block align works here and now talk about
vertical
<dbaron> For what it's worth, we have 6 different lists of values of the
align attribute in HTML.
David: what is it there that you can't do with margin auto?
Bert: it works only when the containing block is wide enough
Anne: given that this is the behavior that authors are used, I'm not sure
what the harm is in giving them a CSS way to do the same thing
Anne: I think all use cases have been addressed, have been done.
Alex: I agree there
Peter: I want blockquotes centered, but text left aligned
Anne: that can be done with margin auto
David: I need to see the example
(Anne updates example on screen)
Steve: block-align would apply to children, be inherited, and margin would
allow you to override it on children
Peter: the only thing that bugs me about this is that if we are using margin
auto to force the behavior of block alignment then why are we doing
block-align
David: margin auto is for one element. block alignment for all descendants
of that element.
Jason: I can see the case for both, where I want it centered all the way down,
and I can see it needing it specifically on specific elements. There
needs to be a better way than margin auto
Jason: because margin auto is not an intuitive way to do it
Jason: to me it is very simple: block align horizontal - I want it centered.
David: the distinction is one element vs. subtree thing
Peter: as long as you handle overflow situations, I'm ok with that distinction
Jason: again it gets back to the intuitiveness of margin auto - that's the
problem.
Steve: I have some text that is left aligned, then a nested blockquote which
is centered, and then an attribution on the right.
Elika: Use case: centering shrink-wrapped table with margins
Elika: when lots of content, still have some spacing on sides
Elika: when small content, table is still centered, not left-aligned
Tantek: you could make it work with block-align applying to the element itself
(lots of discussion of block-align applying to the block itself, or children,
or both, and/or inheriting)
Alex: we already have two ways to center, I'm not sure we have justification
for a 3rd way
Peter: the HTML way is deprecated
Peter: we don't want new documents to use it
Anne: yes, and therefore having a CSS way would solve that
Steve: your point is valid.
Anne: given that all implementers would like to implement this property,
child-block-align, we could all do prefixed versions
-ms-child-block-align, -moz-child-block-align etc., or we would just
all agree on one and do it the same.
Tantek: sounds like you (Anne) want to write up a child-block-align proposal
with a URL
Elika: I think Anne is right, but it doesn't solve all the use cases
Anne: we couldn't think of one that it doesn't.
Steve: it doesn't do that one (blockquote and cite)
Elika: it doesn't solve mine.
Peter: we have taken an hour and a half so far
Tantek: are going to talk vertical now?
Bert: that's what I wanted to talk about
Steve: I want to express a straw poll
Steve: at least three of us say that block-align applies to the margin box
Steve: anyone disagree with that?
(silence)
Steve: ok, resolution, it is the margin box that is positioned
Elika: it looks like we need two properties to address this
Elika: one, make current uses cases accessible, and two the centered,
shrinkwrapped table case
Tantek: we are still talking horizontal right?
Steve: yes we are still talking horizontal
Tantek: someone needs to write up a proposal
ACTION Elika write centering proposal for 2 properties
ACTION: Elika write block-align centering proposal
<Bert> (See http://www.w3.org/blog/CSS/2007/12/03/box_module_the_horizontal_centering_prob
for an ilustration where centering with auto margins doesn't work.)
ACTION: Elika write child-block-align centering proposal
Bert: I did integrate and update Markus's proposal into the box model module
* dbaron thinks Bert said the URL is the://internal/version
break before we switch to vertical
<anne> demo:
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0A%20center%20{%20border%3Adotted%201px%3Bwidth%3A200px%3Bmargin%3Aauto%20}%0A%20.x%20{%20width%3A50%25%3B%20border%3Athick%20solid%20red%20}%0A%20div%20%3E%20div.x%20{%20border-color%3Ayellow%20}%0A%20h1%20{%20width%3A50px%3B%20border%3Asolid%20purple%3B%20margin-right%3Aauto%20}%0A%2F*%0A%20center%20{%20%2F*block-align%3Acenter%3B*%2F%20child-block-align%3Acenter%3B%20text-align%3Acenter%20}%0A*%2F%0A%3C%2Fstyle%3E%0A%3Ccenter%3E%3Cdiv%20class%3Dx%20align%3Dright%3E%3Ch1%3Ex%3C%2Fh1%3E%3Cdiv%20class%3Dx%3Ex%3C%2Fdiv%3E%3C%2Fdiv%3E%3C%2Fcenter%3E
Peter: 15-20 min break
<Bert> Alignment property in current Box Module:
http://www.w3.org/Style/Group/css3-src/css3-box/Overview.html#the-alignment
resume meeting
Elika goes to the whiteboard to start discussion of vertical alignment
discussion of vertical margins vs. horizontal margins
discussion of vertical text layout applying to this situation - and noting
that it is orthogonal and an issue that needs to be more broadly discussed
<Bert> [Questions about margin collapsing: is 'block-align: top' the default
or 'block-align: auto'? I.e., does 'top' cause collapsing margins?]
David: I don't see the use case for introducing block-vertical-align:top as
something distinct from the default behavior now
Alex: if you set this on the body, and you want the behavior of the child
element to be same as the float, you would expect margin collapse
David: floats are going to be hard for this. does block-vertical-align affect
floats
David: if the block has a first child that is a float?
Alex: layout everything and then ...
<Bert> 'block-align: top; margin-top: 1em'
David: maybe if there is a new block formatting context
<dbaron> nasty case is floats protruding into block
Steve: what happens with floats from the block above protruding into the next
vertical block?
<dbaron> because layout and then slide around doesn't work
Alex: I think if you say it is a new block formatting context, everything
becomes simpler.
David: yes
Alex: so we need 4 different values
Steve: why does creating a new block formatting context solve the problem?
David: float protrusion is ignored across block formatting contexts
David: the whole block simply doesn't overlap the float
Steve: it's like an implicit clear
Elika: no, you might end up with things next to each other
Steve: then it's like table
David: yes
Elika: people will use this to turn off margin collapsing
Bert: I just had a strange idea, instead of a new property block-align,
add display value centered-block
David: what if you want to center an inline-block or table cell etc.
Steve: I can't support that either because I think it overloads display too
much
Steve: so we had, Alex wanted four values
Alex: anything other than "none" introduces a block formatting context
Alex: we do normal layout in that context
Alex: if the distance between the top margin of the first child and the
bottom margin of the last child is smaller than the vertical space
within the element, then we can align to bottom or middle.
Bert: if it is more...
Alex: if it is more, then we get into the issue of centering something
that doesn't fit
Bert: the question is which side does the overflow go on
Elika: How does this interact with vertical-align on table cells? I think
you need the default to be 'auto' which means honor vertical-align
on table cells
Steve: the only way we can introduce this property is if the default is
"do what we do today"
Tantek: I'm asking for a picture at this point
Alex goes to whiteboard
Alex draws example of what he just said above
Steve: so we include the margins as part of the chunk that is aligned?
Alex, others: yes
Alex draws a float
Bert: does this apply to table cells?
Bert: just a question - i don't know the answer
Alex: it should apply to everything
and if both are applied, I'm not sure
Alex: if both are applied, the new property wins
Bert: similar case, advanced layout, how do you center something in a grid
cell?
Bert: is that vertical-align or a new property
Elika: the advantage of vertical-align is a baseline value which you might
want
Alex: you have to have a baseline for that
Alex: as long as you can define what a baseline is for a group of cells
Alex: in advanced layout that would be an interesting challenge
Alex: no that is not going to work
Bert: I don't know any designer that doesn't want baseline alignment.
Elika: you don't need to use advanced layout for tabular data or name-value
pairs
Bert: may or may not
Elika: in Jason's layout you may want to have them align
Bert: who is going to write up the vertical case?
Steve: the hard part of the vertical case is what it is that we do today
ACTION: Alex write up the four value proposal for vertical alignment for
the block-align property.
page-break-inside
-----------------
Peter: next subject
Peter: page break
ScribeNick: Bert
Elika explains page-break-inside issue
Some use cases...
Elika argues the need for not inheriting 'page-break-*: avoid'
Steve: XSL adds a strength to its "keeps" (which are like page break avoid)
Peter: Could als have additive strength: every child can add to the strength.
Steve: yes, then you break ate the lowest strength break point by preference.
Alex: We are willing to reverse the CSS 2.1 implementation.
David: How de we get in this situation?
David: with different implementations doing inheritance or not.
<fantasai> http://fantasai.inkedblade.net/style/tests/issues/page-break-inheritance
* Bert suspects that doesn't work...
Fantasai: Could make nested avoids stronger later
Alex: It is probably not possible to find the bext break point without a
O(n^2 ) algorithm.
Alex: An explicit property is probably better than a complicated algorithm.
Alex: Our plan is to ignore the proeprties when no page break is allowed
and find a page break then.
Alex: Maybe not try to solve that problem now.
Fanatasai: But leave possibility open.
<anne>
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Cstyle%3E%20%23x%20%7B%20page-break-inside%3Aavoid%20%7D%20%3C%2Fstyle%3E%0D%0A...%3Cdiv%20id%3Dx%3E%20%3Cdiv%20id%3Dy%3E%20%3C%2Fdiv%3E%20%3C%2Fdiv%3E%0D%0A%3Cscript%3E%20w(getComputedStyle(document.getElementById(%22y%22)%2C%22%22).pageBreakInside)%20%3C%2Fscript%3E
shows that Opera does inherit page-break-inside:avoid at least for getComputedStyle purposes
Alex: Even if we define this better, there will not be perfect interop.
We would also need line height more interoperable.
Alex: I expect we will not do the strength. Would prefer to honor a 'allow'
value.
Steve: XSL is implemented and works, with strengths.
<dbaron> It's nice to see that 13.3.3 and 13.3.4 say page-break-before
and page-break-after both apply on both sides of the box
Peter: So we make minimal change in CSS 2.1 and do more later.
David: This change requires a new last calll.
Peter: We can go to last call and only accept comments on the specific change.
Fantasai: But white space in tables also requires a last call.
<fantasai> * In CSS2.1 make page-break-inside not inherit anymore, but still
<fantasai> discourage breaks inside its descendants: basically avoid
breaking at a break point with a page-break-inside: avoid
ancestor (rather than direct parent).
<fantasai> -- 'page-break-inside' no longer inherits
<fantasai> -- 13.3.3 rule D says
<fantasai> Rule D: In addition, breaking at (2) is allowed only if the
<fantasai> 'page-break-inside' property is 'auto' <INS> and no ancestor
<fantasai> has a 'page-break-inside' property of 'avoid'.</INS>
Steve: I'm opposed to the change.
Bert: I'd rather not change either.
Steve: A last call cannot be restricted to just one change, must accept
comments on everything.
Anne: The test case doesn't seem to test what Elika proposes.
Elika: It does
ACTION: Elika and Anne to review test case for page break inside and report
back with a recommendation to the group about how to move on
Syntax
------
Fantasai: Concerned about difference in white space syntax of nth-child()
and calc().
Fantasai: Want consistency: either both need space or neither.
Anne: Principle should be that space is irrelevant.
David: Except where it s needed, between two idents, e.g.
[Example of 2n-1 being a DIMEN token]
Anne/David: and if we ban numbers or non-letters from units...
David: but allow underscores (for vendor extensions)
[but "n-1" is an ident and will remain an ident]
<glazou> exactly
Peter: Can we change an+b to a,b ?
Daniel: too late for that.
Daniel: and the "n" and "+" help to show which number does what.
[Spec has no examples with white space]
Daniel: Even so, people will write with white space.
David: No space between a and n is fine, looks similar to a unit.
Tantek: no space between sign and number either.
Daniel: I think people will put a space between + and b.
Daniel: We should consider user's point of view. Either way is not so
difficult to implement.
Daniel: "7n + 3" looks very intuitive, is used in many other places
that people now.
Peter: And "2n + -3" ?
several: should be forbidden.
Alex: Can we allow spaces as well as no spaces and define what "n-1"
means separately?
<fantasai> http://lists.w3.org/Archives/Public/www-style/2008Mar/0111.html
[More dicussion about what spaces are required in calc()]
Peter: I don't think designers will understand that spaces are not allowed
in nth-child but *are* required in calc()
Daniel: We will get some comments on this no matter what.
Steve: Yes, but only it is shipped.
Steve: Why not make nth-child argument an expression?
Steve: ... with exception of the an part, which must remain together.
<fantasai> http://lists.w3.org/Archives/Public/www-style/2008Mar/0111.html
<fantasai> http://lists.w3.org/Archives/Public/www-style/2008Mar/0121.html
David's proposal (link 0111 above) allows space except between a nd n.
<tantek> in the interest of progress I'm ok deferring to David's proposal.
Fantasai's variant (link 0121 above) is a better wording.
[David describes the parsing algorithm anddealing with incorrect expressions,
such as "+-3"]
David: 3n++2 has to be rejected, too.
Steve: The spec doesn't actually say anything about ++
Tantek: Better not mess with something that has been CR for so long, five
years, already.
David: I'm OK with relaxing restriction in the future, but not for this
version.
Peter: We don't have to note in the spec that we may lift the restriction.
<anne> Anne: I think allowing an+-b is fine
Steve: Question if it is editorial or not depends on if it changes the
conformance.
<anne> (and an-+b for that matter)
Strawpoll on Elika variant of David's proposal:
Numerous in favor, no opposition.
[Discussion about what the spec allows or not about spaces]
ACTION: Daniel to make changes to spec for Selectors to allow spaces as
per David/Elika's proposal.
CSS2.1
------
<fantasai> http://lists.w3.org/Archives/Public/www-style/2008Mar/0166.html
<fantasai> which is issue 38 http://csswg.inkedblade.net/spec/css2.1#issue-38
Are attribute selectors [att~="x x"] (i.e., with a space) allowed or not?
<fantasai> RESOLVED: Copy wording from Selectors 3 to CSS2.1
ACTION: Bert to make change to CSS 2.1 as per Elkia's proposal.
* trackbot-ng noticed an ACTION. Trying to create it.
* RRSAgent records action 10
<fantasai> http://csswg.inkedblade.net/spec/css2.1#issue-24
http://csswg.inkedblade.net/spec/css2.1#issue-32
<SteveZ2> The definition of a substantive change (which can trigger a return
to WD) is:
<SteveZ2> A substantive change (whether deletion, inclusion, or other
modification) is one where someone could reasonably expect that
making the change would invalidate an individual's review or
implementation experience.
David gives example: @media screen { p {color: green} div }
The last } doesn't close the @media according to the spec.
<tantek> and according to David, Firefox properly ignores the last } and
keeps processing "inside" the @media block, whereas *other* (not
named) implementations close the @media block by that last }
<tantek> and I know exactly what this will be used for. >:D
Bert: I'm not sure I agree with David's analysis.
Elika: Extending this (issue 24), we should have thematching-brackets
principle apply generally across CSS and be the strongest parsing
rule after strings -- and it should apply everywhere, not only in
declaration blocks
Peter: Do you always close an open paren on the stack before any other
recovery rule?
Steve: After an error, stop as soon as possible?
Peter: Other example: @media screen { p {color: green} div:nth-child( }
Peter: Now there is a { and an ( open.
Anne: And if it were a different @-rule, say a future one, that does not
have rules inside?
Anne: Or consider a UA that doesn't implement @media.
Anne: The example of David is well-formed.
David's proposal to fix the spec is
http://lists.w3.org/Archives/Public/www-style/2008Mar/0353.html
David gives another example: p {width: calc(3px }
Fantasai: this would eat the } as part of the calc.
Daniel: There is an error and thus you look for a }, which you find right
away.
Fantasai quotes from text that says to skip tokens but match paren pairs.
<anne>
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%0A%3Cstyle%3E%20%23x%20{%20background%3Aurl(x}%20)%20}%20%23x%20{%20background%3Alime%20}%20%3C%2Fstyle%3E%0A%0A...%3Cdiv%20id%3Dx%3E%20xxx%3Cdiv%20id%3Dy%3E%20%3C%2Fdiv%3E%20%3C%2Fdiv%3E%0A%0A
<anne> (try removing the closing parenthesis)
<fantasai> "Malformed declarations. User agents must handle unexpected
tokens encountered while parsing a declaration by reading until
the end of the declaration, while observing the rules for
matching pairs of (), [], {}, "", and '', and correctly handling
escapes. For example, a malformed declaration may be missing a
property, colon (:) or value."
<fantasai> from 4.2
ACTION: Arron to come up with more tests.
Topic: Issue 25
<fantasai> http://csswg.inkedblade.net/spec/css2.1#issue-25
<fantasai> Define what effect } has in style attribute syntax.
<anne> (I wonder if it's defined that '{}html { background:lime }' should
apply)
David: There are actually different rules in Firefox in quirks vs standards
mode.
<fantasai> style="color: red; } ; color: green; "
<fantasai> is it red or green?
Peter: Is it an HTML question or CSS question?
David: I suspect HTML says something vague like: expects style data...
Anne: HTML5 says a declaration block, I think.
<glazou> The syntax [p.57] of the value of the style attribute is determined
by the default
<glazou> style sheet language [p.186] . For example, for [[CSS2]] inline
style, use the
<glazou> declaration block syntax described in section 4.1.8 (without curly
brace delimiters).
Daniel: HTML says the style sheet language chose determines the syntax.
* anne tries loading HTML5...
<anne> it should be somewhere here:
http://www.whatwg.org/specs/web-apps/current-work/multipage/section-wysiwyg.html
<anne>
http://64.233.167.104/search?q=cache:NGAhkwJnYLMJ:www.whatwg.org/specs/web-apps/current-work/multipage/section-presentational.html+html5+style+attribute&hl=en&ct=clnk&cd=2&gl=us&client=opera
<anne> "The style attribute, if specified, must contain only a list of zero
or more semicolon-separated (;) CSS declarations."
<fantasai> http://lists.w3.org/Archives/Public/www-style/2007Dec/0167.html
<plinss> style="color:red}"
<plinss> style="color:red;}"
<anne> style="color:lime; (; color:red"
<anne> (though per HTML5 that could be argued to be red)
Daniel: Peter's first example is thrown away, the second has one valid
declaration.
Anne: Can split at ";" first and then parse each part, or parse the whole as
a CSS block.
ACTION: Daniel report to HTML WG that def of style attr in HTML5 is
incompatible with def in HTML4 and probably problematic from point
of view of CSS parsing rules.
<dbaron> For example, for [[CSS2]] inline style, use the declaration block
syntax described in section 4.1.8 (without curly brace delimiters).
<dbaron> is what HTML 4.01 said
Tantek: So HTML should not define any rules?
Tantek: The CSS module for Style attribute syntax was supposed to define this.
Tantek: Could strip that module to just the piece that describes the current
style attribute and take it to PR immediately.
RESOLVED: a mismatched closed brace in a style attr is treated as an invalid
token.
<anne> style="} background:red " versus style="}background:red "
<anne> versus style="};background:red "
<fantasai> http://lists.w3.org/Archives/Public/www-style/2008Mar/0166.html
<anne>
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A...%3Cdiv%20id%3Dx%20style%3D%22background%3Ared%20%22%3E%20xxx%3Cdiv%20id%3Dy%3E%20%3C%2Fdiv%3E%20%3C%2Fdiv%3E%0D%0A%0D%0A
Empty Substring Attribute Selectors
-----------------------------------
David: Previously we decided they were parse errors.
David: But it also seems to affect ~= in CSS2, so now I think we should not
do that, because it affects CSS2.
Peter: Previously we said it was valid but matches nothing.
David: CSS 2.1 says it;s a space-separated list of words, an empty string
has no words, so matches nothing.
Peter: How about [x~=" "] (*two* spaces), is that an empty word between
two spaces?
<anne> (I like what Opera does for style attributes. Open the block, close
it when you hit }.)
Peter: Existing behavior is that it matches nothing, in three implementations
Peter: So propose to revert previous decision and say it is valid (but
matches nothing).
Peter: Spec should makes this explicit.
ACTION: Elika check in Alan Gresley's empty attr selector testcases for
CSS2.1/CSS3, investigate :not()
David: For the other attribute selectors, the empty string *always* matches,
rather than never. Only Mozilla matches nothing, but I can change that.
Peter: Would like similar behavior from all attribute selectors.
David: Matching on words with ~= is somewhat different from matching
substring, though.
Proposal: *= ~= ^= $= all accept empty string, but match nothing
RESOLVED: proposal accepted
Question about two spaces in [x~=" "] was not further discussed.
End of meeting.
<dbaron> We should consider adding
<dbaron> ot txet cinodehportsuob
<dbaron> Cascading Style Sheets.
<glazou> ADJOURN FOR TODAY
ACTION: Elika post page-break-inside examples to www-style
<Hixie> if anyone is still here who is near daniel, let him know that i
agree with his comment on style="" and html5
<Hixie> and that the spec will be fixed in due course
Received on Wednesday, 2 April 2008 19:20:19 UTC