W3C home > Mailing lists > Public > www-style@w3.org > June 2009

[CSSWG] Minutes F2F 2009-06-03 Part III: Multi-col, Abandoned Drafts, Splitting border-image

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 16 Jun 2009 23:31:35 -0700
Message-ID: <4A388DC7.4090801@inkedblade.net>
To: www-style@w3.org

Multi-Col
---------

Scribe: fantasai
   howcome: We have three issues
   howcome: We have generally agreed to go to last call, but one issue came up,
            and Alex raised another issue I would like to resolve as well
   howcome: The one issue that was left from the Tokyo F2F was about
            expressing column breaks
   howcome: There have been various proposals that were discussed on
            www-style afterwards
   howcome: I put in the proposal I thought we had consensus on in the
            mailing list
   howcome: where we go from having a set of page-break-* properties to
            using more generic names
   howcome: adding new keywords to express column breaking
   howcome: This would be an alias, which is something new in CSS
   anne has some concerns about expressing this in the DOM
   http://lists.w3.org/Archives/Public/www-style/2009May/0100.html
   howcome: other options are to add new properties for columns
   howcome: and the resolution from the last f2f was to simply add new
            keywords to page-break-*
   howcome: which would result in e.g. page-break-before: column
   http://lists.w3.org/Archives/Public/www-style/2009Apr/0270.html
   <anne> the concern is that introducing a new CSS property introduces a
          new DOM attribute even if you call it an "alias"
   http://lists.w3.org/Archives/Public/www-style/2009May/0100.html
   <anne> (unless we start doing trickery)
   <anne> (and I'm not sure how that'd work, to be clear)
   <anne> (arguably you could remove pageBreakBefore from the DOM and
          obsolete it in favor of breakBefore under the assumption that
          nobody relies on it anyway)
   people were unhappy with page-break-*: column because it's confusing
     and awkward
   howcome: I think creating six new properties for this is overkill
   Alex: One of the reasons we didn't like adding column-break before
         was that not all combinations of column-break and page-break
         didn't make sense
   Alex: now we have arrived at the conclusions that all combinations
         are sensible, so should be able to provide all
   howcome prefers the alias approach, and doesn't think there's enough
           dom use of page-break properties to block shifting that over
   <ChrisL> break: nicely
   fantasai summarizes the three proposals in Melinda's email
   Molly thinks the shorthand thing makes sense
   howcome wants to avoid creating new properties
   howcome: anyone object to #2?
   Bert objects
   Bert: I hate aliases, but I want only one property I want to set.
   Bert: break-* is too generic, imo. We have lots of kinds of breaks,
         e.g. line breaks which are totally unrelated
   discussion of whether #3 is an "alias" (where separation is maintained
     through the system) or a "syntax feature" (which gets resolved at
     parse time)
   Alex: we could also do #2 without the shorthand
   Alex: I don't think shorthands are useful or necessary here
   some disagreement with that
   Steve: Another thing to consider is spreads
   fantasai: Melinda suggested adding 'avoid-turn' to 'page-break-*'
   Arron: I think #2 is easier to understand
   Molly: #3 is freer because it's not dependent on the media
   fantasai: If I have a multicolumn layout on pages, I can say that
             page breaks are just as bad as column breaks and both
             should be equally avoided
   fantasai: Or I can say that page breaks are worse than column breaks,
             and I want to avoid column breaks, but even more than that
             I want to avoid page breaks
   fantasai: So I may wind up skipping columns in order to keep things
             on one page
   fantasai: How do I express these as two distinct possibilities?
   RESOLVED: #3 -- page-break-* as syntactic suga

   howcome: Alex suggested taking out column-span
   howcome: He thinks we can express this in other properties
   Alex: It's weird that it takes the values '1' and 'all'
   howcome: Alex is saying that we don't need this, you can just put extra
            <div>s around the content before and after the spanning element
   fantasai: If you want an image to span multiple columns what are you
             going to do, put <div class="before-image"> and
             <div class="after-image"> around the content before/after the image?
   <ChrisL> this requires some ugly presentational markup; i don't like
            forcing authors to do this
   discussion of column-spanning and nested multicol elements
   Chris: Can you do column-span: 2 in a 3-column layout?
   Yes, this feature was there before but was hard to define/implement so
     we're starting with column-span: 1 | all
   Alex: I'll have to take away my statement that this can be done with
         other things.
   Chris: Maybe call '1' 'one' instead, to avoid that people expect '2' to work?

   Someone asks what happens if there's a float that's wider than the column
   it overflows the column
   and affects adjacent columns
   fantasai: Does it affect previous columns, or only subsequent ones?
   discussion of this issue
   floats that affect previous columns are complicated to implement, it
     requires multiple passes
   floats that affect subsequent columns are straightforward
   RESOLVED: howcome to add an example of a float intruding into previous
             columns and we wait for implementors to complain

   Sylvain: There's also an issue on the pseudo-algorithm
   <sylvaing> http://lists.w3.org/Archives/Public/www-style/2009Jun/0009.html
   <sylvaing> and summarized here to try and make it more readable:
              http://lists.w3.org/Archives/Public/www-style/2009Jun/0046.html
   howcome: Adding line numbers is easy
   <glazou> Bert is playing Simon game with the conf-call hardware
   howcome: The hard one is the shrink-to-fit one
   <dbaron> http://dbaron.org/css/intrinsic/ has some work on defining
            the shrink-to-fit algorithm
   howcome: we could point to the shrink-to-fit algorithm, but we can't
            define it here
   Bert reviews the proposed changes
   RESOLVED: accepted to fix


