[CSSWG] Minutes and Resolutions TPAC 2011-10-30 Sunday Morning: Issue Tracking, Regions

Unless you're correcting the minutes,
*Please respond by starting a new thread with an appropriate subject line.*

Issue Tracking
--------------

   Discussed how certain editors are not tracking or responding to issues
   on their specs and other general issue-tracking issues.
   RESOLVED: Each module must have one publicly-accessible, CSSWG-editable
             way of tracking issues.
   RESOLVED: Add link to issues list from spec header
   RESOLVED: use one of bugzilla, wiki, tracker or inline to track issues.


CSS Regions
-----------

   howcome raised issue of auto-generation of regions in order to show
   overflowing (and thus currently invisible) content. Bert pointed at
   a feature in Template Layout that does this
     http://dev.w3.org/csswg/css3-layout/#repeating-templates

   General consensus that multi-column elements should be allowed to be
   regions; Alex and Vincent to propose text.
   http://wiki.csswg.org/spec/css3-regions#issue-12should-we-allow-multi-column-elements-to-be-regions

   Discussion of special behavior of <iframe> in Regions; agreement that
   it should behave just like any other element, and the use case for
   seamless inclusions should be addressed some other way.
   http://wiki.csswg.org/spec/css3-regions#issue-19special-behavior-of-iframe-flow

   RESOLVED: regionLayoutUpdate is an asynchronous event
   http://wiki.csswg.org/spec/css3-regions#issue-10should-the-regionlayoutupdate-event-by-sync-or-async

   RESOLVED: close open issue on whether flow-from turns an element
            into a region, reopen if needed later
   http://wiki.csswg.org/spec/css3-regions?&#issue-18interplay-of-flow-from-and-content

   RESOLVED: If 'content' computes to 'normal', then the element takes the flow
   http://wiki.csswg.org/spec/css3-regions#issue-22content-vs-flow-from-precedence

   Discussion of which properties apply to region pseudo-elements.

   RESOLVED: publish regions and template if there are no objections in 2 weeks

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

http://www.w3.org/2011/10/30-css-irc
http://krijnhoetmer.nl/irc-logs/css/20111030#l-60
http://krijnhoetmer.nl/irc-logs/css/20111031

Present:
   Rossen Atanassov (Microsoft)
   Tab Atkins (Google)
   David Baron (Mozilla)
   Bert Bos (W3C)
   Tantek Çelik (Mozilla)
   John Daggett (Mozilla)
   Arron Eicholz (Microsoft)
   Elika Etemad (Mozilla)
   Sylvain Galineau (Microsoft)
   Daniel Glazman (Disruptive Innovations)
   Arno Gourdol (Adobe)
   Vincent Hardy (Adobe)
   Molly Holzschlag (Invited Expert)
   Koji Ishii (Invited Expert)
   John Jansen (Microsoft)
   Brad Kemper (Invited Expert)
   Håkon Wium Lie (Opera)
   Chris Lilley (W3C)
   Peter Linss (Opera)
   Luke McPherson (Google)
   Mark Silverman (Adobe)
   Alan Stearns (Adobe)
   Shane Stevens (Google)
   Deepa Subramanian (Adobe)
   Steve Zilles (Adobe)

<RRSAgent> logging to http://www.w3.org/2011/10/30-css-irc
Scribe: Arno
<Bert> The snow in the NE has made one victim: Florian not sure he can make
        today (see e-mail I just forwarded)

Agenda
------

   vincent: 3d interest group requested to meet w/ us
   Daniel: will add to agenda for Tuesday morning
   Tab: variables and hierarchy (nesting selectors)
   Tab: I have a proposed spec and would like sign off on "yes, we're going
        to do these"
   Tab: asking on behalf of shane and luke.
   Daniel: adding to agenda, but gut feeling: "you are going too fast"
   Peter: I have a joint meeting w/ web apps at 11am
   ??: discussion on CSS OM on tuesday morning would require david and tab,
       will they be there?
   tab: yes, there's a conflict w/ a fx meeting
   peter: no, fx meeting is on thursday
   daniel: please update wiki accordingly
   daniel: I did the schedule based on interest and joint meetings, it
           wasn't an easy task.
   daniel: any other extra items?
   everyone: no.

   <dbaron> Should we do a brief round of introductions?
   daniel: first, a request from sylvain: "how should wg handle issues?"
   daniel: yes, let's start with intros
   daniel: back to first issue

