W3C home > Mailing lists > Public > www-style@w3.org > February 2012

Minutes and Resolutions Paris F2F 2012-02-07 Tue Morning I: Regions Issues, Nested Style Rules

From: fantasai <fantasai.lists@inkedblade.net>
Date: Sun, 12 Feb 2012 01:07:53 +0100
Message-ID: <4F3702D9.9020506@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>

   - 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 ======

    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)

    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

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
   alexmog: I'd like to discuss issues in the regions spec.
   <tantek> the Microsoft implementation of regions is -ms- prefixed
   <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
   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

   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
   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...)

   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
   <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

   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
   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.
   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.)
   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


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
   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
   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 &amp;
   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
   (discussion about how this would be the same as the current server side
   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

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:10 UTC