Abandoned Working Drafts
------------------------

Scribe: alexmog
   discussing mathml
   RESOLVED: css math -- dropped
   anne: what does dropping mean?
   daniel: another group takes over

   CSS style Attribute syntax 3
   chris: scoping is still needed?
   discusing scope, how it is related to HTML5
   anne: HTML5 allows more, media independent style sheets, etc.
   david: suggest dropping this spec but publish what needs to be
          specified elsewhere
   RESOLVED: drop "style attribute syntax" spec
   RESOLVED: keep "style attribute syntax" spec, remove extensions,
             only keep current syntax
   ACTION: fantasai: edit "style attribute syntax" to constrain to current syntax

   CSS Hyperlink Presentation Module
   daniel: reason for the spec is to allow to overide link behavior
           from user style sheet
   the behavior is now available via DOM
   browser vendors don't express interest in implementing it
   RESOLVED: drop Hyperlink Presentation module

   CSS Web Fonts Level 3
   merged with CSS3 Fonts -- links should be redirected to the merged spec

   CSS Introduction
   RESOLVED: snapshot will override; when snapshot is published,
             introduction link will point to the snapshot

   CSS Reader Media type
   already dropped, should not be in current work
   RESOLVED: publish a note on not working on CSS Reader Media Type

   CSS OM View
   Anne is working on the spec, it is meant to obsolete DOM spec
   status -- in WD for over the year
   anne: time to publish a new WD
   RESOLVED: publish a new working draft on CSS OM View
   anne: have requests for support of 3D transforms

   RESOLVED: Aural stylesheets - dropped

   CSS Lists
   fantasai: should not be dropped

   CSS Scoping
   daniel is the editor
   daniel: the idea was to suggest a way to scope stylesheets to an
           element; HTML5 has scoping support, this spec is not needed
   RESOLVED: CSS Scoping is droppped

   CSS Ruby
   IE has partial implementation
   ACTION: Arron to send a list of CSS Ruby properties supported by IE8
   RESOLVED: Ruby spec is on hold until an editor is found

   CSS Object Model
   no working draft yet
   anne: huge project, no time currently
   RESOLVED: CSS Object Model -- not dropped, abandoned for the time being

   CSS Presentation Levels
   Hakon: let's drop it. it's going nowhere.
   RESOLVED: CSS Presentation Level -- not being worked on for undetermined time
   discuss the difference between dropped, abandoned and on hold
   discussing keeping documents on low-priority, off-charter list vs.
     completely removing documents and saying we are not working on it any more
   RESOLVED: CSS Presentation Level -- discontinue, publish a note
             that contains the whole content of current document

Splitting border-image
----------------------

Scribe: Sylvain
   <fantasai> http://www.css3.info/border-image-issues/
   <fantasai> Second issue
   <fantasai> border-image: url(...) 20% 40% / 10% 4em 20% / 0 1em;
   fantasai: comments were requested on issue #2
   fantasai: i.e. syntax is arcane
   fantasai: someone suggested splitting into multiple props; helps JS
             manipulation....
   fantasai: ..or :hover selector
   fantasai: many other responders expressed support for this idea
   chrisl: even if we add properties we should preserve the current syntax
           since it has been implemented, even if behind a vendor prefix
   fantasai: yes, absolutely, the shorthand syntax remains
   fantasai: it does create more properties but people find it simpler and
             like the flexibility
   fantasai displays second issue from http://www.css3.info/border-image-issues/
   (comparing split example against border-image property definition...)
   hakon: does border-image-outset change the size of the boxes ?
   fantasai: no
   chrisl: can outset values be negative to make insets ?
   fantasai: no
   <dbaron> I'm not crazy about separating border-image-slice from
            border-image-source.
   <dbaron> (And there was agreement that border-image-widths should be
            border-image-width.)
   fantasai explains that border-image is a painting effect i.e. it does
            not affect the size of the border box
   anne: optimizing for the case where the image cannot be loaded seems wrong
   chrisl: it's not an optimization. you also want to avoid layout flicker
           when the image resource loads slowly
   bert: not sure we need the complexity of outset
   fantasai and chrisl disagree
   fantasai: any objections to splitting border-image ?
   bert: not to the principle but to the naming
   fantasai: so we drop the plural on border-image-width. anything else ?
   <fantasai> add border-image-repeat for the keywords
   discussing the default for border-image-repeat: tile or stretch ?
   dbaron: we might want to leave this open for now
   <fantasai> Mark border-image-repeat name as an open issue
   RESOLVED: border-image property split proposal is accepted

glazou declares an end to the hostilities
Received on Wednesday, 17 June 2009 07:48:20 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:18 GMT