- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 16 Jun 2009 23:31:35 -0700
- 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 UTC