- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Mon, 28 Nov 2011 14:21:08 -0800
- To: "www-style@w3.org" <www-style@w3.org>
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