- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 07 Feb 2012 11:23:16 +0100
- To: "www-style@w3.org" <www-style@w3.org>
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
property
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
optionality?
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:
http://dev.w3.org/csswg/css3-exclusions/#shapes-from-svg-syntax
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
meant?)
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
purpose.
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
sense.
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
http://wiki.csswg.org/ideas/functional-notation
<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
function
<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
content.
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
font-size.
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
templates.
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
pseudos.
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
language.
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
things.
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
meanderings.
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
yet.
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
integration.
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