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

[CSSWG] Minutes F2F 2008-10-20

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 04 Nov 2008 19:49:12 -0800
Message-ID: <491117B8.1040904@inkedblade.net>
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 &nbsp;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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:55:16 GMT