Issue Tracking
--------------

   sylvain: we implement a spectrum of specs at different levels
   sylvain: when something is not Last Call, questions get asked
   <sylvaing> http://lists.w3.org/Archives/Public/www-style/2011Apr/0359.html
   sylvain: the question above was asked, but not answered
   <sylvaing> https://docs.google.com/spreadsheet/ccc?key=0Akz3Ts2PEQF2dEdQMEtSMXFFMWJyYkVpdUtrWDB4Z3c&hl=en_US#gid=1
   sylvain: "how much normative info is laying around in the mailing list that's
            not incorporated?"
   sylvain: I replied "I don't know" and people freaked out.. :)
   sylvain: did an analysis of discussion threads, and it turns out that many
            did not got concluded and getting it back into the spec
   sylvain: we did that with css 2.1 where fantasai went through 10 years of
            archives to make sure that everything was taken into account
   sylvain: we shouldn't have to do this. we should have a better organized
            way of tracking issues.
   jdaggett: we already have a tracker, no?
   fantasai: but the editor does not keep up with the feedback
   dbaron: Of all the specs I've implemented, CSS Animations has been in the
           worst state
   sylvain: difficult to resolve differences between implementations...
   sylvain: when we get to module, we should have a link of issues
   vincent: would be nice to have one common way. I liked the suggestion to
            have an annotation in the spec that incorporates a link to the wiki
   vincent: not a big fan of the wiki because it's a bit too fragile, would
            like better method
   daniel: it's a human process, the editor still has to do the right thing
   <dbaron> (I think there are also a bunch of animations issue that I didn't
            even bother to bring up on the mailing list.)
   fantasai: we have multiple ways
   fantasai: different editors like different systems
   fantasai: I used to track issues in a plain text file, and that worked great
             for me
   vincent: I like steve's suggestion to incorporate it in the spec, because
            as you read the spec you can see where there are issues
   howcome: I think email works pretty well
   fantasai: This is not about the tracking system.
   fantasai: The problem is that if the editor is not tracking issues, the
             issues aren't being tracked. Period.
   sylvain: when it come to disposition of comments, you shouldn't have to go
            through email archives
   howcome: it's not a lack of mechanical solution, the problem is the editor
            needs to do the tracking
   dbaron: I like the idea of having it in the spec
   dbaron: Not necessarily as the only place to track it but as a place to track it
   dbaron: but that doesn't mean there shouldn't be some other way of tracking it
   steve: we may need a mechanism to collect in a list all the issues and what
          their status is, and we need a way to track what the issue actually
          is (email, etc.. anything with a URL)
   Steve: First issue I see is showing in the spec, at that place, that there
          is an issue there. Second we need some place that collects all the
          issues and tells you the status of the issues. Third is we need a
          way to document what the issue actually is
   steve: putting open issues in the document is pretty important, as it allows
          people to do something about it. but we probably to have somewhere
          else also to keep track of all issues
   chris: it's useful to be able to track issues over a long period of time,
          with a tracker or something else
   jdaggett: we don't need to track all issues, especially at the very beginning
             of a spec, but bug tracking does make sense when you get to the end
   <fantasai> jdaggett++
   fantasai: I agree with this, that's what I've done
   fantasai: but the editor still needs to response to feedback. If it doesn't
             happen, it doesn't matter what tracking system we have.
   fantasai: It's unfair to expect that others will do the work of identifying
             issues that need to be tracked
   fantasai: Note most specs currently don't link to their issues
   <JohnJansen> note: this is not just a problem with one spec, but is a more
                general issue
   daggett: how to we deal w/ feature request which the editor think should
            be dealt with later?
   fantasai: I dump it into tracker
   alan: there's also some wiki pages that include level 4 ideas
   tantek: I like wiki pages better, because it's easier to aggregate requests
           together, "since the future is fuzzier, a fuzzier mechanism helps"
   daniel: any concrete proposal?
   sylvain: when dino is around we should discuss w/ him
   tab: should we introduce an issue tracker so that if you file an issue via
        email you also have to file it into the tracker?
   tantek: it depends on where you constraint is. If it's editor's time, that's
           going to be the bottleneck
   <Ms2ger> Might as well go to filing directly in bugzilla, then
   <JohnJansen> ms2ger, the argument against that is that when a spec is young,
                bugzilla is too much overhead
   * Ms2ger doesn't care much about young specs
   dbaron: if there are multiple requirements to track issues (tracker, email,
           bugzilla, etc.) some people might use the wrong mechanism and issues
           may end up dropped on the floor
   tantek: it's already in the spec: send a message to www-style
   tantek: I think it's up to the editor to track the messages to www-style
           and track it
   tantek: however the editor track the issue, it should be public and others
           should be able to add issues
   molly: what about using some tools like stackoverflow, etc. to track?
   tantek: there's only a handful of mechanism other than bugzilla, tracker, wiki
   fantasai: I've used CVS/plaintext
   tantek: someone could add to it?
   fantasai: yes, a bit more cumbersome, though
   chris: as long as it's publicly available
   fantasai: yes, a local text file, spreadsheet, etc. would not work
   molly: each editor has process, but we need to communicate where the info
          is. the disparate methodology is creating a disparate problem in
          which we're not able to have this coalesced
   <tantek> molly is talking about a discovery problem ("where are the issues?")
            rather than a diversity of mechanisms problem.
   steve: as part of the status section of a spec, we should include where
          the issues are being tracked, so that you can know where the editor
          tracks issues
   <tantek> what Steve Zilles said
   <tantek> one single place to track where the issues are, not one single
            issue tracker
   steve: i.e. that's a per spec issue, not an issue for all specs, right?
   steve: I propose we have, for each spec, a clear indication of where the
          issues are tracked
   <tantek> fantasai - you said there are some specs that have links from
            their header to their issues?
   <tantek> examples?
   <Ms2ger> HTML has that
   <tantek> i.e.. which spec(s)
   <fantasai> tantek, http://www.w3.org/TR/css3-background/
   <dbaron> For http://dev.w3.org/csswg/css3-conditional/ I've just been
            tracking all the issues in <p class=issue>s in the editor's draft.
   <tantek> so none of those have links from the header
   <tantek> proposal: just as each spec must have a link to the editor's draft,
            right underneath that, it should link to where it tracks issues

   steve: if there's a clear list of issues, people could find out what the
          status is and have the group (or the chair) do the policing if
          necessary
   fantasai: so, each spec must have a clear, publicly accessible way of
             tracking issues
   fantasai: each module
   <Ms2ger> And note that nobody reads the SotD :)
   <sylvaing> http://dev.w3.org/csswg/css3-positioning/
   tantek: the examples above are buried in the spec
   RESOLVED: Each module must have one publicly-accessible, CSSWG-editable
             way of tracking issues.
   RESOLVED: Add link to issues list from spec header

   daniel: I'm not satisfied with a different system for each spec
   daniel: you have to adapt yourself for each one, and it's difficult when
           you're tracking 30 specs
   steve: building on the idea that there are 4 systems in use right now,
          could we restrict the list of acceptable issue tracking system
   daniel: that's a good compromise
   steve: we have 3: wiki, tracker and bugzilla
   <Ms2ger> And plaintext in CVS
   dbaron: and there's another one: track everything in the draft
   alan/tantek: do you keep a log of the resolved issues
   dbaron: no, the CVS log is the log...
   daniel: <squirms>
   tantek: so you're saying that twitter is the log, then...
   <tantek> here's an example of a spec which has links in the header to
            both editor's draft and issues list:
            http://dev.w3.org/csswg/css3-ui/
   tab: I use the same system as david, and it works for me
   alexm: with multiple editors it can get complicated
   fantasai: I use different systems, depending on the lifecycle of the spec.
   fantasai: when we need to resolve a bunch of issues as a group, I make a
             list and use it in tracker for easier resolution
   fantasai: at the end, I use a plaintext file
   daniel: let's close on steve's proposal
   <tantek> I use the wiki to track issues, and have been putting links from
            the document like: "Related open issue: 1. " (where "1." is
            hyperlinked to the issue)
   daniel: when using inline issue tracking, still indicate that in the header

   fantasai: we have the WD and the Editor's draft.
   fantasai: they may have separate issues list
   vincent: the current list of issues is related to the ED, not the WD
   fantasai: it's snapshotted if you track it inline, but otherwise the link
             to a separate issue tracker may get out of sync
   fantasai: maybe only have the link on the ED
   steve: no, too many people get to the WD than the ED, and then you will
          end up in the wrong issue list
   molly: agree, we need to coalesce, rather than fragment
   vincent: if you do inline issue tracking, that resolves it
   fantasai: could be resolved if the link to issues in the WD point to the
             ED issues list
   molly: the ED is the up to date version of issues are tracked. so we could
          just have a link that points to the ED to find out what the current
          issues are
   tantek: maybe we need a warning in the WD that makes it clear it's out of
           date...
   chris: when it's published as a TR it should not include the list of
          issues anymore
   <Ms2ger> Why not?
   daniel: a TR has a date, so having issues there would be appropriate to
           reflect what the issues were for *that* version of the document
   daniel: I don't know how to tweet this
   <ChrisL> @ms2ger I was arguing against a static, out of date copy of the
            state of issues in a /TR published draft, if the editors draft
            has a more up to date list
   daniel: issue trackers used: bugzilla, wiki, tracker, inline
   RESOLVED: use one of bugzilla, wiki, tracker or inline to track issues.

   fantasai: The wiki became very unweildy with CSS 2.1
   tantek: let's not have big specs like that anymore :)
   fantasai: how do we track 300 issues on one wiki page? doesn't seem to scale
   <tantek> we can cross that bridge when we reach it
   johnjansen: that's why I like bugzilla better to do the tracking
   vincent: maybe it depends on the lifecycle, later on in the spec's life,
            using bugzilla may be better
   fantasai: not asking for a WG resolution, but sharing my experience
   fantasai: You're going to run into this problem if you're tracking all
             the issues on a single wiki page.
   fantasai: When we used plaintext for CSS2.1 issues, we had a separate
             file for each publication.
   steve: we have these discussions where we agree on a particular strategy,
          recorded in the minute, and then it slowly gets out of memory as
          time goes on
   steve: could we have this recorded in the wiki or somewhere
   daniel: I agree that best practices are needed
   <tantek> here: http://wiki.csswg.org/spec#specification-editing

   daniel: what should happen if an editor doesn't track issues?
   daniel: spanking the editor?
   steve: the chair has multiple paths: talk to the editor, talk to the AC rep,
          raise it to the group and replace the editor
   tantek: after step 1 (talking to the editor), you could also suggest adding
           a co-editor
   tantek: or even assign a co-editor
   tantek: that's worked in the past
   daniel: you need to know there's an issue with the issue tracking
   tantek: if the ED gets more than 1 year out of date...
   tantek: there are past signals and procedure that seem to have fixed it
   tab: re: issue tracking and bugzilla, there's only 5 components in it
        right now. could we add all components?
   johnjansen: yeah, how do we do that
   solution: mail mike smith (or bert) to ask the components to be added
            in bugzilla

   sylvain: we have 1 hour tomorrow for animation
   sylvain: I have some technical discussion that needs to happen
   bert: maybe that's a topic for the plenary
   tantek: there are several issue re: specs
   tantek: sounds like you want to lead a discussion
   bert: no, not really...
   daniel: anything else about spec editing/tracking?

   plinns: that makes me want to build a tool. would people use it?
   tantek: might be worth looking at hixie's tool'
   tab: it's easy to deal with
   daniel: yes, select all and resolve as invalid :)
   <Bert> Tracker itself came out of Dean Jackson feeling like Peter feels now. :-)
   fantasai: you could improve tracker, most of its problems are UI issues
   fantasai: we have so many systems because all of them kinda suck
   tantek: who does the IT for bugzilla/tracker?
   chris: it's the systems team
   <tantek> URL?
   * tantek wouldn't mind seeing tracker's source/deployment moving to github.
   daniel: let's close this agenda item and move on the next one
   daniel: let's move to css regions

   <tantek> <aside> just stubbed http://wiki.csswg.org/spec/issue-tracking -
            please review and feel free to improve </aside>

