- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Sun, 12 Feb 2012 01:07:53 +0100
- To: "www-style@w3.org" <www-style@w3.org>
Regions
-------
- Discussed drafting page templates spec for next F2F
- RESOLVED: bug 15159 for adding use cases to Regions spec is closed
- Reviewed various issues in Regions draft.
Nesting Style Rules
-------------------
Discussed various issues with nested style rules proposal including:
- use of & is troublesome for embedding in <style>
- OM is insufficient, and editability is problematic
- mix of declarations and sub-rules is problematic
- need to distinguish that this is a proposal to the WG from one
vendor, not a WG draft
- invalidation rules could be improved
- prioritization wrt other modules; there are already too many
higher-priority items on the WG agenda for us to work on this now.
====== Full minutes below ======
Present:
Rossen Atanassov (Microsoft)
Tab Atkins (Google)
David Baron (Mozilla)
Bert Bos (W3C)
Tantek Çelik (Mozilla)
John Daggett (Mozilla)
fantasai Etemad (Mozilla)
Simon Fraser (Apple)
Sylvain Galineau (Microsoft)
Daniel Glazman (Disruptive Innovations)
Vincent Hardy (Adobe)
Koji Ishii (Invited Expert)
Håkon Wium Lie (Opera)
+ Chris Lilley (W3C)
Peter Linss (Hewlett-Packard)
Luke Macpherson (Google)
Alex Mogilevsky (Microsoft)
Anton Prowse (Invited Expert)
Florian Rivoal (Opera)
Alan Stearns (Adobe)
Steve Zilles (Adobe)
Observers:
Jet Villegas (Mozilla Corporation)
Tavmjong Bah (Inkscape)
<RRSAgent> logging to http://www.w3.org/2012/02/07-css-irc
Agenda: http://wiki.csswg.org/planning/paris-2012
Regions
-------
Scribe: Sylvain
howcome: I think we agreed we want to achieve modern magazine designs
howcome: we disagree how to reach that goal
howcome: I prefer a declarative approach
howcome: others prefer a hybrid approach that involves script
steve: I thought we came out of the discussion thinking that we needed
declarative as well as scripting
* fantasai agrees 100% with howcome and Bert on this topic and has
nothing more to say.
<successful re-enactment of yesterday's discussion>
tab: allowing the last region be auto-sized would help a lot
tab: being able to flow a region into a grid cell (which used to
exist with ::slot) would also help
tab: with those two combined, a large number of these layouts would
be possible
vincent: the first one is something we have as an issue.
vincent: we also talked about making multicol a region; in particular
make the last region a multicol
vincent: we'd also like to make a proposal for page templating
rossen: our goal is to present a page template at the next f2f which
would address basic region auto-generation needs
rossen: so this would allow us to go back to the regions spec now and
work on known issues
alexmog: I think we generally disagree on the order of implementation
howcome: my concern is that the first implementations coming out will
force the creation of dummy divs through script
alexmog: we only aim to enable implementation in this space and gather
feedback
alexmog: I'd like to discuss issues in the regions spec.
<tantek> the Microsoft implementation of regions is -ms- prefixed
right?
<sylvaing> tantek, yes
* ChrisL maybe we should all implement the microsoft solution, but
all with the -ms- prefix
howcome: i think a page template spec is necessary
howcome: regions and page templates should come together is necessary
vincent: I see it as a two step process. if we do allow regions to be
multicol elements I think it mixes well with your solution
vincent: this provides a progression that doesn't require scripting
tab: is there any reason why all regions couldn't be multicols?
vincent: no
alexmog: can we put region issues on the agenda?
howcome: sure, i just don't want to make a general decision on whether
this is the right way forward until we have visibility into
your general model
vincent: as a way forward we'll submit a page template, add support
for multicols and paged overflow
vincent: at the f2f we can show something that's much more complete
florian: that way we'll be able to compare complete solutions based
on use-cases
howcome: we should also look at Bert's use-cases
howcome: we need a set of use-cases to evaluate the various proposals
jdaggett: I think it would also be useful to share presentation
material like this on www-style in advance so as to gather
feedback from a wider group
<Bert> q+ to give example of what looking at a complete example can give
rossen: valid feedback, thank you
ACTION: vhardy Draft a page template proposal for the May f2f
<trackbot> Created ACTION-422
vhardy: Should I put it on dev.w3.org?
Bert: region styling using @-rule is different from pseudo-element
styling and creates inconsistencies
daniel: of course; we have things there that aren't even in the
charter; I won't entertain objections to that
vincent: there was feedback at the last meeting on the way we presented
issues and I wanted to start by showing how we dealt with that
vincent projects css3-regions ED
vincent: we're filing all the spec issues in Bugzilla
vincent: before then we only had issue markers in the spec
vincent: now all the issues in the spec link back to bugzilla, and
the short description is shown in the margin
vincent: this is done in a scripted manner and matches them with
the spec and appends them a report at the end of the spec.
it lets you know whether new issues are not marked in the
spec. this helps editing.
vincent: let me know how to make it more useful
<dbaron> I didn't follow what the buttons at the bottom were supposed
to do.
<ChrisL> inline bug links in the spec are very useful
<ChrisL> tools better in a subdirectory instead of littering the root
ACTION: vhardy Create a shared directory to post the bug helper script
and document it on the wiki
<trackbot> Created ACTION-423
vhardy: first bug was https://www.w3.org/Bugs/Public/show_bug.cgi?id=15159
to add use-cases
vhardy: we've done that
http://wiki.csswg.org/spec/css3-regions/regions-use-cases
howcome: in addition to the CSS and HTML, it'd be useful to see any
script that is needed to flow in more content
howcome: do you encourage others to add more to the wiki page?
vincent: yes
ACTION: vhardy make a generic use-case page linking to proposed
markup solutions
<trackbot> Created ACTION-424
RESOLVED: bug 15159 is closed
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15733
vincent: this is about creating regions declaratively
howcome: let's close it once there is a proposal
vincent: this will be solved in the template proposal
vincent: we'll update the bug to reference the pending action
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15131
vincent: originally the spec had a section on how regions integrated
with different layout systems since regions don't create
layout. this was taken out
vincent: then we explained how a region could be selected or created
but this was not to be covered in the spec
vincent: but we were left with this example and we were asked to
update it
vincent: the goal should be to indicate there is an overflow area
and that should be item 4 in Figure 1
vincent: the point of the example is to show there is a catch-all area
ACTION: vhardy Make item 4 a multicolumn overflow
<trackbot> Created ACTION-425
howcome: <creep-laugh type="evil">
vincent: Bug 15186 is about auto-generation and is to be revisited
with future proposals. Same for 15187.
<Bert> (The example of 15131 doesn't really add a layout-based
solution, does it? I still see empty HTML elements...)
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15811
alexmog: we are not proposing to flow content from external resources
at the moment
alexmog: providing flow from external resources could be out of scope,
or the Regions spec shouldn't restrict the origin of a resource
ChrisL: I don't think it should be out of scope since the alternative
would be to write script to pull in content
alexmog: out of scope may be the wrong term
alexmog: can regions assume that every element or node comes from
the same origin?
alexmog: I think it's useful to assume it but it is limiting
* Bert thinks flowing <iframe seamless data="foo.html"> into a chain
of regions would be cool...
dbaron: given the seamless iframes feature of HTLM5, I'm not sure
how much this matters
dbaron: if you assume you have seamless iframes then you don't need
features in CSS
<ChrisL> is there a benefit to assuming that all the nodes are in
the same document?
* Bert put suspects that <iframe> will be a rectangle, like other
replaced elements.
<ChrisL> alex: yes, you can determine element order
alexmog: but we want to allow indirection into a different document
without changing the style of this document
alexmog: seamless iframes does not have that option
alexmog: I have a options on the wiki but I am not yet ready to
commit to any of them
http://wiki.csswg.org/spec/css3-regions#issue-24creating-a-named-flow-from-external-resource
<dbaron> TabAtkins: there are security concerns with integrating
iframes and, e.g., determining the height of the contents,
without using the mechanisms in seamless iframes
alexmog: one option involves using an iframe element; another uses
a separate property; a third uses a flow rule. we can
discuss these but work remains to evaluate the solutions
as well as understand seamless iframes
tabatkins: this should be discussed on www-style as there are issues
with it
alexmog: the Regions spec should note that the content of a named
flow may come from another document
vincent: should we retitle the bug?
vincent: we can note in the spec that the current version assumes
the content comes from the same document pointing to an
issue to resolve it later
Bert: this is not really a Regions issue but a general question of
whether we can have replaced elements that are reflowing
vincent: how do we deal with this issue?
bert: put it on the agenda
ACTION: alexmog to rework 15811 as a general issue of replaced content
and flow
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15858
vincent: the spec identifies the ICB for elements in regions
vincent: the defintiion was modeled on the page spec which uses the
first page
vincent: based on use-cases involving a page preview we thought of
using the first region as the ICB for the flowed content
vincent: feedback has been that this may not be always useful, and
that the normal ICB should be used
vincent: we can also keep what we have
vincent: or we can provide a switch
alexmog: this is also relates to regions' interaction with stacking
contexts
alexmog: if you model regions based on columns then they're not
containing blocks for absolutely positoned elements
anton: it's difficult to understand when you'll want to position
within a region or within the wider document. a switch may
be too hard to understand
plinss: from past feedback, we may want to be able to declare
something to be a containing block
plinss: i like having a switch to control whether an element
positions relative to the ICB but it shouldn't be
region-specific. It should be in css3-break and apply to
pages and maybe columns
vincent: so regions should not discuss this at all
ACTION: vhardy to move the issue to css3-break and remove the text
from Regions
<trackbot> Created ACTION-426
Bert: I've found that the gr unit should be enough to position
objects independently of their containing block
steve: if you're simulating multicolumns or something like it,
you need a different mechanism
alexmog: you may want positioned elements in your flow to start
in a region and cover the next one, you don't want to be
constrained by your container or its stacking context.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15116
vincent: I don't have a proposal yet.
ACTION: vhardy to update region styling
<trackbot> Created ACTION-427
bert: there might potential confusion between styling the region itself
and styling on the elements that end up in a region.
<Bert> (If the div defines a grid and has a child p, then
'div::slot(a) {background: red}' sets a bg on the region,
while 'p::slot(a) {background: yellow}' sets a bg only on
the part of the p that ends up inside that region.)
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15828
vhardy: we were missing properties in the CSSOM
vhardy: we added a way to retrive flows by name and return a collection
of existing named flows
(previous two comments by vincent)
tabatkins: I'll suggest a different interface
<br/>
Nesting Style Rules
-------------------
Scribe: vhardy
<TabAtkins_> http://dev.w3.org/csswg/css3-hierarchies/
<glazou> http://dev.w3.org/csswg/css3-hierarchies/
daniel: i want to discuss this because people discovered the document
and started to discuss it as if it was a wg draft.
daniel: it is a modification of the grammar. Technically, it is not in
the charter.
daniel: it is about nesting rules and reconstructing the selector based
on the parent rule.
daniel: the goal is to simplify the selector of the children rules.
This has been requested for a long time.
daniel: I have a lot of issues and questions.
daniel: first the OM. Not enough. selectorText on the style rule is not
enough.
daniel: selectorText is not meaningful, you need to reconstruct looking
at the parent style rules.
tab: right now, there is only the nested selector. Would be more useful
if we provided the expanded the selector, including the parent
selectors.
peter: if you are going to change that, add an attribute to only get
the local selectorText.
daniel: there is a way to navigate the children rules from the parent
rule, but not from the children rules to the parent rules.
tab: we are following media queries.
daniel: you do not say so.
tab: we are going to say we follow the structure of the @media rules.
If something is missing, we will fix both of them.
daniel: I have a problem with example #5.
daniel: the third nested 'thing' have a rule followed by a declaration
followed by a rule. This is an issue in the OM, because the
declaration is stored in one 'thing' and nested rules are in
another. Order cannot be maintained.
tab: I agree you should put your properties first.
daniel: the order should be mandatory.
tab: seems fine.
florian: I noted that the nested things last rather than first works
better. That is where they should be if mandatory.
daniel: you are using the &. That could be an issue for embedded
stylesheets because of encoding rules.
tab: not a problem in HTML.
daniel: I do not like the & because there are people who will forget to
use &
daniel: I think we should discourage that. I think this is a problem.
tab: Ok, I'll look for a replacement.
daniel: editability is a problem. When an editor needs to add a style
rule, you can look for a style rule with the same selector.
With nesting, it is way more complicated. You need to look for
a nested style rules as well. It complexifies.
tab: if you have the full selector, does that simplify your work?
daniel: when you insert a rule, you have to look for all the rules that
have an effect in the cascade and modify them.
daniel: I understand this is an important request from the user community,
but I would like a clear issue created about editability.
daniel: for example, what will happen to legacy browsers.
tab: they will ignore the nested selectors.
daniel: will that be used?
tab: people love that feature.
jdaggett: for things where we have not really taken on a module, could
we have a clear marker, something that says this is a 'proposal',
not an editor draft.
tab: yes, that is fine.
jdaggett: the word "proposal" would be ok.
tab, others: ok.
steve: moving from proposal to ED is an action of the wg.
all: yes.
jdaggett: I think this is better to have it here than on someone's blog.
jdaggett: should be a proposal until the group takes it on.
chris: I did not quite understand the 'expand' the selector thing.
<glazou> http://dev.w3.org/csswg/css3-hierarchies/#nesting-selector
tab: yes, you have the entire selector.
chris: then it is duplicated.
tab: we are talking about selectorText in the OM, not in the stylesheet.
What is editable is still the short form.
<ChrisL> example 4
<ChrisL> div, p {
<ChrisL> & .keyword, & .constant {color: red;}
<ChrisL> }
<ChrisL> is same as
<ChrisL> div .keyword {color:red;}
<ChrisL> div .constant {color:red;}
<ChrisL> p .keyword {color:red;}
<ChrisL> p .constant {color:red;}
daniel: In example 4, I would like a change. The parent rule has a group
of selectors. The nested rule has a group of selector, if one of
the selectors is invalid, the whole is invalid. So use groups
in the expanded version of the example.
tab: changing the example right now.
daniel: I have a suggestion for editability.
daniel: if you set the selectorText, the implementation will need to match
with as many parent selectors as possible to compute part of the
selector only, and set that part of not. If it fails to compute
the parent selector, it will throw an error. This is required,
because the selectorText is writable.
jdaggett: one way to implement it, then we could do it a parse time only
thing.
(discussion about how this would be the same as the current server side
solutions).
jdaggett: but it would make it easier to manipulate.
daniel: I do not think this is something we can _not_ do.
dbaron: I am not happy about the selectorText expansion.
dbaron: it seems a bit lossy in that you might want the thing with the &,
it will be hard to get that.
daniel: the part with the & is the selectorText of the parent rule.
dbaron: no, the local part.
(all) we are introducing a way to get the local part.
dbaron: one advantage of making the new one expanded is that we can make
it read-only.
daniel: I do not have a strong opinion, either way.
daniel: I just need both for reading and output.
daniel: to compute the style, I need both.
daniel: for writing I only need the local part.
daniel: with that, I think editors can work with such a specification,
it is doable.
daniel: this said, the question is, do we want to work on this?
daniel: do we have CSS grammar in the charter for the next 3 years.
tab: we have other specs, that will modify the grammar or tweak it.
tab: CSS conditionals will do that for example.
daniel: section 2 of the charter says that CSS syntax is discontinued.
chris: this just means that draft is not further developed.
daniel: if we want to work on that, we have to find a landing spot in
the existing charter deliverables or extend the charter.
chris: or we can fit in the existing charter.
chris: syntax is in the scope section, so we are fine.
daniel: I needed to check that.
jdaggett: the bigger question is the priority.
jdaggett: it is possibly disruptive. There are a lot of things to work out.
daniel: this is the kind of item that the author community is looking for.
tab: error recovery rules are working nicely here.
jdagget: this has a non trivial cost. We already have a lot that we need
to get done.
chris: yes, we have a priority list already.
chris: the important question is the relative priority.
peter: is there interest from implementors to implement this.
peter: if there is only one implementor, then we will not get to REC.
florian: from an Opera point of view, I can easily see how people want that,
but it is not at the top of our priority list.
vhardy: we think this is an important feature for web authors.
sylvain: no plans right now.
dbaron: there is a bunch of other things that are higher priorities.
sylvain: selectors 4 is more important.
daniel: I think it is clear there will not be commitment from the wg members
to work on this right now.
peter: do we want to keep this on the shelve as a proposal or do we take it
as a WD?
jdagget: I think we should keep it as a proposal and ask Tab to mark it as
a proposal.
vhardy: what are the more important things?
ACTION: Tab to mark the nested selector spec. as a proposal.
<trackbot> Created ACTION-428
vhardy: from the feedback we get, nested selectors, mixins and variables are
really important.
Received on Sunday, 12 February 2012 00:08:24 UTC