W3C home > Mailing lists > Public > www-style@w3.org > April 2008

[CSSWG] Minutes F2F 2008-03-27

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 02 Apr 2008 12:19:32 -0700
Message-ID: <47F3DC44.4060208@inkedblade.net>
To: www-style@w3.org

Meeting: CSS Working Group Meeting, San Diego, CA
Chair: Daniel Glazman, Peter Linss

   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


   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
   Steve: event target Europe rather than US designers
   "An Event Apart"
   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
   <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:
   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?
    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
    [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
    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
   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


   Bert: Box sizing wasn't handled yet
   Fantasai: I had a proposal there
              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
   <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
   * 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(),
   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 ====


   * 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
   <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
   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 { 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?
   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
   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
   <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
   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
   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?
   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:
   Peter: 15-20 min break
   <Bert> Alignment property in current Box Module:
   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
   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
   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
   Bert: is that vertical-align or a new property
   Elika: the advantage of vertical-align is a baseline value which you might
   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
   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.


   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.

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'
   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


   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
   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
   <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.


   <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
   <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
   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
   Fantasai quotes from text that says to skip tokens but match paren pairs.
   <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
   David: There are actually different rules in Firefox in quirks vs standards
   <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:
   <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
   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
   <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

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.
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

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:35 UTC