CSS Regions
-----------

   vincent: <showing slides>
   vincent: css regions (alex and vincent)
            css exclusions (rossen and vincent)
            css fragmentations (fantasai and rossen)
   vincent: ED after the tokyo meeting
   vincent: most issues have been worked out, except the ones to review today
   vincent: 2 implementations in progress (IE and WebKit)
   vincent: would like to resolve some issues today and publish a new WD
   <dbaron> Is positioned floats part of one of those three parts?
   vincent: positioned floats is another module (not the three parts above)
   vincent: positioned floats is a 4th part
   vincent: issue tracked in the spec, and the wiki has a list of resolved
            issues and no longer in the spec
   <dbaron> http://wiki.csswg.org/spec/css3-regions#issue-19special-behavior-of-iframe-flow

   howcome: I have concerns with the current regions approach
   howcome: we need them, but it doesn't discuss two issues that seem important:
            pagination and auto-generation of boxes
   max: currently done by script, using OM
   alan: to have the entire content displayed, you need a page template
         mechanism
   howcome: multicol is already doing auto-generation
   alex: we use at multiple use cases, and there are so many cases that
         you need script anyway
   howcome: I'd love to see the use cases.
   alex: for some use cases you need script, but maybe we can have a subset
         that does auto-generation
   <stearns> you can display the entire content (by having the last region
             overflow)
   steve: you are correct that some of the problem have do with pages.
          you can't know ahead of time how many pages you need. rather than
          picking up on region, it seems like this is something that should
          be handled by pages instead
   <fantasai> didn't Bert have a proposal in css3-template that solved this
              kind of problem?
   steve: some way of having master pages that can be combined through an
          auto-generation mechanism to do this
   steve: multicol seems too weak to deal with this
   howcome: I'd like to approach this by looking at use cases
   vincent: we looked at what's needed for magazine, but regions are one
            the building blocks that's needed. pagination is useful as well.
   vincent: there's a lot that can be done with regions, and we'd like to
            work on pagination as well
   vincent: regions was a common denominator across all the use cases we
            looked at
   howcome: I think two things regions must address are pagination and
            auto-generation
   steve: I'm confused: neither of these things have to do with pages,
          pages is a separate module
   howcome: I think we're using the terms differently
   * alexmog proposes action for Håkon and Alex to propose a mechanism
             for autogeneration
   howcome: If I take a stylesheet from one document and apply it to another
            that has more content, I should still be able to *see the content*

   steve: regions doesn't resolve all problems. it's one building block,
          that can be chained with others.
   steve: the intent was that the auto-generation would be done over a
          collection of regions, called a page, that would get auto-generated.
          you're correct this is not correctly specified, but it makes more
          sense to deal with it in the context of pages, rather than regions
   howcome: I don't think we fundamentally disagree. we both want to do regions.
            I think it's possible to latch onto the multicol model with does
            auto-generation and paginations
   howcome: if you can have selectors for each column, and column on each
            page, maybe layout-wise it's as powerful, it solves the use cases
            but gives you pagination and auto-generation
   bert: I did some work past few days to integrate regions spec in template
         layout
   bert: for repeating, not completely worked out, but should be possible to
         put a template in a column.
   bert: all w/ same mechanism, you only need a selector to select a column
         and a column in a page
   <Bert> -> https://www.w3.org/Style/Group/css3-src/css3-layout/Overview.html#repeating-templates
          note about combining columns and regions (i.e., templates)
   fantasai: Can we have this draft on dev.w3.org?
   Bert: It's convenient to have it internal.
   fantasai: It's more convenient for us to have it public.
   Bert: I'd rather publish a WD. fantasai: Yes, let's do both. :)
   <Ms2ger> fantasai++
   <Bert> action bert: move template layout to dev.w3.org
   <trackbot> Created ACTION-374
   http://dev.w3.org/csswg/css3-layout/#repeating-templates

   howcome: can we see the use cases?
   daniel: have them in the spec
   vincent: we don't have use cases in specs in general
   daniel: maybe in an appendix
   molly: there's a convention in publishing, if it's a screenshot it's not
          considered proprietary
   * tantek agrees with daniel
   howcome: we need to see the use cases
   howcome: we need to support auto-generation
   hwocome: Shouldn't have to resort to scripting.
   howcome: we need pagination
   <tantek> would be useful to capture/see the use-cases in the spec that
            drove the design. in an Appendix is fine.
   * sylvaing dreams of specs with uses-cases appendices
   vincent: agree with it, but our take was that pagination and auto-generation
            were not going to be covered in regions spec
   steve: shouldn't it be in the paginated media module?
   howcome: that would be fine, but the specs should evolve at the same time
   alex: I think you're trying to do a simple page flipper, it would be great
         to support that
   howcome: My use case is to have a fancy first page of an article, and then
            second and subsequent pages flow as multi-col
   vincent: That's issue 12, whether to have multicol as regions
   vincent: multicol serves multiple purpose, it's both a template and a way
            to paginate
   vincent: auto-generation goes much further than just that
   alex: I think we need to talk about it and decide which spec it belongs to
   steve: I think we should record the issue that howcome is raising
   alex: I think pagination/fragmentation is a fundamental feature of layout.
         the region spec is about how to provide this boundary
   howcome: I just want to know how to print documents with regions on them
   daniel: we have 15min remaining. let's move on.

   <dbaron> http://wiki.csswg.org/spec/css3-regions#issue-12should-we-allow-multi-column-elements-to-be-regions
   vincent: do we want multicol elements to be regions or not
   fantasai: I'm in favor
   alex: I like that idea too, add very little complexity to implementation
   alex: if there's a region and you set column = 2, you get a region with
         two columns
   rossen: overflow would be interesting in that case
   rossen: this would lead to introducing fragmentation
   steve: seems like the AI is "how should it be done or why it shouldn't
          be done"
   jdaggett: is the question something with both multi-column and region,
             what happens?
   jdaggett: where does the spec forbid it?
   section 4.2
   <vhardy> http://dev.w3.org/csswg/css3-regions/#the-flow-from-property
   howcome: multicol only changes how things are laid out inside the element
   howcome: I don't understand how multicol would be any harder...
   alex: some work needs to happen, because overflow behavior is different
   howcome: I don't understand why we need a proposal
   daniel: we need a proposal, alex/vincent come back to the group when you
           have one
   action vincent: bring a proposal for interaction between multicol and region
   <trackbot> Created ACTION-375

   <dbaron> http://wiki.csswg.org/spec/css3-regions#issue-19special-behavior-of-iframe-flow
   alex: issue 19: special behavior of iframe.
   alex: two implementations (IE and webkit) have different behavior. need to reconcile.
   alex: need some sort of indirection mechanism
   fantasai: how does it related to the seamless attributes in HTML5
   alex: seamless also allows transparency wrt scripting and style rules
   hober: seems like allowing flowing of content is not specific to regions
   alex: once the flow is picked up from iframe, not relevant to iframe either.
         maybe have a link element referring to a url with the external flow
   alex: I would like advice
   tab: I am scared of this, esp. re: security
   tab: this would allow arbitrary interaction with layout
   alex: currently restricted to same origin
   fantasai: seems like the switch should be at the HTML level
   hober: certainly not at the regions level
   tab: I don't think we should tie a "transclusion" property with regions
   molly: I think it should be in html5
   <dbaron> http://dev.w3.org/html5/spec/the-iframe-element.html#attr-iframe-seamless
   <Bert> (Sounds like this already exists: XInclude)
   tab: we should make a separate spec for transclusions
   steve: you can put the iframe in the flow, but not the content of the iframe
   tab: the content of iframes are a black box to css
   johnjansen: you get the security protection by using iframe
   tab: the security concern is in the other direction
   rossen: the core of the problem is do we allow external content to flow
           through regions? if we do, we need a way
   daniel: what's the use case
   rossen: digital publishing that pick up articles from various sources,
           and aggregates them
   daniel: seems like it could be a feature we add later
   dbaron: doesn't seem specific to Regions
   molly: or CSS at all. seems like HTML
   alex: looks like we don't have a proposal, and that's what IE is going
         to ship
   hober: it could be anywhere it's appropriate
   <Bert> (B.t.w., https://www.w3.org/Style/Group/css3-src/css3-box/#the-width-and-height-properties
          defines 'height: complex' to deal with SEAMLESS (although it
          predates the invention of that attribute.)
   daniel: This reminds of the time when features where implemented before
           discussions
   daniel: and it gives me a bad feeling
   daniel: I have the gut feeling you're going too fast. there's no agreement
           between parties it should be the spec and you say: "it's in IE"
   alex: I disagree w/ the statement that we don't care about it
   * tantek agrees with daniel. this feels like we (the working group) are
            racing towards shipping incompatibility and legacy compat issues.
   <fantasai> +1
   ACTION alex: remove text about special iframe behavior and alex to write
                proposal about the behavior of iframe
   <trackbot> Created ACTION-376

   * Bert to Daniel: can we find 2 minutes somewhere on the agenda to decide to publish a new Template Layout WD (probably 
conditionally, with a week's delay, so people can raise objections if needed)?
   * glazou Bert yes, right after lunch?
   * Bert OK

Scribe: fantasai
   <dbaron> http://wiki.csswg.org/spec/css3-regions#issue-10should-the-regionlayoutupdate-event-by-sync-or-async
   vhardy: Should this event be synchronous or asynchronous
   vhardy: IE implemented as async, seemed to work with demos they built
   alex: Not sure how to make it synchronous
   vhardy: If no convincing argument for sync, then making it async
   dbaron: Are you defining exactly how it's async?
   alex: Sync would be defining exactly in what order it happens
   alex: async means that some layout process has happened in this region,
         and you're notified of that
   dbaron: I agree with making it async. Might need more detail at some point
   RESOLVED: regionLayoutUpdate is an asynchronous event

   <vhardy> http://wiki.csswg.org/spec/css3-regions?&#issue-18interplay-of-flow-from-and-content
   vhardy: interplay of flow-from and content
   vhardy: which one has precedence?
   vhardy: We had resolved to say that flow from property gets used in place
           of content for associating an element with a flow
   vhardy: We moved from using 'content' to 'flow-from', there was issue raised
           during meeting that not sure this was quite the right decision
   vhardy: My request is to close the issue unless we have a problem to discuss?
   vhardy: I'd rather close it, and reopen if you have a specific objection
   fantasai: I'm ok with that.
   Bert: flow-from is on regions, content is on elements. So they don't interact.
   vhardy: flow-from makes something a region
   Bert: There are various ways to make regions, but content is on an element.
   vhardy: Right now if you want to flow content into an area, then you'll pick
           a flow and then put it in an element, which makes it into a region
   howcome: Bert's point is that you're using an element to create a region.
            You could create a region without an element
   RESOLVED: close issue 18, reopen if needed later

   <dbaron> http://wiki.csswg.org/spec/css3-regions#issue-22content-vs-flow-from-precedence
   vhardy: content vs. flow-from precedence
   vhardy: On mailing list there was overwhelming preference for 'content'
           to take precedence
   fantasai: The 'normal' value of 'content' would compute to using flow-from
             when available
   discussion of using 'content' to override content
   alex: flow-from blows away whatever content is there. Why shouldn't it be
         more important than 'content'.
   vhardy: So we have a proposal from several to have 'content' != 'normal'
           override, and other is to have 'flow-from' always override.
   alex: If we had display-inside: region, then 'content' would be irrelevant
   alex: flow-from is two properties in one
   fantasai: 'content' property is supposed to be the master switch for what
             the contents of this element are.
   fantasai: I don't like having properties that unilaterally override other
             properties.
   fantasai: That always leads to problems.
   fantasai: we have this problem with 'border-image', where if someone sets
             'border-image' further up in the cascade, my 'border-style: dashed'
             inexplicably has no effect
   Bert: A different solution, apart from needing two properties, the model
         doesn't have to be one overriding the other.
   Bert: In Template module, if two pieces of content go into the same slot,
         they add up
   alex: So if there's content in the region, then it's appended to the flow?
   vincent: You would include the element's content, and the append the flow
   molly: from a developer perspective, 'content' should be about the content.
   discussion of applying 'content' to an image
   fantasai: if you write img { content: "foo" } the <img> element will cease
             to be a replaced element and will become an inline element
             containing the string "foo"
   alex: If that's the case, then I agree.
   fantasai explains the 'content' property and its various values and effects
     on elements, pseudo-elements, replaced elements, etc.
   RESOLVED: If 'content' computes to 'normal', then the element takes the flow

   <vhardy> http://dev.w3.org/csswg/css3-regions/#the-at-region-style-rule
   vhardy: The @region doesn't have the pseudo-selector ppl didn't like
   vhardy: The number of properties that apply listed in that link, font
           properties, background properties, simple rendering properties
   vhardy: Also includes borders/margins/padding,
   vhardy: We explain why some things that apply to layout might make sense
           here
   vhardy: there's a simplified list of properties that can apply to regions,
           but it's now more than ::first-line
   vhardy: In our impl experience, this has been ok
   alex: multi-col properties?
   vhardy: The multi-col isn't on the flow content, it's on the region itself
   alex: We should have an element there, say <article> as 3 columns... flows
         into a 1 column region
   alex: Could choose to have 1 col in one region and 3 col in another region
   * fantasai doesn't understand this issue at all and need to read the spec
              before making any comment
   vhardy: You can't change the layout nature, e.g. display/position
   vhardy: multicol... I guess it's halfway
   vhardy: I guess we could add it
   dbaron: Does this specify somewhere how the cascading and inheritance works?
   vhardy: yes, somewhere there
   dbaron: .... specificity isn't the issue
   howcome: It's multiple inheritance, isn't it.
   Bert: It's the ::first-line problem.
   fantasai: Can we put ::first-line into the regions spec so you can solve
             all the problems at the same time? :)
   vhardy: If there's an issue with cascading/inheritance then I'm happy to
           take that as a separate issue. This one is about the list of
           properties.
   ...
   howcome: if you set 1.2em on something inside a region, what does it
            refer to?
   vhardy: If you set the font size on the region itself, it has no effect
           on the content just on the layout of the region
   howcome: I have a region, and I set font-size on that. And it's applied
   howcome: And I have a span inside it that sets 1.2em. What is it relative to?
   vhardy: If you set it on the region then it doesn't inherit
   Steve: You can't have it both ways.
   Steve: If you set it on the region and it affects the text, it inherits
          into that element
   howcome: What if you set 'inherit'?
   Steve: I wouldn't answer that question hastily...
   Steve: ::first-line has the same problem
   dbaron: This is very different from ::first-line actually
   dbaron: I'd like the example in the spec to not use pseudo-syntax, use
           real syntax
   jdaggett agrees
   jdaggett: I'd like the examples to show what an author might use, not
             just region1 region2
   Steve: dbaron, I thought you said ::first-line effectively introduced
          an element around that thing, so inheritance would go to the
          first line
   dbaron: ::first-line introduces an additional pseudo-element around it,
           and I forget the wording around inheritance 'cuz we changed it
           so many times
   dbaron: But this also has selectors inside the region rules, so you can
           have an element that picks up different selectors based on where
           it breaks.
   howcome: It says font size in percentages refers to inherited font-size
   dbaron: I think the model here is actually relatively simple. I think
           it's simpler than ::first-letter. However it doesn't agree at
           all with the spec's existing terminology. So it's sort of hard
           to write about.
   dbaron: This model gives elements multiple styles essentially.
   * tantek is a bit confused about the distinction between the "current"
            font-size and the "inherited" font-size.
   dbaron: And 2.1 is written assuming that an element has *a* computed
           value for a property
   Tab: All the specs are written with that assumption
   dbaron: This is more box tree stuff
   fantasai: We're introducing the term "fragment" to talk about pieces
             of the box in the box tree when it's broken
   fantasai: might help with discussing this
   Bert: I also have 'vertical-align', works like in table cells
   Bert: I also have 'overflow': if contents put in the region are too wide
         for the region, where does it go? Is it visible at all?
   (talking about properties that are set on the region)
   Rossen: This is about the properties that are propagated to the contents
           of the region
   Rossen: Back to howcome's example, when you compute fonts you always have
           a resolved font-size no matter where you are in the tree
   Rossen: If we allow regions to specify font-size, this would be equivalent
           to changing initial font size on the fly
   Rossen: Once you're inside, you start again from the root
   Rossen: Like howcome pointed out, this is multiple inheritance, no kidding
   Rossen: you won't know your font size until you lay out the part of the
           element that you're computing
   Rossen: Simplest example is body with 100em width
   Rossen: It appears in 2 regions, one with 10px font size and one with
           100px font size
   Rossen: In this model you will have to recompute the body size
   vhardy: No, right now all inheritance happens through the element tree
   vhardy: you're adding selectors that apply to fragments
   ...
   vhardy: In our model, you'll set a selector: if my H1 is in this region,
           here's the font size that applies
   howcome: in that sense you don't have multiple inheritance
   Steve: the multiple inheritance is when you have different pieces of the
          block that get different styling
   CHrisL: Similar to ::first-letter multiple inheritance
   dbaron: no, I don't think it is

   dbaron: Wanted to bring up 2 other things
   dbaron: Thing you said about percentages relative to the original, that
           sounded wrong to me.
   dbaron: I'd think if you have separate styles for stuff in the region,
           you'd compute styles in a consistent model within that tree
   dbaron: Percentages etc. would compute relative to those styles until
           you're back outside of that region
   dbaron: I don't think multiple inheritance is the right way to think
           about that.
   dbaron: Other thing I wanted to mention is, if we think about it that way
   dbaron: Then any property that takes lengths can change as a result of
           font-size changes.
   dbaron: It seems silly to restrict that then, i.e. only allow changes
           as a result of font-size but not arbitrarily otherwise.
   dbaron: Basically if you have
           @region head { body {font-size: 2em; }}
           h1 { height: 2em; }
   dbaron: Your body font size is going to be double your HTML font size
           as it flows into this region.
   dbaron: your h1 initial font size is specified in ems
   dbaron: If you accept what steve and I say, then the h1 is going to be
           proportionally larger
   dbaron: but what you said earlier is that it wouldn't be
   Steve: So I thought what you said is that you're overlaying styles on
          these elements using selectors
   Steve: so you'd walk up the tree and see the overlaid styles
   vhardy: ... this is why the properties only make sense ..
   vhardy: height doesn't make sense to apply to different fragments of the div
   steve: height has to look somewhere for its value
   vhardy: So that's something you'd have to compute relative to the parent
           element
   vhardy: If my h1 is in the head region, will it be based on that value or
           the other one
   vhardy: I'll take an action item on that.
   howcome: We all wanted to have a use case appendix, wasn't recorded as an
            action item.
   ACTION vhardy: Make a use case appendix
   <trackbot> Created ACTION-377

<br type="lunch" dur="60min" />

Received on Monday, 28 November 2011 22:21:42 UTC