- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Mon, 28 Nov 2011 13:39:24 -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.*
Values and Units
----------------
RESOLVED: remove <fraction> and <grid> (ISSUE-193)
http://www.w3.org/Style/CSS/Tracker/issues/193
Positioned Layout
-----------------
Arron presented a draft for CSS3 Positioning, which includes CSS2.1
absolute, fixed, and relative positioning, containing blocks, and
z-index; and that adds:
- 'position: center', in which 'auto' offsets compute to center the element
- 'position: page', in which the current page box is the containing block
There were concerns raised that the page positioning scheme would result in
layouts that broke very badly if the document were either rendered onto a
continuous (scrolling) canvas, or if it were paginated differently than the
author's original intent (due to differently-sized fonts, differently-sized
pages, etc.). Thus:
RESOLVED: Publish CSS3 Positioning as FPWD, without position: page
Animations
----------
RESOLVED: CSS animations do not start or continue running on elements that
are display:none or inside display:none elements.
RESOLVED: Two new co-editors Sylvain and dbaron for Animation module.
ACTION: Define how properties are interpolated when left out of a subset
of keyframes.
RESOLVED: 'all' is allowed within lists in 'transition-property' (but
'none' is not). Which item wins works like for shorthands,
so it's silly to use 'all' other than at the start of the
list, but it's not forbidden.
RESOLVED: Fire the animation cancellation event on the disconnected element
if the element has been removed
RESOLVED: Will consider animating inset to outset box-shadows iff someone
posts a proposal of exactly how that's supposed to work.
====== Full minutes below ======
http://www.w3.org/2011/10/31-css-irc#T16-07-49-1
http://krijnhoetmer.nl/irc-logs/css/20111031#l-473
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)
Alex Mogilevsky (Microsoft)
Florian Rivoal (Opera)
Alan Stearns (Adobe)
Shane Stevens (Google)
Steve Zilles (Adobe)
Scribe: Bert
Values and units
----------------
<fantasai> http://www.w3.org/Style/CSS/Tracker/products/8
<fantasai> http://www.w3.org/Style/CSS/Tracker/issues/193
fantasai: Issue 193 is about removing <fraction> and <grid>
fantasai: Not sure they are actually used anywhere.
fantasai: Apart from unstable modules.
fantasai: If necessary we can add them back in Level 4
Florian: Sounds reasonable. No hidden issues?
Markus: If another spec needs it?
fantasai: Some modules already define their own units.
RESOLVED: remove <fraction> and <grid> (ISSUE-193)
fantasai: ISSUE-195 is next
fantasai: In CJK
fantasai: fonts typically have 1em advance.
fantasai: We have a ch unit.
fantasai: Compressed CJK fonts do not advance 1em.
fantasai: Dow we want a new unit for CJK fonts advance?
Florian: Is font is proportional?
fantasai: No, for compressed, but still monospaced fonts.
jdaggett: Don't think we should add it.
jdaggett: It is not going to help you.
fantasai: Our feedback was that a line consisting only of ideographic
characters should be set solid.
jdaggett: how do you get the value?
fantasai: Same way as ch unit.
jdaggett: Did you ceck that fonts actually give that info?
Koji: [...]
Koji: Definition in Opentype.
Koji: "if this table then use that"
jdaggett: I'm sceptical.
jdaggett: Would like to see a post on www-style, with use-case
ACTION koji post use-case on www-style. Then we'll look at actual fonts.
<trackbot> Created ACTION-386
Positioned layout module
------------------------
<arronei> http://dev.w3.org/csswg/css3-positioning/
arronei: [shows module on screen]
arronei: Updated with feedback from last ftf
<arronei> http://wiki.csswg.org/spec/css3-position
arronei: See also the issues list
arronei: Still need to discuss some things with Tab.
arronei: Today topic is page positioning and centering.
arronei: Page position is absolute, but looks a bit like fixed.
arronei: Mainly meant for Regions.
arronei: A deeply nested regions can still be positioned relative to page.
arronei: If not in a region, position is relative to initial CB.
arronei: Possible problems with overlap in that case.
Howcome: Hard to understand without examples.
arronei: Regions create new initial containing blocks.
howcome: Can you put something in a position on page 3, e.g.
howcome: 'position: page' with offset?
fantasai: Overlap if you are not on the page you expected to be on.
arronei: Really focused on regions.
fantasai: Don't like that fallback behavior.
howcome: Yes, that is a problem.
howcome: Page floats don't have that problem.
howcome: Next float autom. goes beneath previous one.
fantasai: page positioning seems to break too easily, and very badly.
[dicsussion about cases]
fantasai: At least with floats everything remains readable, visible.
arronei: I hear some concerns. What is general feel?
Peter: Some cases you may not care so much, e.g., create a watermark.
arronei: Shall we pull it out then, for now?
Steve: For named pages, can you use the name?
fantasai: abs. pos is not the greatest thing with pagination.
fantasai: This solution is broken enough to need redesign.
arronei: Do you already have a better solution?
fantasai: Not really.
arronei: We need something eventually.
Steve: We'll need some way to make a seq. of pages with each their own
structure.
Steve: As we said already with howcomes' demo yesterday.
Tab: Something like float's ability to reposition itself.
fantasai: important is that it doesn't break horribly if things aren't
exactly as expected.
(various): Changes to the page size, margins, or font size can cause
things that were positioned on different pages to be positioned
on the same page, so that they overlap.
arronei: If you adjust the margins on a page, you may easily get two elements
on the same page where you didn't have them before.
fantasai: This will break if you either paginate differently or display in
scrolled media
Alex: Anything available that would work?
howcome: page floats!
alex: Still need to get something in top right if you want it in top right.
Rossen: confusion between clearing and positioning.
Rossen: Position page is not necessarily the feature at risk. It lacks
clearing, yes, but if we solve that, we don't have the fallback
problem anymore.
Rossen: Do you propose to pull the feature to solve positioning or solve
clearing?
Florian: both.
Alex: Exclusion, positioning and floats all needed, 3rd part not done yet.
howcome: page floats works, in spec and tested in implementation.
arronei: find middle ground.
Tab: floats don't overlap, that is the big difference.
fantasai: My issue is that something that is designed such that the fallback
nearly always fails, is not good.
fantasai: We can leave it in ED, but should not be like this in WD.
Alex: Want to be able to
Alex: General solution for floats is complex.
Alex: We want that, but want exact algos.
Alex: positioning to page is very important.
Alex: Needed for pages with exclusions.
Alex: Some of their logic will have to be in scripts.
Alex: Very hard to do without positioning to page.
Alex: [something]
Alex: This will only work well with multiple positioned items if you have
script
Tab: only useful with scripting, you say?
Alex: Probably.
fantasai: So that indicates to me the model is broken and you need a better
one.
Tab: We should not write something that is broken just because we don't
have time for the better one yet.
arronei: We should think about clearing, not decide it right now, but think.
arronei: Can put it in Editor's Draft.
Steve: Put in the ED what the issue is, and what arguments are,
fantasai: and look for other solution for same use cases.
arronei: I can put that in.
Brad: What does page float not solve that this does?
Steve: yes.
Alex: something that is positioned and does not collide with other things
is a page float.
howcome: We should find use cases and solve the problem.
Brad: So this is complementary to page floats?
Alex: In the future we need page floats that can be positioned absolutely
on a page.
Alex: Don't worry that we will have that some time in the future.
Alex: We want more, but what we have is good enough for now.
Howcome: We want the use cases to be solved, but we also need the fallback.
Cannot rely on scripts to solve the fallback.
fantasai: Good summary!
Alex: We have no media selector to distinguish scroll from paged.
Tab: It's not about paged vs scrolled. Even within paged media, this breaks
if you change the pagination
Alex: Let's make floats work.
arronei: Yes, but we need to move this spec. There aren't many issues left.
ACTION arronei: detail issues further and come up with use cases and solve
them better and pull page positioning out of WD.
<trackbot> Created ACTION-387
arronei: Need to handle the cases were there is overlap.
arronei: About center positioning:
arronei: Very old request.
arronei: It is now similar to block-level non-replaced centering with
auto margins.
arronei: Margin: auto wouldn't work here.
arronei: There is a calculation in the spec.
arronei: Set 'position: center'
Alex: bottom positioning is a problem.
fantasai: This allows us to position out of flow objects, but still not
in-flow objects.
fantasai: And that is more important.
Daniel: Agree.
Tab: Can use flex box, or grid.
dbaron: Proposal is reasonable for positioning.
dbaron: Could add something about auto margins, not defined currently.
Tab: horizontal only, or vertical, too.
dbaron: Symmetric.
fantasai: No, it is not symmetric.
arronei: We'll keep this part in the draft.
dbaron: you can center vertically with auto margins, in level 2, as long
as height is fixed.
fantasai: exactly
[discussion about case with height: auto]
arronei: Should work for auto height, so I'll correct that.
dbaron: For centering in each dimension you need to set four properties
and set height.
arronei: Some other issues in the spec:
arronei: No ruby values.
arronei: Not sure what a positioned ruby works.
dbaron: Do the spec need to redefine CSS 2.1 section?
dbaron: Can't you just say it amends CSS 2.1 for these cases?
Tab: Do we want to write delta specs?
Chris: We decided to refer to CSS 2.1 from level 3 modules.
Tab: Yes, but not the same thing.
Chris: We decided that level 3 can refer to CSS 2.1 and to other modules.
Steve: A module is self-consistent. It refers to other specs, of course.
fantasai: Modules replace CSS 2.1, also to make text more readable.
fantasai: This spec should not define display types not un CSS 2.1.
fantasai: Flex Box defines its own display types and their interaction
with this spec. Likewise Ruby.
arronei: So I only need to refer to 2.1 display types here. OK.
dbaron: You need to redefine the term "absolutely positioned" to include
center and fixed.
<dbaron> http://www.w3.org/TR/CSS21/visuren.html#absolutely-positioned
<dbaron> http://www.w3.org/TR/CSS21/visuren.html#position-props (positioned)
arronei: Next is inset-rect.
dbaron: Yes, we resolved to add that some ten years ago :-)
arronei: So I think we're OK with this part.
arronei: Last issue is stacking context and opacity and transforms.
arronei: Couldn't find any conclusions about that.
dbaron: Both opacity and transform on elements without z-index, than act
as if z-index is 0.
dbaron: If it is positioned and has a z-index, than use that.
dbaron: Otherwise do as if z-index is 0.
arronei: Implementations seem to do that, indeed.
arronei: How about transforms?
dbaron: Believe they are the same.
arronei: I will add that to this section.
arronei: Can we then move this to WD?
daniel: I think we should. Objections?
[no objections]
<dbaron> see http://lists.w3.org/Archives/Public/www-style/1999Jul/0014.html
for inset-rect() :-)
RESOLVED: Publish CSS3 Positioning as FPWD, without position: page
daniel: One remark: you cannot actually search for "issue" in the draft.
daniel: Can that be fixed?
fantasai: I think it is a bug in browsers that they don't find generated text.
daniel: But we need a way to find issues now.
Animations
----------
[discussion about agenda, break, joint meetings...]
Daniel: yesterday already some issues.
Dean: Most editorial issues were addressed already. So we can today talk
about difficult issues.
sylvaing: What happens when an animation is cancelled: is there an event?
dean: You mean, ended before it completed?
Dean: What would you do at that point?
Dean: Just a notification?
Dean: I'd be OK with that.
sylvaing: Need to put in one place all the things that can happen on
cancellation.
Dean: Give me an action to add an event?
ACTION Dean add an event for animation cancellation
<trackbot> Created ACTION-406
Dean: display: none is tricky.
sylvaing: People expect that properties continue to change, even if you
don't see anything.
sylvaing: But you can achieve that with a delay.
Dean: Computed style of a property exists even when display is none,
doesn't it?
dbaron: starting an animation is result of computing a value.
dbaron: We don't define *when* you compute style.
dbaron: Just assume it happens at proper time.
dbaron: Authors depend on display: none content not having a performance
effect.
dbaron: But changing this will have such a performance effect.
Shane: Not so much impact, only looking at selectors that apply.
sylvaing: Animation delay solves it.
dbaron: Not so sure about shane's performance assessment. There's also
memory, and inheritance.
shane: It doesn't fundamentally change the behavior of 'display: none'
dbaron: It doesn't change for authors who don't have animations.
dbaron: But it does change where there are animations.
shane: Yes, in some cases.
[discussion about impl. architecture and impact, scribe didn't understand]
Chris: The author will expect that hidden stuff is still up to date.
sylvaing: Use delay.
Tab: Cannot know delay in advance.
Dean: Calculate time line in advance for part of the tree.
Dean: In some future version of the spec we can define that animations
can be aligned.
Dean: Problem that we cannot do that now.
Dean: But we can still say things in current spec so that implementations
don't have to compute for elements with display: none.
Dean: No events.
Dean: You could use script and set delays as well.
Dean: What happens if you animate 'display: none' in a key frame?
Tab: As soon as we can animate keywords, you mean.
Dean: Yes, that is not yet in spec, but will add it.
Dean: I propose display: none means element is not animated.
Luke: What does it mean?
Dean: Elements with display: none and animation property, we don't even
look at animation.
Luke: So as author I first need to set to block, then add animation,
so GetComputedStyle(), then set display again.
Dean: Not sure I understand.
Dean: Just set display: inline or whatever and animate.
Dean: The rules for starting an animation should include that animation
starts as soon as display changes from 'none'.
Shane: Could get interesting.
Shane: Change in display may trigger an animation.
Dean: Is that any worse than applying animation styles? Performance hit?
sylvain: Problem if middle key frame has 'display: none'
brad: Say I want to move from left to right in 10 sec, and after 5 secs
I set display.
dbaron: So question is if display becomes none in middle of animation
and then becomes block again, does animation continue? Gecko
does that.
Brad: So I can stop animation that way and get my use case?
[Scribe didn't understand]
Florian: Spec doesn't really say it has to be that way.
Tab: Say 'display: none' is set during animation.
dbaron: We recompute style while the animation is running.
Tab: It won't restart until the display: none goes away?
Tab: Mental model is not obvious.
Florian: Simpler to say display: none doesn't animate?
sylvaing: We still need to define
Shane: Should we look at implications for perf. of running in display: none?
Markus: Also look at battery life.
dbaron: Animation can stop while display: none is in effect, you still
need to detect that.
Luke: No need to do that in real time.
dbaron: Yes, need to do that at each tick.
Luke: What if element itself is removed?
dbaron: We remove the animation as well.
Tab: It doesn't have any CSS anymore at that point, that is a distinct case.
dbaron: We explicitly stop animations when an element moves in the DOM.
dbaron: We have the code to preserve animations during display: none'
precisely to deal with the DOM issues.
dbaron: Harder to do if an ancestor has 'display:none' instead of the
element itself.
Tab: Model is really confusing, except if you understand browser kernels...
Tab: Simplest is that animations keep running, even if not displayed.
[scribe missed some]
Dean: Take a spinner, and you set 'display: none' to hide it and expect
it to start from zero when it reappears.
Tab: [explains an solution]
Tab: Instead of putting anim. on spinner. set it on spinner.shown.
Tab: No restarting involved.
Tab: Just add/remove the class when needed.
[some discussion not minuted during network outage]
Molly: When display is none, animation should not apply.
Molly: That is easy to explain.
sylvaing: But what if display is set to none in middle of key frame?
molly: Keep consistent.
Florian: Set none at 50% just kills the animation, that is consistent.
<ChrisL2> For clarity, I prefer to modify what Molly suggested - when display
is none, CSS animation must not apply
<ChrisL2> (because smil-based animation does apply when display=none)
Steve: display triggers a relayout, can use visibility hidden instead.
Steve: So letting display: none turn off anim seems reasonable.
Markus: Steve's solution is good.
dbaron: So I hear consensus that display: none breaks animations, stops them.
RESOLVED: CSS animations do not start or continue running on elements that
are display:none or inside display:none elements
RESOLVED: Two new co-editors Sylvain and David for Animation module
[break]
[Joint meeting with WebApps, scribed in #webapps, see their minutes]
ScribeNick: fantasai
sylvaing: Issue is what if a property is not specified in all keyframes.
sylvaing: Also what if one keyframe has an invalid value
dbaron: What happens in gecko when a property is not valid in all keyframes:
every animations animates all properties that are in any keyframe
of the animation, over the entire duration of the animation
dbaron: The animation interpolates each property across the keyframes
from the keyframes in which the property was present.
dbaron gives an example
smfr: Imagine exploding keyframes into keyframes per property. For keyframes
in which the property isn't specified, you ignore that keyframe.
sylvaing: So if I had an animation with keyframes at 0%, 50% and 100%, and
'width' appeared only in 0% and 100%, it just animates between
those two values and ignores 50% (for 'width')
dbaron: The fun case there, and one I'm not sure we agree on, is what happens
if some of the values are values you cannot interpolate between
dbaron: In Gecko, if there are such values, I drop the property from
animation completely
dbaron: So if you animate from width: 100% to width: 50% to width: auto,
I say you can't animate between 50% and auto, so I'm not going to
animate 'width' at all
Luke: If you have, say, an abspos div and it's specified left in the
initial state and right in the final state, you can't actually
do an animation for that thing.
smfr: It's the same problem as not being able to animate to/from auto
dbaron: Another issue here from testcase on www-style last week (from Lea?)
dbaron: In some cases, the computed value of one prop depends on computed
value of another property
dbaron: If your animation is multiple properties, what basis values are
you using?
dbaron: So in Gecko, I didn't really think about this when implementing,
so what I implemented is that it ignores other properties in the
animation
dbaron: That's probably wrong
dbaron: If we want this to work right, for some definition of right, things
can get pretty complicated quickly
dbaron: So I'm not sure what to do there.
example was animating stuff in ems and font-size (?)
Luke: Has anyone considered doing this in computed space instead of
precomputed?
Tab, dbaron: Happens over computed values
Luke: Instead of being ems and whatever, then you'd want these things to
be final pixel values
Luke: Instead of ...
dbaron: You want to animate used values instead of computed values. That's
hard because it depends on layout. Would rather not go there.
dbaron: I'd be more interested in solving those problems by making things
like calc(50% + 2px + auto) work
dbaron: or calc(auto * 0.5)
dbaron: Then it's much easier to solve these problems
smfr: theoretically you could lay out at the final state to find what
'auto' means
dbaron: The problem there is that might depend on other things that animate
smfr: So does Gecko explicitly not do animations that involve 'auto'?
smfr: In WebKit we have a bug where we treat 'auto' as 0
smfr: That makes things like left -> right work
Luke: So if you have these calc() expressions, you can defer layout
dbaron: Yes, you can do the animation on computed values and then you do
the layout with the interpreted calc() expression
dbaron: background-position has a problem, too -- it needs calc()
Shane: It's pretty much impossible to animate gradients without deferring
layout
Shane: For gradients, you can't generate and interpolate a computed state.
You need to do layout
dbaron: I think we have a lot of agreement on this. We need to write it up.
dbaron: a) How the loop over properties works: properties, the keyframes
dbaron: b) be clear that interpolation happens on computed values (think
we say that already)
dbaron: c) Issue on what to do with non-interpolatable pairs in the animation
fantasai: dropping it entirely seems like a better idea.
fantasai: More straightforward, and if we later figure out how to
interpolate it and people add it, it'll either work or not work
(in older browsers): you won't get this halfway jumpy thing
smfr: If the property is missing from a 100% keyframe and the animation
is looping, you could look for the next value in the loop rather
than going back to the base value
fantasai: so if you only have a property specified in one keyframe
smfr: It would go from base value to that value, stay at that value,
and then come back down to the base value once you stop animating
ACTION dbaron to write up description of how animations of properties
only in some keyframes work
<trackbot> Created ACTION-389
sylvaing: next issue is on transition property
sylvaing: Idea was that you could set a duration for all properties
sylvaing: and then override that separately
sylvaing: And we talked about the none case. We said that if you have 'none'
in the list of properties, that kills everything before it
dbaron: Right now none and all can't be part of a list
sylvaing: We agreed to fix that
dbaron: Missed that thread
dbaron: Seems like it makes more sense for all than none. Maybe fix it
for all and not for none?
Dean: So you can't put none in a list, but all you can
fantasai: so, can you put all anywhere in the list?
sylvaing: It will override anything before it
TabAtkins: So 'all' just happens to be a really big shorthand
fantasai: Reminds me of a request for blocking inheritance. Could do
"all: initial" for that
plinss: Anything else on animations?
RESOLVED: 'all' is allowed within lists in 'transition-property' (but
'none' is not). Which item wins works like for shorthands,
so it's silly to use 'all' other than at the start of the
list, but it's not forbidden.
dean: We had an issue on the animation cancel event -- an event that
fires when an animation gets cancelled
dean: The event fires on the element. But what if the element is removed?
dean: Do you fire on its parent? Or not fire the event?
dbaron: I'm inclined it should fire on the element or it shouldn't fire
dbaron: I'm not sure firing an event on something not in the document is
something to do
Tab: Not sure it's a problem. Your target phase is weird. You have events
firing at DOM non-elements all the time
dbaron: I'd prefer to ask a DOM Events expert; I'm not one
dean: If we do decide to fire on an element that's no longer in the DOM,
then it obviously can't bubble up to its parent.
dean: Typically people want to listen for events on an ancestor
dean: I'm tempted to say it doesn't fire
Tab: I'm not certain if I want to object yet.
Dimitri says something about not getting an event on an event listener
...
AlexRussell: In webkit [...]
AlexRussell says something about bubbling being useful...
Tab: Ms2ger says that firing a DOM event on a disconnected element should
be fine
RESOLVED: Fire the event on the disconnected element
plinss: Does anyone want to check with other DOM Event experts on that?
dbaron: I'll double-check with smaug as well
<Ms2ger> Please do :)
ACTION dbaron to check with smaug about firing DOM events on disconnected
elements
<trackbot> Created ACTION-390
plinss: Anything else?
sylvaing: One interesting piece of feedback from people internally using
them to dev applications
sylvaing: They're trying to animate inset box-shadows to outset box-shadows,
and it doesn't work
dean: We could do that..
smfr: I almost did that at one point, but gave up because it seemed a
little tricky
smfr: What do you do with spread, if it's nonzero?
dean: I still can't work out how you'd do it.
fantasai: You'd have to bring everything down to zero, then bring it all
back up on the other side
dbaron: Could you pretend that instead inset, you use negative numbers?
fantasai: You could define this, but it wouldn't be simple: have to bring
the offsets and spread and blur radius down to zero and bring
them back up. Do you do that simultaneously, one after the other?
dbaron: If someone comes up with a way to represent all these intermediate
states
plinss: You want to make it look like raised above, then you're sinking it
down
dbaron: You have to model it with a light source
TabAtkins: The shadows are not necessarily representable by a single
light source
dbaron: Assume the light source is a point at infinite distance, and then
only modify the distance fo the box to the canvas
dean: With a special model of physics, we can come up with a model for the
animation of inset to outset box-shadows. :)
* ChrisL wonders if relativistic effects have been ignored
smfr: Any more serious issues?
<dbaron> assume the light source is 45 degrees from vertical
Seems we will consider animating inset to outset box-shadows iff someone
comes up with a proposal of exactly how that's supposed to work.
plinss: They all have to hit zero at the same time or its going to look
stupid
dbaron: I could try writing it up, but not sure it's a high priority
fantasai: I think you have more important things on your to-do list :)
szilles: +1 to that
<ChrisL> so the question is how to simultaneously animate three properties
through zero and out the other side without a discontinuity?
<dbaron> I think it's relatively straightforward to break down each shadow
as something created by an infinite light source and a box elevation.
RESOLVED: Will consider animating inset to outset box-shadows iff someone
posts a proposal of exactly how that's supposed to work.
<dbaron> assume the infinite light source is at 45 degrees for both endpoints
Regexp matching and values of text-combine
------------------------------------------
<Bert> text-combine-horizontal property
Florian: We rejected regexp matching in selectors, but you have to do
similar for text-combine
Florian is asking for the ability to make pseudo-elements out of something
that matches a regexp
jdaggett: yes, it's a contextual role, but it's far more finely scoped
fantasai: When you're dealing with text-combine, you're doing it as you're
evaluating the text. It's not part of selector matching.
Florian: Just a question, not an issue.
fantasai: from the spec: " If the content contains any element boundaries
this is treated as text-combine-horizontal: none on the element
and any descendants."
<fantasai> It's a theoretical box, as soon as you notice a boundary you
abort constructing it.
Tab: OK, clear what is supposed to happen, still have editorial reservations.
<br type=lunch>
Received on Monday, 28 November 2011 21:59:02 UTC