[CSSWG] Minutes and Resolutions Paris F2F 2012-02-06 Monday Afternoon: Functional Notation, Values and Units, Regions Scope

Functional Notation

   RESOLVED: adopt the principles in http://wiki.csswg.org/ideas/functional-notation
   RESOLVED: adopt the proposed changes to exclusions in
             http://wiki.csswg.org/ideas/functional-notation except
             for the suggestion to unify rect() and rectangle()

Values and Units LC

   No known open issues other than attr() syntax; plan to go to LC after that
   is resolved.

Regions Scope

   Long discussion on Regions spec, scope of the spec, whether it's useful
   without a spec that defines templates or pseudo-elements or suchlike.

====== Full minutes below ======

Functional notation
ScribeNick: florian

   <fantasai> http://wiki.csswg.org/ideas/functional-notation
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Jan/0933.html
   fantasai: Tab and I have reviewed functional notation through all
             specs to try and see what can be aligned
   fantasai: principles: comma is the lowest priority
   fantasai: if a value is optional, you can leave it out in functional
             syntax just as in the rest of css
   Tab: Inside a function, things should be just like they are on any
   Håkon: we created functional notation to have ordering
   Tab: no, it was created to have grouping
   Tab: css already has ordering. The only thing functional notation
        gives you is grouping
   Håkon: but generally, ordering is not expected,
   howcome: in functional notation, commas should separated ordered
             parameters, just like they do in other languages
   howcome: the proposal makes some sense, but the cost of changing
            is too high compared to the benefit
   tab: most properties try to have arguments that can be reordered,
        unless that gives some ambiguity
   tab: functions should do the same, but currently, they don't
   fantasai: allowing for optionality also makes it possible to extend
             functionality later
   Steve: with a naïve understanding of functions, I expect ordering
   florain: these are not functions
   glazou: people will still see them as such
   howcome: don't change the meaning of commas
   fantasai: let's look at some examples
   <sgalineau> I think the combination of CSS2.1 precedent and average
               JS programmer habit creates an expectation of commas a
               separators between each value
   fantasai: see the wiki for examples
   <fantasai> http://wiki.csswg.org/ideas/functional-notation
   dbaron: it would have been ok to change a few years ago, but not now
   dbaron: we should push transforms 3 as it is, and introduce a new
           syntax in a later level
   *: general agreement
   howcome: how are they done in Fortran?

   sylvian: are users going to remember this?
   florian: they do for regular properties
   tab: the benefits are reordering and optionality
   tantek: did we ever get stuck due to the lack of reordering or
   tab: on gradients
   dbaron: I'm not yet comfortable using the word "fixed" for gradients
   <sgalineau> the issue is not whether the new notation helps feature
               design, but whether it may confuse feature users
   jdagget: of the things on this wiki, I don't see any that benefit
            from the extensibility argument
   plinss: you don't know what you want to extend until you try to
   glazou: translate(x,y) to translate(x y) is useless
   fantasai: it is for consistency with other places that have an x
             and a y
   <fantasai> background-position, background-size
   plinss: even if some case don't benefit individually, consistency
           is good
   tab: we didn't suggest any change to gcpm because everything was
        either ok or consistent with some established thing
   fantasai reads the proposal for animations (steps and cubic-bezier)
   fantasai: for steps() we suggest removing the comma and making the
             arguments reorderable,as there's no reason not to
   fantasai: For cubic-bezier() you see why it's good to drop commas
             between x-y pairs. It looks like it takes four numbers.
             It actually takes two points. Using spaces between x-y
             makes that more obvious and understandable.
   tab: polygons would also be nicer as a list of points (pairs of
        numbers) than a list of numbers where the pairing is implied
   <dbaron> So how many browser implementations of cubic-bezier() do
            we have now?  4, right?
   florian: let's not break support for things that are interoperably
            implemented, even if they are currently prefixed
   glazou: does any tool support this syntax already?
   tab: no, it is a new proposal
   plinss: on matrices, commas, spaces, whatever doesn't really matter
   * dbaron wonders if we should also allow the function name to
            optionally be spelled as cubic-bézier() :-)
   fantasai: if we want to make commas optionals, we need to do it now,
             otherwise people won't ever use it

   plinss: I don't want to hold specs due to this
   plinss: as a general principle, as soon as we have experimental
           implementations, it should be the focus of the wg to drive
           that to rec asap
   tab: there are a few ones that haven't been implemented yet
   fantasai: We suggest to merge the rectangle notation with the rect
             notation in exclusions
   <smfr> css2 rect: http://www.w3.org/TR/CSS2/visufx.html#clipping
   <smfr> exclusions rectangle:
   discussion of rect()'s craziness
   Tab: Ok, scratch that.
   vincent: overall, we are ok with the changes suggested for exclusions
   <dbaron> http://www.w3.org/TR/WD-positioning-970131
   tab: let's drop the suggestion to merge with rect

   fantasai: for values and units, in attr, we want to drop the comma
             between the name and the type, because they are paired,
             and keep the comma that separates that from the fallback
   fantasai: also good for extensibility, especially if the fallback
             value can contain commas
   * Bert considering other syntaxes... attr-url(src), attr-length(border, 0)...

   howcome: this would break prince's implementation
   howcome: put the type outside the parenthesis
    Bert: should put the type in the function name (is that what howcome

Scribe: dbaron

   Tab, Peter: would like to get some resolutions
   Tab: can we resolved that exclusions, attr(), and the steps()
        function from transitions/animations can change?
   dbaron: Gecko has implemented steps() since Firefox 5
   smfr: I think WebKit would end up supporting both syntaxes for steps()
   howcome: So you dropped the proposal to use 'as' as a keyword?
   howcome: This would break target-counter() which has 2 implementations,
            which has href inside ...?...
   howcome: we'd be breaking 2 implementatiosn
   howcome: It's what you use to generate "see page 83"
   fantasai: and these implementations are unprefixed?
   howcome: They're not prefixed -- functions inside the content()
            property.  Prince and antennahouse.
   howcome: I think it's the same as the other argument that we're
            breaking implementations, so I would object to the change.
   TabAtkins: previously when printing devices have implemented
              something unprefixed we've let them alias -- we care
              about the Web more than print implementations
   howcome, peterl: I disagree.
   peterl: Over half of what comes out of HP printers is Web pages,
           mostly from browsers.
   Peterl: We do care about offline renderers.
   peterl: However, I'm fine with breaking people who shipped things
           unprefixed before they should have.
   florian: We should still consider them before breaking them.
   peterl: understood
   peterl: Can't distinguish name,type,default from name,default,moredefault
   howcome: ?
   Tab: should just specify attr(href url)
   TabAtkins: I think we should make this change.
   peterl: ambiguous
   TabAtkins: could say "if fallback value is the token 'url'" ... ?
   howcome: We're not helping adaptation with implementors if we come
            in after 5 years and make arbitrary changes for little
   Tantek: If it has 2 implementations, why isn't the spec in CR?
   howcome: lack of implementations
   Tantek: then what's the problem?
   howcome: non-browser implementations
   howcome: values & units should be the last css3 spec out
   dbaron: I think we all disagree with you on that

   TabAtkins: Summary -
   TabAtkins: exclusions, ignore the crazy rect()/rectangle() suggestion
   TabAtkins: make changes for exclusions
   TabAtkins: make changes for attr()
   TabAtkins: maybe make changes for steps()
   TabAtkins: for the rest, let things progress to CR and maybe make
              a compatible change in level 4
   ?: When are we doing level 4 of transforms?
   fantasai: if the concern is impls you could put it in the spec and
             mark it at risk
   peterl: I'm happy with the proposed resolution but concern with
           the attr() thing
   TabAtkins: I believe implementations could support both attr()
              without breaking
   peterl: I think we should leave attr() for discussion
   peterl: I think we should also resolve to accept the principles
   peterl: And adapt them to old properties as we can and as it makes
   RESOLVED: adopt the principles in http://wiki.csswg.org/ideas/functional-notation
   RESOLVED: adopt the proposed changes to exclusions in
             http://wiki.csswg.org/ideas/functional-notation except
             for the part on unifying rect() and rectangle()
   ACTION Tab to investigate if we can change functional notation in
              steps() in line with http://wiki.csswg.org/ideas/functional-notation
   <trackbot> Created ACTION-419
   ACTION Tab to work with howcome and AntennaHouse to see if we can
              change attr() as suggested in
   <trackbot> Created ACTION-420

Values and Units Issues before LC
Scribe: TabAtkins

   TabAtkins: fantasai and I have only the one issue about attr()
   [no one else has any issues, apparently]
   plinss: Let's discuss the attr() issue now, see if we can resolve
           the legacy issues.
   <fantasai> target-counter(href, ...) instead of target-counter(attr(href, url), ...)
   fantasai: I think we need to discuss this one on the mailing list.

   plinss: Anyone object to going to LC after the attr() issue?
   sylvaing: I think there was an issue about calc() and background-position.
   TabAtkins: fantasai pointed out that if you lawyer the spec correctly,
              it's not a problem at all.
   fantasai: I can add an example with an explanation.
   ACTION fantasai: Add example of background-position with calc()
   <trackbot> Created ACTION-421
   plinss: We'll come back to attr() on next telcon.
   <dbaron> I'm not crazy about the intro to css3-values section 8
            (functional notations) using url() as an example of a
   <dbaron> given how special url() is

Regions Scope

   vhardy: There's been feedback on region scope.
   vhardy: On our end we'd like to present our working assumptions.
   vhardy: And, per a request from Håkon, what we think the bigger
           picture is and how that would work in the larger group.
   vhardy: So, to recap would take about 20 minutes.
   Rossen: [shows some slides]
   Rossen: [recaps CSS regions]
   Rossen: An Element that is able to receive and output content from
           other elements is a Named Flow.
   Rossen: Fragmenter - boxes produced by a region can fragment their
   fantasai: Page boxes, column boxes, regions are all fragmenters.
   fantasai: Better name suggestions welcome.

   Rossen: In regions it can be controlled with 'region-break'
   Rossen: [shows the canon region example, highlighting the boxes
           containing text]
   Rossen: There is region styling on the first region, changing the
   Rossen: Out of scope of regions is the breaking rules - specified
           in CSS3 Fragmentation.
   Rossen: That spec should cover *all* breaking rules - pages,
           columns, regions, and future stuff.
   Rossen: Finally, out-of-scope is auto-generation, conditional-generation,
           or grouping of regions.  This should be covered by a Page
           Templates module.
   florian: Defining them in a separate document seems fine to me, as
            long as we do it simultaneously and know aproximately what
            we're doing.

   Bert: When you say Fragmention, is that a new name for Paged Media?
   fantasai: No, new spec.  This is specifically about breaking.
             Paged Media is now just about the page boxes themselves.
   Bert: So the break properties, and widows and orphans. Anything more?
   Rossen: Some text about variable-width containers, etc., but that's
           about it.

   vhardy: [shows some different slides]
   vhardy: Here's context about why we brought them to the group.
   vhardy: There were two features we couldnt script our way around.
   vhardy: Our people tried to have multiple aspect ratios, and multiple
           form factors.
   vhardy: [shows a slide of a fairly large screen with three columns
           of text, some pull-quotes]
   vhardy: In this example, the content uses three templates.
   vhardy: But on smaller screens, you have substantially different
   vhardy: There's also justification for page templates being conditional -
           based on the content, you may use different templates.
   vhardy: The regions offers the way of pulling content into the template.
   vhardy: So one approach that could work here is GCPM - use paged
           overflow and media queries to swap out templates.
   vhardy: The @page rule would contain a template and specify how areas
           of the template are regions.
   vhardy: In our experience, trying to do magazine content, there's
           reason to do conditional content.
   vhardy: For exapmle, if a page's content has a pull-quote region,
           use the template meant for pull-quotes.
   vhardy: Further, one can leverage regions and pseudo-elements to
           control the flowing in th epage templates.
   vhardy: So the core notion is that you would use CSS (@page and pseudos)
          to define the templates, and use regions to pull content into them.
   vhardy: This is important, because the people asking us for these abilities
           want very precise control over how things are laid out.
   szilles: The WebApps group is also looking at templates in this context,
            and there's an opportunity for discussion.
   szilles: HTML-based templates, shadow DOM, etc.

   Bert: Two comments.
   Bert: Regarding ::slot(), I had resolved to put it directly after the @page
         token. This avoids mixing with @page styles, and also makes it look
         more like a selector.
   Bert: The other comment is looking at the "nth(2)", and wondering if this
         is what we wanted.
   Bert: I thought we had ideas about named pages.
   Bert: Another comment, XSL already has things like this.
   Bert: We should probably look at what they've done already.
   szilles: I think the main thing is what Vincent already hinted at -
            conditional choice pages.
   szilles: His example of small and large templates was primitive, but
            obviously useful.
   szilles: The XSL mechanism had extremely primitive questions you could ask.
   szilles: But in general you want to be able to see if the next page's
            content contains images, particular flows, etc., and select
            your template based on that.
   szilles: We don't need to get into specifics now, but the notion of
            conditioning based on content is important.
   vhardy: [shows some demos]
   vhardy: [first demo shows regions being created/destroyed dynamically
           based on the length of the content]
   vhardy: It uses the regions OM to tell when there is overflow/underflow so
           it can create/destroy "columns" and "pages" with script.
   vhardy: If we could do all this declaratively, it would be great.
   vhardy: [shows another demo]
   florian: I think this demo can be done with overflow:paged, too.
   howcome: [shows a similar demo using display:table and multicol to achieve
            a result similar to the english/french stuff.
   astearns: In the template example, different pages were split in different
             ways.  That seems incompatible.
   howcome: There may be changes needed, yes.
   howcome: I think if we can just agree on the general shape of CSS syntax
            for making region targets is good, so we don't need to have
            dummy elements.
   vhardy: We found that often you need to nest the containers needed for
           complex but realistic layouts.  That makes it hard to work with
   glazou: [talks about HTML-to-CSS templates]
   Bert: I think you are putting up a hack as a solution.
   glazou: I think they're using it because it's simple.
   fantasai: People are using those for actual HTML templates - that's the
             markup they want.

   howcome: There's a finite number of elements in the page.  You still are
            forced to use JS to create new elements as necessary.
   astearns: The idea is that regions are primitives.  They could be elements
             or pseudo-elements or what-have-you.
   astearns: We don't want to limit what Regions can be.
   astearns: We just want these primitive region concepts that can be used
             *now* with JS, and *soon* with page templates, etc.
   howcome: If a property can only be used in practice with JS, I think
            that's wrong.  CSS has always been able to create boxes as
           we need them.
   vhardy: I think it would be great to have slots and such.
   vhardy: We tried to push it far in the earlier proposals, but it got *ugly*.
   vhardy: For simple things, using ::slot() or similar with regions is great.
           For more complex things like Wired Magazine, HTML seems very good
           for setting this.
   vhardy: the way we script things currently is that we have a custom CSS
           syntax, and we parse that and then generate things in the DOM
           based on that.
   vhardy: If we had shadow DOM, or some way to use boxes without elements,
           we'd use that.
   florian: For all the examples you have, the most tricky ones may be
            complicated, but everything else is doable with existing stuff.

   alexmog: The purpose of this was just to introduce our ideas. We'll have
            future conversations about how to address templates and such.
   * dbaron can't follow this discussion at all
   * TabAtkins neither.
   alexmog: [some discussion I missed]
   florian: It seems to me that if you have a different solution, you'll
            always find some cases that you need your solution for.
   florian: But it seems that in *most* cases, you can solve them with
            simpler things.

   dbaron: AFAICT, you went through a presentation very quickly, not giving
           people a chance to comment, and now saying we have to move on
           without asking questions.
   alexmog: I'm trying to separate these conversations because...
   dbaron: What convos are you trying to separate?
   alexmog: I want to delay discussions on use-cases and solutions until a
            longer solution with Håkon about what is happening.
   alexmog: I would be happy to analyze specific use-cases now if we have
           time, to show that only Regions can solve those.
   alexmog: I think that preparing for that would be more productive with
            a small session first.
   alexmog: These use-cases are posted in the wiki.
   <tantek> URL?
   <Rossen> http://wiki.csswg.org/spec/page-view
   vhardy: We are trying to make progress on Regions, and what the spec
           covers or not is in question.
   <astearns> http://wiki.csswg.org/spec/css3-region-templates
   vhardy: So we need to see if we can address things like auto-height,
           tiling, etc., or if we need to go back further in the idea.
   dbaron: Okay, I heard that, and then it delved into very specific
           examples, and it wasn't clear how they connected.
   vhardy: One of the big questions that Håkon has asked is how you generate
           regions, how you paginate, etc., and so I tried to show that.
   sylvaing: At TPAC we said that certain things are out-of-scope of regions,
             and so the presentation showed that those out-of-scope things
             are needed for some of the questions being raised.
   <Bert> (So I think Regions is about:
           (1) given that there are regions on the canvas (created with a
               grid template or in some other way), we need a way to chain
               them together so content flows from one to the next;
           (2) given that there are regions, we want to assign style to
               them that overrides the style set on the elements whose
               content ends up in those regions.)
   howcome: but you need the page templates for evaluating regions.
   astearns: My take is that there are problems you can poke at with our
             examples, and with GCPM, but there's a need for both to have
             a primitive thing to flow content through.
   astearns: In multicol it's a column element.  Regions are a further
             abstraction - it's not a multicol, it's bare columns that
             can be put anywhere.
   astearns: It's the multicol layout scheme that isn't generic enough,
             so we needed to go further down and have simple, primitive
             flow-through boxes.
   howcome: In doing so, you lose the fundamental scalability of the web.
   howcome: Look at this example (the canon regions example).
   howcome: If the screen gets wider, you can't add another column to the right.
   Rossen: This is what page templates are going toward.
   howcome: But we haven't seen them! We can't evaluate a non-existing spec.
   alexmog: First, we'd like to work with you for a complete solution.
   alexmog: Second, regions as they are are following the same pattern as
            everything else in CSS.
   alexmog: Following existing typography tradition being described in a
   howcome: Right now we have multiple plans, and I think we should talk
            about just the declarative stuff right now.
   szilles: If you want declarative, why do you have an OM?
   howcome: It allows more functionality.  But it's not required to display
   howcome: What I fear is that IE will implement the script-centric approach
            and nothing else.
   alexmog: What you are suggesting does not yet address all the use-cases
            we've presented.
   howcome: I've been away for a bit, but I've answered many of them.
   howcome: Number one example of an exclusion is a pullquote that comes
            out of some text and goes between two columns.
   howcome: It can't be done in your approach.

   Tab: What is the point of this discussion? I don't want to minute random
   florian: The problem I see is that we're introducing various pieces that
            are meant to be combined, but we're not considering them together.
   florian: As long as we discuss them separately, we aren't dealing with it.
   alexmog: We know we disagree somewhat.  Can we move past that?
   howcome: We could if we agreed on the declarative approach.
   vhardy: On your end, Håkon, you take existing content and figure out how
           to paginate on multiple devices, as automated as possible, with
           as little knowledge as possible.
   vhardy: Where we're coming from is different - design houses that want
           precise control over content when it's paginated.
   TabAtkins: Within the context of epub, we explicitly rejected the
              "precise design" use-case as a thing for CSS to worry about.
              Why are we worrying about that in the context of Regions?
   szilles: Not precise control, but a design that will scale over a
            reasonable set of form factors, combined with media queries.
   florian: I agree, but I don't see how you go from there to "you need this
            type of regions"
   szilles: Some people believe that there aren't reasonable ways to use columns.
   florian: Using current columns, yes.
   szilles: I see columns as combining two things.  They do columns, and they
            do auto-generation.
   szilles: I think it's more powerful to separate those two things into
            building blocks.
   szilles: And use things like conditional page templates for auto-generation.
   howcome: That' s afine approach, but it doesn't need script.
   szilles: I don't think we know the set of templates or rules that we'll need
   vhardy: Multicol gives us a lot of the abilities we need, but with a single,
           particular layout solution, when we have use-cases for lots of
           different layouts.
   vhardy: If the last region is always overflow/auto-scroll/etc, there will
           always be a way to show the additional content.
   howcome: How does the content get onto the next page?
   alexmog: How it gets onto the next page is the next thing we need to write.
   florian: That's what we can't accept!
   fantasai: You need script to do something simple like fancy regions on page
             1, and then just regular columns on the rest.
   vhardy: There are different problems and concerns.
   vhardy: Regions is trying to be agnostic about the boxes it's flowing into.
           Anything that can take 'flow-from' is a region container.
   florian: The least-effort way of doing things doesn't get you what you want.
   macpherson: You *could* generate the rest with JS, or have it do automatically
               with columns.
   fantasai: Solutions like putting a bunch of extra <div>s that may or may
             not be sufficient isn't a good solution.
   macpherson: One problem is that we currently don't have good multicol
   macpherson: But CSS already doesn't solve this case.
   * glazou recommends leaving the implementors having a flow layout proposal
            on the table in one room, locking it, letting only one survivor leave
   fantasai: What we're saying is that the cases that should be easy to solve in
             CSS is still hard in Regions.
   fantasai: We're seeing part of a solution and being assured that the rest
             will come eventually, but right now the piece we know isn't
             capable of doing robust layout.
   vhardy: But regions aren't layout.
   fantasai: Agreed. But based on what we have right now, Regions makes it
             possible to create very *non-robust* layouts. And not possible to
             create robust layouts.
   howcome: If there's one thing we've learned, scripting isn't robust.
   macpherson: What's the problem with having the last thing be auto-sized?
   howcome: If that's the approach, I'm happy.  I just don't like the
            script-centric thing.
   sylvaing: without dom elements, you can't receive clicks, etc.
   antonp: The problem right now is that, based on what we have right now,
           it seems that scripts are required.
   antonp: Is the objection about a theoretical problem with regions right now,
           or practical issues?
   * fantasai thinks anton didn't get minuted quite right
   astearns: I think finding a good, complete solution can only be furthered
             by having the primitives right now, even if scripts are needed
             to use them *right now*.
   astearns: So get a set of functionality in place, and then extend it.
   florian: It seems that in the future we're pointing at the same needs.
            But what you proposed is that, on day 1, you can use tools to
            create great stuff on the kindle, but not on the web.  We're
            wanting to make sure that it scales better across the web/devices
            on day 1 as well.
   florian: Our ideas don't support quite as fancy stuff as yours on day 1,
            but they do handle better scaling on day 1.
   vhardy: We have a solution today which is fully scripted.
   vhardy: We feel that this isn't a good solution.
   vhardy: Even without regions.
   vhardy: If we don't do this, we'll stick with fully-scripted.
   vhardy: [shows example with the last region taking the rest of the content
           and scrolling]
   vhardy: If we had the last region be auto-height, it wouldn't need to be
           scrolled.  It could be multicol.
   howcome: It doesn't work today?
   vhardy: Not per spec.
   Bert: The assumption of regions is that somewhere else there is a way to
         make regions,and then you can style/position them later. It then
         defines how content flows between them.
   Bert: I'm predicting that once we know how to make regions, we'll know how
         to do these things, and they'll fall out.
   * fantasai agrees with Bert
   vhardy: I think that the automatic generation of boxes is useful, but not
           just for regions.  It can be used for more things.
   Tab: Afaict, layouts should only need Grid. What's missing?
   <glazou> ADJOURN

<glazou> jdaggett, dbaron, florian, vhardy : 119 people registered for wednesday evening at La Cantine
<jdaggett> glazou: wow!
<jdaggett> glazou: will there be enough air in the room?

Received on Tuesday, 7 February 2012 10:26:27 UTC