- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 04 Nov 2008 19:49:12 -0800
- To: www-style@w3.org
<RRSAgent> logging to http://www.w3.org/2008/10/20-css-irc
<Hixie> glazou, plinss: i'm around; let me know if/when i should
attend the css meeting, i have multiple clashing meetings
but am happy to move from one to the other as needs warrant
<glazou> Hixie: sure thing ; how was discussion with tbl?
<Hixie> good, good
<glazou> wb CWilso :)
<CWilso> :)
* CWilso expects to float between webapps and css today. If there's
anything you particularly want to smack me around on, let me know when.
<glazou> ok, cool
<glazou> we'll start with css system colors at 9:30
<glazou> the accessibility guys want us to keep them
<Hixie> quick question about the media queries decisions yesterday --
do they imply any changes required to acid3? should i uncomment
out any of the commented out tests?
<glazou> Hixie: we did not make any MQ decision yesterday Hixie
<anne> Hixie, media queries got published with changes that requires
stuff to stay commented out
<glazou> we made changes during last call related to error recovery
<Hixie> oh sorry, was looking at last week's minutes
<glazou> yeah
<glazou> so, yes, that might trigger changes in acid3
<glazou> if acid3 checks error recovery in media value
<Hixie> ok i'll coordinate with anne
<glazou> ok
<glazou> http://wiki.csswg.org/planning/mandelieu-2008
<glazou> (attendance list monday morning TPAC: jdagget, plinss, Alexm,
fantasai, dbaron, SteveZ, Bert, howcome, dino, glazou
+ Richard Schwerdtfeger)
System Colors
-------------
ScribeNick: Alexmog
Richard is presenting
Richard Schwerdtfeger, IBM accessibility
richard will explain why it is not a good idea to deprecate system colors
Richard: with rich internet apps, we can create objects that use system
color settings like "icon", "menu" etc.
Richard: while system colors are available, accessibility can find colors
and get idea of a role
dbaron is trying to understand why we are talking about using things that
look like system controls but are not system controls
Richard: actually it is to keep application colors in sync with system
settings. e.g. if there is a system color for highlight it can
be applied to tree widgets
Hakon: do you know about personal stylesheet
dbaron: does is have to lead to CSS system colors as a solution?
fantasai: ... ways to override colors based on Aria settings
dbaron: points at the titlebar with a gradient in windows colors dialog
dbaron: css system colors model system effect, but in a simpler way, as a
set of colors rather than exact system effects like rounded borders
or gradients
dbaron: that is a big rationale for deprecation (colors don't represent
exact system effect)
dbaron: another rationale - these are very Windows specific
dbaron: Windows controls are used in controls in multiple combinations that
are hard to map to other systems
... more discussion
jdaggett: I'm concerned that we're going for checking items off a list
rather than actually solving the problem
Richard: My concern is mainly about giving the author the ability to ensure
enough contrast.
Richard: My suggestion is to pick a baseline set of colors: window bg,
text color, highlight colors, and maybe a border color and draw
the line there.
Howcome: Can I show you what we do with Opera?
Howcome projects Opera with high-contrast settings.
dbaron: There are other ways to do this besides style sheets
dbaron: Mozilla has the minimum size pref
dbaron: We also have options to say that the browser should ignore colors
set by the author.
dbaron: When we do that, we also preserve transparency, which you can't do
with an author style sheet.
dbaron: When you start doing things like that, then you get to the point
where a lot of applications will still work.
dbaron: Even if you make government websites meet these requirements,
users are going to want to visit other sites as well.
dbaron: You have the option of solving the problem at one point, and you
have the option of making all authors try to solve the problem.
SteveZ: So what I'm hearing is that system colors doesn't solve the problem.
SteveZ: Maybe the way of solving the problem is identifying ways the browser
can enable a disabled person to view the web
SteveZ: The catch is that the browser is only one aspect of using the
computer.
SteveZ: With system colors, the settings are system-wide
dbaron: When you turn off author colors, usually the browser will use the
system colors as the default.
dbaron: The point I was making a few minutes ago, it seems when there's
the possibility of solving this problem at one point vs. making
each author solve them independently
dbaron: It seems we're going for the high-cost approach.
Richard: The browser doesn't know what the author intended.
dbaron: I'm not saying that the approach I want would mean no work for
the author.
dbaron: For example, the author might have to use appropriate markup to
cause the browser to do the right thing.
Richard: That works for standard form controls.
Richard: But when the author is making custom controls, the author needs
to make the decisions the browser makes
fantasai: Couldn't you make the browser style custom controls based on
the ARIA attributes?
fantasai: If the author uses the ARIA attributes correctly (which you're
assuming anyway) then the browser can have a setting that forces
system colors on those controls based on the ARIA attributes.
fantasai: I note that if you make the authors do the coloring work, most
of them will get it wrong.
Howcome shows Opera's high-contrast and zoom settings on Yahoo Mail
* CWilso is it demo day already? ;)
Richard points at selection not being visible at yahoo inbox
* dino_ - it's always demo day with Hakon around
jdaggett: how would system colors help here?
Richard: because it uses highlight colors of the system
fantasai: aria attributes have enough information to be able to render
with the right colors
Alex: Aria has coarser granularity, not enough to represent UI elements
<glazou> CWilso: you're in France, just thank Orange...
<glazou> because demos w/o connectivity...
discussing tabs on Orange page example...
dbaron: tabs are really really complicated. questioning if system colors
will help
fantasai: browser shoud be able to make things look like tabs...
Alex is not sure what it means
Hakon reminds about mobile
ScribeNick: fantasai
Alex: So what I'm hearing is that you want system colors so that someone
who has the budget to really do a lot of accessibility work they
can make a really cool-looking app with system colors
fantasai: System colors don't give you access to the gradients, bitmaps,
etc. that you need to make a modern-looking app
fantasai: If you want to use system colors, sure you can get enough contrast
fantasai: But your web app will look like a Windows 3.1 application
fantasai: That's the best you can do with system colors
fantasai: The browser can get access to all of that stylistic information
and draw real-looking controls
fantasai: If it has a way of knowing what to draw where
Richard: ...
Richard: I'm proposing that you have four basic colors so you can draw
controls with enough contrast
Peter: That won't be enough
dbaron: I'd like to point out that deprecated doesn't mean gone.
dbaron: Deprecated means there's a better solution
dbaron: It might be not quite ready yet, but this is not the right permanent
solution
Richard: What's the better solution?
dbaron: Some combination of better markup for controls and the CSS
'appearance' property
fantasai: Deprecation means they shouldn't be used in favor of something
else (the 'appearance' property), but they are still required
to be supported.
dbaron: Mozilla has supported system colors for ages.
Peter: It uses them to render its own UI, so it actually has more capability
for representing system-based UI than is in that spec
<Bert> QA definition of deprecated: http://www.w3.org/QA/glossary
<Bert> "An existing feature that has become outdated and is in the process
of being phased out, usually in favor of a specified replacement.
Deprecated features are no longer recommended for use and may cease
to exist in future versions of the specification."
Richard: So I'd request that you add that wording to css3-color
dbaron: I've added it to my issues list
Richard: And we need to come up with a solution
jdaggett: I think it needs to be at a higher semantic level
SteveZ: It would be nice if css3-color linked informatively to the
'appearance' property
discussion about custom controls, HTML5, system colors, accessibility, etc
Richard: lotus Notes 4 had 200 custom controls
...
Richard: So you're saying that these colors are supported in IE, Opera,
Mozilla, and WebKit?
dbaron: more or less
dbaron: but I've had to go through and write implementation reports for these
dbaron: and I couldn't mark them all as passing
dbaron: Each time it was some bizarre judgement call
dbaron: about whether the system color approximated what it was supposed to
approximate
dbaron: whether or not that thing existed on the OS I was running the test on
BREAK
Apple's Proposals
-----------------
ScribeNick: glazou
Topic is Apple proposals (transformations, animations, ...)
dino: webkit has made a few extensions to css in response to external
user feedback
dino: other companies wanted that too
dino: the goal was always to propose it to css wg
dino: css transforms, allows to 2d or 3D transform any element
dino: transitions, animated effects between two sets of properties in
a given time
dino: animations, same but with key frames
dino: the 3 specs are documented on webkit side, looking like w3c specs
<CWilso> goal should be to discuss/design in the WG, imo
dino: webkit nightlies implement transforms, also on iphone, and firefox
has in 3.1
<CWilso> :)
dino: transitions and animations spec also there
CWilso: right
<dbaron> http://webkit.org/specs/CSSVisualEffects/CSSTransforms.html
<dbaron> http://webkit.org/specs/CSSVisualEffects/CSSTransitions.html
<dbaron> http://webkit.org/specs/CSSVisualEffects/CSSAnimation.html
glazou: are all specs implemented ?
dino: yes all of them are in nightlies
howcome: I'm confused, what are the 3 ?
dino: transforms, transitions, animations
howcome: where's gradients ?
<dbaron> http://webkit.org/blog/175/introducing-css-gradients/
<dbaron> http://webkit.org/blog/181/css-masks/
<dbaron> http://webkit.org/blog/182/css-reflections/
dino: there are 3 more, gradients, masks and reflections, not documented
yet very well
dino: only on the webkit blog for the time being
* glazou appreciates dino's english accent, easier to minute
* dbaron notes that's an Australian accent!
dino shows gradient syntax and example
* Bert thinks reflections will be long out of fashion before we get to them...
* glazou then appreciates down under accent
* glazou thinks Bert is wrong here
dino shows reflections syntax and demo
glazou: and how many people are already using this ?
dino: no idea yet ?
howcome: does it change the size of image ?
dino: I can't answer on that but I suppose not
dino: you have to set a margin and the reflection shows in the margin
howcome: why not resize the image ?
glazou: probably too complex to predict the size of the whole thing
jdagget: the reflection is probably the least interesting
glazou: can you use MAMA to determine if web sites already use these beasts ?
howcome: yes
dino: transforms, animations & transitions are in a state for FPWD
dino: not the 3 others
fantasai: dbaron sent a lot of comments six months ago, were they addressed ?
dino: I assume they were
dino: I'm the one editing the specs and I try to keep up to date with
feedback
<fantasai> http://lists.w3.org/Archives/Public/www-style/2007Nov/0223.html
dino: transforms is quite tricky, can influence the content's context
and that goes beyond my CSS knowledge
<fantasai> http://lists.w3.org/Archives/Public/www-style/2008Sep/0043.html
<fantasai> those are dbaron's comments
SteveZ: what about rotation ? a few issues were addressed
<Bert> http://www.w3.org/Style/Group/css3-src/css3-box/Overview.html#the-transform contains the latest text I know
about transformations.
SteveZ: css syntax rules inconsistent with the proposals too
<dbaron> I recall hyatt responding to
http://lists.w3.org/Archives/Public/www-style/2008Sep/0043.html
peter: we discussed it in beijing and cambridge
dino: I have implemented these but not sure spec says it already
glazou: so ready for FPWD ?
dino: yes
glazou, SteveZ: out of scope for current charter
dino: yes we target next target
dino: current charter is terribly vague but
glazou: only a question of a few months
dino: yes, that's why we targetted next charter
dino: do you think this is acceptable and what kind of review would you like?
SteveZ: for transformations, there is a reasonable context
SteveZ: but further down, why isn't it in the scope of the graphics domain?
dino: I get your point on masks, and others
dino: people use JS to do transitions, animations, transformations
dino: this is more dynamic than graphical effect
dino: having it in css makes it really easy to edit
dino: also important for mobile devices
dino: more accessible and not JS-consuming
dino: and if you don't support it, the page is still readable
dino: quite simple to describe and fits well into something like CSS
SteveZ: so why not SMIL ?
dino: these are separate things
dino: nothing in SMIL allows you to do such transitions
dino: different interaction model and you can't update the CSS OM like
we propose to do
dino: animations does definitely have an overlap with SMIL
dino: we are consistent with SMIL, same timing model and yadayada
dino: we wanted to express it as document style rather than markup
dino: so it's triggerable by CSS Media Queries
jdaggett: you could do that using SVG animations
dino: yep, you can even apply it to each other
howcome: you do svg animations
dino: yes, not completely, but enough
dino: whoever designed the acid tests deserve credit for that :)
(laughs)
dino: so very well suited for CSS but I understand also why some people
say do SMIL instead
<dbaron> http://developer.mozilla.org/web-tech/2008/09/15/svg-effects-for-html-content/
<dbaron> (and http://developer.mozilla.org/web-tech/2008/10/10/svg-external-document-references/ )
dino: but it's easy for authors
fantasai: when we asked from feddback from WASP, a lot of people requested gradients in CSS
<fantasai> http://fantasai.inkedblade.net/style/discuss/wasp-feedback-2008#gradients
fantasai: for some of the other effects, the idea of applying SVG is better
fantasai: Got comments saying don't duplicate things, don't have different
ways for same thing
fantasai: creating duplication adds complexity for the others
dino does not agree apparently
glazou: having all of this in CSS makes my job easier for BlueGriffon
Bert and howcome discussing purity vs. pragmatism
jdaggett: SVG people want a lot of things
dino: there're not many people in the world who can do SVG filters that well
fantasai: SVG libraries ?
fantasai: again, I have comments "don't duplicate features' entry points"
(shepazu enters the meeting room)
Bert: CSS and HTML I want to write by hand
Bert: SVG no
dino: CSS should allow to make the easy things easily
dino: full SVG power for complicated stuff
SteveZ: I'm lost
SteveZ: reflection is mostly graphic
SteveZ: that's more relevant in graphics spec
jdaggett: SVG ?
SteveZ: yeah a spec like SVG
SteveZ: should a reflected image itself be an object ?
glazou: just like a complex shadow ?
plinss: why not a pseudo-element so it can be styled ?
howcome demos reflection in video using SVG
glazou: hard to implement in wysiwyg editors
shepazu: I don't see why you shouldn't have it in css if it fits into css
fantasai: again, not a lot of requests for reflections from authors
shepazu: they do it as a graphic !
shepazu: if css is available, they'll use it
glazou: clap clap clap
fantasai: I'm saying, let's add the ability to use SVG filters on an HTML
document
fantasai: so that these things are possible
fantasai: and then see if there's a demand for syntactic shortcuts
dino: we try to be compatible with whatever is already implemented
dino: SVG linear gradients have extra capabilities, that's all
dino compares CSS and SVG proposals here
dino: pretty much exactly the same, expressed more in a CSS way
Alexm: do specs belong to CSS charter?
Alexm: For transitions and animations I do not see a reason why this does
not belong to CSS
Alexm: In the 21st century there should be a declarative way of specifying
these
dino makes a demo with the iphone simulator
dino: written in JS and CSS, 200 lines of JS and 20 of CSS
dino: we moved content from JS code to CSS? far easier to understand
dino: if users understand css, they understand that
dino: the frame rate improved too
dino: we have 3 different animations at the same time here
dino: nice effect doable with CSS
Bert: hey, make one big animated GIF
jdaggett,shepazu: uuuuuuuh
howcome: what if animations are not here ?
dino shows
howcomes: we did replace JS rollovers with :hover
dino: you can use the DOM to trigger your animations
Bert expressed wishes that are not exactly in line with modern web sites :-)
dino shows another demo of movable objects in a page with 1 line of
-webkit-* css
Bert: transitions, agreed, very useful
dino shows an even cooler demo
dino shows a 3d demo, very nice indeed
Bert: transforms ok but low priority
Bert: but why animations ?
Bert: why should I have animations in a site I use for my work ?
dino: user style sheet disables animations !
Bert: good argument
Bert: we'll have a thousand properties and css won't be usable any more
Bert: css is for the low end
Bert: you don't have to know css
glazou: false with my nvu hat
fantasai: 2-columns layout
glazou: basics of css are easy, but false you can edit nice stuff w/o deep
language
<fantasai> I note that CSS has no facility for 2-column layout, table-cell
display in IE will help with that
Bert: at-rule are terrible for instance
all: uuuh ?
glazou: I totally disagree with that, and I authored a book on css2
shepazu: if you ask the CSS teams of browsers if they are interested in
this, they'll reply yes
glazou: mozilla already started
Bert: you have to observe people writing CSS
glazou: I do that all the time, Nvu has 3.5 million users !
shepazu: really complicated to use JS to do that
shepazu: copying 1 line of CSS is far easier !
* glazou nods
Bert: but not SMIL
glazou: are you chosing the most complex solution all the time ?
(anne and Hixie join)
glazou: it will end up in the same block of declarations anyway
Bert: don't use CSS
Alexmog: we should do it
shepazu: is mozilla interested ?
dbaron: we already do transforms and are looking at animations/transitions
shepazu: what about google
Hixie: chrome will ship this, yes
shepazu: so the 4 major browsers will *do* it
shepazu: it seems to me this is the reality of what authors want to do
shepazu: they won't do it if authors don't want it
Bert: I'm more and more convinced that Andy was right saying immplementors
should not decide what goes into CSS
Bert: clean design will go away
shepazu will probably faint before end of the meeting
Hixie: all authors want animations, so much script to do this crap
shepazu: replacing script anywhere is good
Bert: agreed but not in css
glazou: this is an animated discussion and I want a transition :)
dino: to followup on Ian, we've a big web site and we try to make things
easier for web sites authors
shepazu: not having these things leads to inaccessible pages
howcome: come on, easy to turn them off
glazou: we'll have it anyways I think
shepazu: it'll be in every browser in 1.5 year
Bert: you are killing the Web
shepazu leaves, his face red and breath short :-)
shepazu comes back :)
SteveZ: Doug, in his discussion, said that this propagation of features
from one specification to another only make s sense if the
results are coordinated so that we don't get conflicts in the models
SteveZ: so that the models are sufficiently similar so that one
implementation can implement both
SteveZ: it's a different entry point to the same feature, that is easier
to to use
shepazu: a person can still choose to do SMIL
anne: there's already coordination happening
anne: the main problem are prefixes
SteveZ: only emphasizing it should be coordinated
shepazu: the svg wg would like to know about the stuff but is confident
about coordination
shepazu: using css transforms, animations, could be useful in svg as well
glazou: In order to bring this through the rec track, we need more presence
from Apple
glazou: and more people on the wg capable of discussing these technically
dino: conf calls are difficult for me, 3am
dino: dsinger can attend often, but less technical but can relay
dino: ftf are hard, but hard
dino: it's time
glazou: My point, if you are not carrying your specs no one else is going
to do that
dino: we offered to do it
glazou, fantasai: but you need to be present and participate in discussion
glazou, fantasai: we can try to work with logistics, e.g. set up a new
telecon at a better time, but you have to put in the time
and effort to show up
glazou: we also need coordination with other browser vendors
howcome: we have 6 specs here
dino: smaller number of specs is better
fantasai: small specs are better
shepazu: authors think they can do it
dbaron: current separation seems fine to me
* glazou nods
dino: I want to split transforms into 2d and 3d
all: agreed
fantasai: we should get them on dev.w3.org
dino: we do care about the patent policy
dino: that's one reason we want to bring it to w3c
glazou: I don't think it's a good idea to do that right now, since we are
in the process of rechartering
dino: there's a 7th proposal
<dbaron> http://webkit.org/specs/Timed_Media_CSS.html
dino: timed media in css
dino: layout control over time-based elements like video
Bert: but that already exists on your computer
shepazu shakes his head
* glazou laughs
ScribeNick: fantasai
Hixie: I'm a little more dubious about that since they interact with the
DOM in a bad way
glazou: I want to draw a few conclusions here
glazou: First, all browser implementors are interested in these specs
glazou: Second, the SVG working is not totally opposed to this, since
this has a nice coordination with what they do and adds another
entry point into their stuff
glazou: and it reduces the amount of script on the Web
glazou: Bert sees value in transforms and transitions
Bert: and if animations are as simple as transitions it would be no problem
glazou: Fourth, Apple is willing to put what is necessary to make the
proposal evolve along the REC track and has no problem waiting
until the end of the rechartering process
glazou: Last, everybody in the group seems to be interested in the
features, and it is in the scope of the next charter
<Bert> (simple = simple in syntax, i.e., just one new properties and
no @rules.)
dino: The specs are on the webkit.org site, we'll leave them there until
someone says to move them
glazou: anything else we have to discuss on this?
* Bert worried that we have new priorities every three months. It seems
the real priority is to never finish anything :-(
LUNCH
MultiCol, Overflow, and Pagination on the Screen
------------------------------------------------
Scribe: Bert
<glazou> (attendees: jdagget, plinss, sylvaing, fantasai, dbaron, Alexmog,
Bert, SteveZ, howcome, glazou)
Håkon shows some images.
Håkon: I have no solutions, so this could be more like a workshop...
Håkon: Module is quite stable.
Håkon: Just one issue: columns aren't really for continuous media, don't
want columns longer than the window to avoid scrolling up and down,
so height can be constrained...
Håkon: So set height to, e.g., 80% of the page height. But then you get
overflow.
Håkon: Where does the overflow go? Two implementations add extra columns
on the side.
Fantasai: Depends on horiz or vert. context.
Alex: Horizontal scrollbar makes sense in vertical text,
Fantasai: Stacking columns can be a neat idea, make multiple "pages" of
columns, but then need more properties. No single best solution.
Fantasai: also it's really awkward to scroll through that, you need to
position your scrollbars so that the entire block of columsn
fits within the viewport, then scroll precisely to the next set
Alex: Stacking columns can be reasonable if they are about half the vieport
height. Can quickly scroll these "pages" into view. Not great, but
usable.
Steve: If I scroll a column at a time, I keep the context. If I jump to a
page, you don't see the context anymore. Cf. turning the page and
no longer remembering the last line at the bottom.
Alex: For immersive reading experience it is important that the next line
to read is where the previous ended, even after turning the page.
Alex: Scrolling is really bad for that kind of reading experience
Alex: In Word paginated reading mode exists, since 2003. at first we had
2 pages on the screen at the time.
Alex: We found it's confusing for people.
Alex: The sentence that you were reading changes place when you move by
one page.
Alex: Thought there is a place for that mode too, in some cases.
glazou draws: 3 columns, with text below the view.
Peter: Our conclusion was that all modes were valid in some cases, if
the designers wants it.
Steve: Reason for columns is to keep lines short.
glazou: My drawing has a fixed height with overflow per column.
glazou: There will be overlap.
Håkon: Will be an unusable page, consider a phone, e.g.,
glazou: How does user know when to scroll sideways? The overflow is not
visible.
Håkon: That is an issue. Scrollbar may be turned off.
Steve: That's general question: how do you know there is more than you see?
glazou: In my drawing you will know, because there is overlap.
Steve: I don't know if that is on purpose.
Steve: And it may be below the window,
Håkon: 'Overflow' can hide it.
Peter: It's always been a UA issue, but not necessarily an issue here.
Steve: It can happen with any fixed height block, even without multicol.
Alex: Are we discussing a fallback?
Håkon: Agree.
Alex: There is no natural way to overflow columns. Traditional is to
make a new page.
Håkon: That's why I think pagination solution is the right thing to do.
More work, though...
Alex: Author can have a choice, among two non-ideal behaviors.
Håkon: Limiting the height is useful, and should not have text overlap
other text.
Håkon draws paginated columns: 3 columns, then a break, then 3 more
columns below that.
Fantasai: There are sites that only scroll horizontally. Because they
feel like it.
Fantasai: Not necessarily bad, as long as you only scroll horiz,
Håkon: You can do that by setting a big width.
Steve: What width? And you are limited to the screen, so it's overflow
anyway.
(Discussing creation of a new row of overflow columns below the first set.)
Fantasai: You don't want fixed height, you want an auto height that
is determined by the amount of content.
Håkon: Right, needs a separate property column-length or similar.
Håkon: Let's look at that in more detail.
Håkon: It avoid having to set height.
Steve: Now where do they wrap?
Håkon, when the column-height is full, you create another set of columns
of the same height. It's not overflow.
dbaron: But then scrolling is difficult. You have to scroll the exact
right amount.
Håkon: Meta-solution is to have overflow mode pagination as general feature.
Håkon Set overflow-mode: paginate and you will get new pages for all
overflow.
Håkon: Cf NYT reader.
Håkon draws pages with next/previous buttons in the lower right corner.
Alex: Who controls the look of the buttons?
Peter: And if you set overflow-mode on another elt than the root?
Fantasai: Then you get a paged box in the document.
Håkon: I don't think authors want to style the prev/next buttons.
Håkone: we had that discussion with controls for video in HTML5.
Håkon: We will get requests from designers to style them.
Steve: So make that possible.
Håkon: Will need DOM, etc.
Peter: Can be in some later, independent module.
Håkone: Let's try to design it: what are the pseudo-elements called?
Bert: How do you knwo there are two?
Steve: I would want them in the scrollbar, not in the page.
Peter: Also things like "jump 50 pages." We can designe generic mechanism,
but shouldn't be exclusive.
Alex: I have a proposal.
Alex: Current definition of 'overflow: scroll' is very reasnable.
Alex: We can make it scroll the right amount. UI mechanism can be built-in.
Alex: You can bind it to DOM if you want.
Alex: We know the box fits in the container. There are Javascript calls
for scrollwidth/offset already.
Alex: It's not trivial math, but not difficult.
Alex: It would scroll by one page sideways.
Håkon: Where is the backgroundon on an overflowing elt?
Håkon: There is currently no bg behind the overflow.
Peter: Set bg and overflow on two different elts.
Alex: Allow UA to look at 'overflow: paginate' and either do scrollbar
or something better, if it can.
Steve: If you implement 'overflow-mode; you get a better behavior, but
it works without.
Steve: But user probably can't tell whether I'm using pagination or not
in a page.
Steve: If pages stack vertical or horizontal doesn't matter, you always
jump by one page anyway.
Alex: 'Overflow-x: scroll' will give horiz. scrolling by column.
Alex: Interestign question is what happens for 'overflow-y'.
Alex: All values are going to make sense.
Fantasai: If I set diff. values for 'overflow' should not make difference
for conceptual model of the layout.
Alex: Yes, columns are always laid out the same.
Fantasai: 'overflow-mode: paginate' would give paginated, Now imagine
a background. The effect will be different based on layout.
dbaron: If you want paged, why would you want a different background?
Fantasai draws many columns side by side with three of them in viewport.
Fantasai: If I paginate that, the next three columns go below the viewport.
Fantasai: Without a background, it wouldn't make a difference: seeing
the first 3 or the 2nd three columns is the same.
dbaron: Aren't you confusing bg on elt that creates the columns and bg
on things inside the columns.
dbaron: That viewport is the elt and it has its bg.
Peter: So printing to a printer should effective switch to
'oveflowmode: paginate'?
Steve: Maybe some issues with margins then?
Steve: We ought to take 'paginate' bahavior from behavior in printed media.
Not maybe exactly the same, but quite similar.
Håkon: Should we add 'overflow-mode: paginate' to Marquee?
Fantasai: Better a new module.
Fantasai: Leave multicol as it is, add new module later.
Alex: If you have just overflow like this, you can print it and see
everything. If it adds columns on the right, you cannot see all
of them.
Alex: In vertical text, a horizontal scrollbar that acts to move you
to the next page may be surprising.
ScribeNick: fantasai
Howcome: it seems the conclusion is we don't make a changeto the multicol
spec now
Alex: This is interesting behavior, if you left it in wd for another
year... :)
Alex: you can make a prototype of the pagination behavior by setting
overflow:hidden and using scrolling APIs
...
Alex: I can easily see pagination widget being scrollbar with additional
widgets
Alex: even in page-reading mode, having a visual indication of where
you are in the document is also useful
Steve: one thing to look at is the way pdfs get handled
Alex: pagination-mode thumnails
Howcome: I think I'm happy with this. I'll try to resolve the other
comments to progress the draft
Sylvain: what are offset-width/height DOM properties in multicol mode?
dbaron: You have these problems with inline elements anyway
dbaron: And there are better apis for getting this info
ScribeNick: Bert
Håkon (to Alex): Are you implementing?
Alex: We're going to.
Håkon: We ought to, too.
Fantasai: With a fixed 'height' you're going to gety overflow, on some side.
Fantasai: With 'column-length' the height grows to whatever it needs.
Håkon: Can use 'column-gap' also between the pages.
Steve: No, they are diff. gaps.
<fantasai> or column-row-gap
<fantasai> column-group-gap?
Steve: Column length seems to introduc a whole set of new prblems.
General paginate seems a better solution.
Peter: Can be in future version of multicol.
Steve: Got an elt that is pagainated, inside a DIV with a border. Where
is the border?
Peter: Just like overflow: scroll, i.e., border goes on outside.
Fantasai: border aroudn the div has nothing to with the overflow. Not
influenced.
Steve: Doesn't look to me like overflow, why doesn't it extend the parent?
Håkon: We could consider it as something else as overflow. But we do
currently consider scroll a part of overflow.
Steve: Paging is just a way of layout, not overflow.
Steve: If I specify size of page, then it is overflow. But if I have
some other way to set height, like column-length, then it's not
overflow.
Peter: Right, that does not set the height of the elt, so is not overflow.
Alex: I see advantage of using overflow for pagination. Then you avoid
defining their interaction.
Peter: to paginate assumes a constrained container.
Steve: Pagination is content that doesn't fit on the page, but it's not
overflow.
Peter: In my old product, we made pagination as a form of overflow.
Håkon: Why on overflow-mode, why not on overflow itself?
Fantasai: You need overflow: hidden independently.
Fantasai: The scrolling mode is independent from whether it overflows at all.
Håkon: Actually, the name is 'overflow-style', not -mode.
Håkon: values are currently marquee and others.
Håkon: Seems not the right comapny for 'paginate'
BREAK
ScribeNick: jdaggett
Hakon: still on multi-column
<plinss_> http://lists.w3.org/Archives/Member/w3c-css-wg/2007JulSep/0177.html
fantasai draws a pretty picture
vertical document with horiz block
horiz block has no constraint b/c auto
what happens when set max-context from box module on horiz block
Hakon: whether multi-column or not, width doesn't change
SteveZ: is column-width inherited?
Hakon: no
SteveZ: i'm confused
discussion of what happens to multi-column in rotated text
SteveZ: issue is if you do a 90deg rotation
SteveZ: no longer have a fixed width
SteveZ: if window height becomes the constraint
fantasai: pagination also an issue
SteveZ: that doesn't depend on columns
Alex and fantasai discussing this
when does content get pushed to another page
Hakon: spec doesn't specify where page break occurs
Alex: lots of other pagination issues other than this
* CWilso thinks for the sake of those not in the room, all art should be
required to be drawn in ASCII art in IRC. :)
* jdaggett_ likes this idea...
* CWilso well you're scribing... :)
* jdaggett_ sorry, too much dessert at lunch...
* glazou agrees but notes it's an implementation issue : my IRC should
have a drawing tool included and a builtin converter to ascii art
more discussion of page breaking in multi-column veritcal text
SteveZ: page breaks are allowed on column boundaries but shouldn't occur
between columns
Hakon: we don't define a lot of those cases
Alex: i'm really uncomfortable with spiltting columns across pages
Alex describes image page breaking behavior
<fantasai> http://lists.w3.org/Archives/Public/www-style/2007Nov/0112.html
Hakon: unsure what to put into draft
SteveZ: call out there is an issue with vertical text
SteveZ thinking while talking
fantasai: if gap between pages is parallel to column, don't break in
middle of column
fantasai: don't break individual lines of content
discussion of where this belongs
Hakon: we should rely on generic rules
fantasai looks things up
fantasai: rules already in css 2.1
dbaron: says about both directions?
fantasai: says don't break line boxes
searching through section 13.3.3 of css 2.1
under "allowed page breaks"
fantasai: other question is can you alter column widths?
Hakon: are we happy happy happy?
discussion of which rules apply when
Alex: available height not being a condenser
SteveZ: is there a min column width
more pretty pictures from fantasai
SteveZ: do we shrink column widths
?
fantasai: the rules that handle increased column-width based on containing
block
Hakon: pseudo-algorithm addresses this case
Hakon: with the available width
section 4.4 of multi col spec
<fantasai> might need to define available width to also consider available
width on the page when paginating in that direction
Hakon: so this solves the issue?
Border Parts
------------
Hakon: next, border parts
generated content for paged media spec
Hakon explains example XXXV
bert makes a very funny face
Hakon: this is very very cool
Hakon: needed for footnotes
Hakon: very intuitive
Hakon: way to define dash above footnotes
Alex mentions alternatives
dbaron: the on-off distinction doesn't work
general unhappiness to which Hakon responds "it's very, very easy"
Hakon: auto means stretch to the available space
Hakon: could also use flex unit
fantasai drawing pictures again in the corner
* jdaggett_ not very pretty ones...
dbaron thinks about other options
SteveZ: the on-off stuff has been used in graphics for dashed line
SteveZ: propose a specific footnote thingy
footnote separator
SteveZ: leaders might also use on-off things
glazou: with css animation we can do crazy stuff
bert: footnotes that move around the page!
peter: moving borders are common
<glazou> CSS Animations + howcome's border-parts = rotating border parts !!!
<fantasai> I propose border-length: <length>{1,2} &&
[ center | left | right | corners ]?
SteveZ: how about a pattern
peter: we had similar things with grids
<fantasai> border-length: 3em left;
glazou: fantasai's proposal is less inuitive
<fantasai> border-segment: 3em left;
<fantasai> border-top: solid red 2px;
<Alexmog> .footnotes:before { display:block; height:0; width:3em;
border-top:solid black 1px; }
glazou: how to specify border patterns
SteveZ: might also want just borders on two corners
SteveZ: can do this with script...
Hakon: this is about geometry not content
Alex thinks this is about content
generated content
Alex: way more interesting generated content in css3
Hakon concerned about how to do footnotes
SteveZ: borders vs. separators
fantasai: this format is just weird
Hakon: it's trivial
fantasai: as a web designer where would i get the idea that i could do this
fantasai: I want a 50% border across the top and bottom of my blockquote
fantasai: you want to make me write border-parts-top: 0 auto 50% auto; ?
dbaron: how does it interact with border-image?
Hakon: this is a mask
Hakon: it's just a mask
SteveZ: can there be a repeat with this?
Hakon: some folks on the list wanted dashes
Hakon and SteveZ discussing patterns
something like
* glazou is developing a strong allergy to the projected syntax
* Bert wondering why we dont go to immediately to 'border: 100 100 L
300 100 L 200 300 z' (cf. SVG)
border-parts: pattern(10px 20px auto, repeat)
jdaggett: what does svg use for pattern syntax?
peter: border-parts: 10px repeat(10px 20px) 20px;
fantasai: this is all ridiculous
peter: equivalent to how to specify grid lines
* Bert : or we could use Metafont: pickup widepen; draw z1..z2--z3;
* jdaggett_ hmm how would postscript do this
fantasai: I'm happy with that releat() syntax if that's what you want to
do, but I think this is all ridiculous
Alex: is there reasonable consensus that this is insane?
Hakon: this is simple euclidaen geometry
Hakon: some people have suggested flex units
Hakon: some people might be confused by the use of auto
checking values and units spec
Hakon looking at gd unit
Hakon: we should add fr
SteveZ: yuk
Hakon: there's many worse things in css
Alex: what happens when fr is in repeat?
* CWilso jdagget: WWPSD?
* jdaggett_ heh
What Would Patrick Swayze Do
<CWilso> that too.
* glazou is too old, he used to say "what would McGyver do?"
discussion of what to do with repeat
peter: what happens if repeat has an odd number
fantasai: need a way to say "this many times the border width"
* MoZ propose a new unit "bw"
Hakon: so i'll just write up this, shall i?
general snickers
<glazou> MoZ: make it "btw" and I buy it !-)
Hakon: it's just an editors draft
buying and selling of issues takes place
Hakon: i see an issue with repeat
* MoZ would have prefered "bmw"...
<glazou> lol
Hakon: you don't know many how many times you repeat
bert remains very, very quiet
* glazou finds amazing that Håkon is proposing a feature that will
eventually lead to web pages blinking more than with the blink tag :-)
* sylvaing cannot wait for border part collapsing
* Bert thinks fr should be defined as repeat(epsilon) where epsilon is a
small value.
<glazou> sylvaing: rotfl
* Bert knows what designers want next: 'border-parts: repeat(random random)'
general discussion of how repeat works
SteveZ: difficulty with specifying dash-dot sequences
Hakon: any units we should add?
Hakon: bw?
Alex: don't really need it
dbaron: don't have outline width, ow possible
<dbaron> I think you can stop minuting at this point... :-)
peter: issue beaten to death
Alex: barcodes with this...
Hakon: grammar question
calc(border-width-1em)
hows does this parse
dbaron: one ident token
Parsing calc()
--------------
discussion of parsing of calc
bert: insert spaces
Hakon: should we say something about this in values and units
ScribeNick: dbaron
(discussion about :nth-child() argument syntax)
Peter: We decided the syntax for the argument there yesterday; it looks a
lot like an expression.
* fantasai thought we resolved that yesterday
Peter: At some point we'll need expression parsing rules, which aren't
compatible with general CSS parsing rules.
Steve: Which means the tokenizer is in trouble.
Peter: "1px-7"
Bert: You have to put spaces. That's normal.
Bert: You can't say background-position: 10px7px
(some examples that went by too fast)
(Haakon shows the grammar for calc() in the css3-values draft)
Peter: You can have "7px + -4px"
Haakon: So these spaces here are significant?
Bert: Some of them are.
Peter: Can you nest calc()?
Bert: no
Bert: Seems kind of pointless.
Peter: It's unintuitive to a user to require spaces around - but not
around / or *.
fantasai: It does match the order of operations :)
Peter: Should require space around all arithmetic operators.
dbaron: Maybe just + and -?
Peter: No, all
dbaron: ok
fantasai: Does that require changing the tokenization?
Various: no
Peter: add parens to change order of ops?
Various: They're already there.
dbaron: Any additional requirement for spaces around paretheses?
Peter: no
fantasai: Do we want % rather than mod now that we have spaces?
Peter: No, % sign is too geeky.
Haakon: no
RESOLVED: spaces around arithmetic operators in calc(), not required
/by/ parentheses, but may be required outside parens due
to operators)
GCPM & Misc
-----------
Haakon: We're likely to have 2 implementations of a fair number of
these items. This spec is a clearinghouse for many things
that possibly could go elsewhere.
Haakon: But it seems reasonable to have an advanced printing features
draft. These seem likely to be implemented mainly by batch
processors.
Haakon: How do people feel about 60% of this spec going forward under
this name?
Alex: Can it be separated into pieces that can be implemented separately?
Haakon: The border thing could go in the border module.
fantasai: No standard for CMYK.
fantasai: I think we want new counter styles in the lists module.
fantasai: That means lists module requires an owner.
Haakon: I would actually remove a lot of the lists.
Haakon: And then I would define them using the symbols() syntax.
fantasai: A lot of the numbering styles don't follow that pattern.
Haakon: You're putting overhead on the implementations if you have all
those lists.
Alex: I also have some concern about footnotes. This definition is
very general; it's not necessarily how we'll do it if we
eventually implement footnotes.
Alex: Maybe footnotes could be a separate spec?
Haakon: That has overhead.
Haakon: I added this section about "Footnote magic"
Bert: Leaders and hyphenation don't belong here.
Hakon: Generated content?
Alex: Can it become paged media level 4?
fantasai: Modules can progress independently.
(discussion of spec progress, and lack thereof)
Peter: I think we're done for the day.
* fantasai wonders if we can resolve the background shorthand issue
and publish CSS3 Backgrounds and Borders as Last Call
Haakon: TOCs, and the 'prototype*' properties
Haakon: Generate content and insert into glossary, TOC, ...
Daniel: S-T-T-What?
Bert: What locale for sorting?
Haakon: I'm looking for somebody to do an implementation in perl or
something to see if it works.
Haakon: This is among the parts I'd chop off if we were to progress?
Ben Millard: I've studied how authors mark up TOCs in HTML currently...
some use OL, some use UL, some use P/BR with s, etc.
Authors aren't clear on markup, so could be positive feeling
on how to do from CSS.
<glazou> STTS RULEZ !!!!!
fantasai: OL is the right markup, styling not good enough.
dbaron: We need ::marker
(Hixie enters.)
Haakon: Can you fix the z-index issue?
15:55 * Bert wonders why HTML5 doesn't add <toc><li>...</toc> elements...
Peter: OK, z-index first thing tomorrow, then.
Haakon: I have another issue about the page counter.
<glazou> Bert: hey, that would be a too simple and intuitive solution :-)
dbaron: We also need counters work for the HTML5 header algorithm,
counter-set that doesn't create a new scope might solve it.
fantasai: We can probably do an LC of backgrounds & borders this year.
Received on Wednesday, 5 November 2008 03:50:33 UTC