- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 30 Sep 2013 19:21:37 -0400
- To: www-style@w3.org
- Message-ID: <CADhPm3sJnPVeCdND4-96r7+e14-Ak+eHRV4N+dTqEGvhu3R=xA@mail.gmail.com>
CSS Writing Modes
-----------------
- Various options were discussed to address the inheritance of
text-combine-horizontal. The group came to three options, but
decided to continue the conversation later to decide between those
choices.
- Koji will update the spec to UTR50
- Rossen check if it's ok to drop support for text-combine-horizontal:
digits 1
Issue 2 in Compositing Spec
---------------------------
- RESOLVED: Close issue #2
- RESOLVED: Everyone review Compositing/Blending, we'll take up the
question of LC publication at next telcon.
=====FULL MINUTES BELOW=======
<TabAtkins> Agenda Request: Go through my Colors spec and get a
definite yay/nay on all the features for moving to the ED.
<SimonSapin> TabAtkins, wouldn't that we the third time we're doing
this, though?
<TabAtkins> SimonSapin: Last time it was just a surprising "Yeah,
let's publish". I know that dbaron had objections, but
don't recall if he was even on the call.
<TabAtkins> I just want to make sure there's no landmines that'll show
up in the future.
<sgalineau> we could split it into one doc for each color...
<dbaron> I don't want to publish 2^24 working drafts.
CSS Writing Modes
-----------------
Scribe: dbaron
<fantasai> http://dev.w3.org/csswg/css-writing-modes/
fantasai: Issue from jdaggett about text-combine-horizontal taking
digits only in the range 2-4 rather than 1-4
jdaggett: 'digits 1' value doesn't have much meaning.
jdaggett: So it means single digits will be upright, but not what the
property is about.
Rossen: ...
fantasai: Key point is that it's rendering it upright.
SimonSapin: Not very useful, but well defined and not really
problematic.
fantasai: Rossen, implementation?
Rossen: Yes, And I believe I've seen content that depends on it.
Rossen: ... expecting automatic tate-chuu-yoku will hit because it's
falling into that range.
dbaron: Issue is that t-c-h says if you have 1 0 2 年1月 you combine
it into [102]年[1]月 or [102]年[11]月
dbaron: If you're saying combine at most 1 digit, you're not doing any
combining.
SteveZ: Suppose I have Latin text, and I want digits upright.
fantasai: That wouldn't work, because if you have a sequence of more
than one consecutive digit, those digits won't be upright.
jdaggett: If an author wants digits upright, they should use
text-orientation: upright.
jdaggett: Yes, it does something in making things upright, but a side
effect rather than combining.
jdaggett: If somebody thinks it's valuable, they should come up with
an example and post to list.
Rossen: Is what fantasai wrote on IRC enough?
fantasai: No. You've seen cases with a single digit upright. If you're
having single digits be upright you're usually also going to
have pairs of digits be upright, and then you'd want digits
2.
fantasai: Not a case we've known people doing.
fantasai: I can't think why people would want single digits upright
but pairs sideways.
fantasai: The number is maximum number in sequence that you'd turn
upright.
jdaggett: Rossen, you want time?
Rossen: Yes, I'll take some time and get back to you.
fantasai: Related issue: we have text about fullwidth numbers that you
said when we apply TCY to it, it should convert out to
ascii.
fantasai: Did you want digits to also include fullwidth digits, or
just ascii digits?
jdaggett: Ascii digits.
glenn: There's ... combinations of digits. Does that include fullwidth
digits?
fantasai: No.
fantasai: The only way you'd get fullwidth digits in TCY is if you
specified the 'all' value.
jdaggett: What's in the spec... is the status of linking the
text-orientation to UTR50.
fantasai: Just need to update reference, everything else as it should
be.
jdaggett: Dfn of text-orientation should be copacetic currently?
fantasai: [reads]
koji: We removed text values.
fantasai: we'll update that
ACTION koji update references to UTR50
jdaggett: ... 20 ... example updated?
fantasai: I didn't see what you meant by the example being incorrect?
jdaggett: Using width variants a normative requirement ... ? ...
fantasai: Only required to use partial width characters if composition
doesn't otherwise fit.
fantasai: Say I have ".9". I can just put that without requiring
turning on halfwidth glyphs.
jdaggett: There's no font that's like that
jdaggett: The minimum width is typically half the width
jdaggett: Typically digits in japanese fonts are fixed width, not
proportional. Example just doesn't make sense.
fantasai: If the text fits without need for compression within 1em,
the ua is not required to do any compression.
fantasai: The implementation is allowed to check if it needs to use
compression and then if it needs to use halfwidth glyphs.
jdaggett: In the known universe of japanese fonts either you're going
to have to do compression or the font by default has
halfwidth glyphs.
fantasai: ".9" will often fit without using halfwidth forms.
jdaggett: That's only in the context of the all value, not in the
context of digits.
fantasai: The compression algorithm not specific to digits.
jdaggett: The cases you're talking about only in the all case.
fantasai: ...
jdaggett: I'll look at it again and we'll discuss on the list.
fantasai: So we have one issue out on action from Rossen.
ACTION Rossen check if it's ok to drop support for
text-combine-horizontal: digits 1
jdaggett: What are we doing about inheritance of
text-combine-horizontal?
fantasai: We don't have a solution for it.
fantasai: dbaron's proposed solution is that 'all' only takes effect
if parent isn't all.
fantasai: koji had some content with text with t-c-y all containing
inside of it a span containing all of the text inside,
expecting all the text combined. But this wouldn't be
combined due to element boundary.
koji: What do you think about allowing elements within
text-combine-horizontal?
fantasai: What to do about inline-block with table and some images?
koji: Tables not realistic, but are realistic html use cases
koji: Allowing elements would be good
SteveZ: Example of CO2 in a newspaper (with subscript)
SteveZ: argument for allowing markup inside TCY
<Bert> CO<sub>2</sub>
<ChrisLilley> Unless you use the opentype features so get a subscript
2, or use the unicode subscript 2.
dbaron: Non-replaced inline elements only?
SteveZ: Plenty of examples in Japan with things with a trademark
symbol of some kind embedded; not so likely inside TCY but
possible.
SteveZ: Many signs that begin with a mark.
koji: Still inline, though.
SteveZ: But an image, so replaced.
dbaron: Not clear to me, if you're having variant font sizes between
things that are supposed to go in TCY, what are you supposed
to do to the different font sizes?
glenn: Similar problem in Arabic with eye-of-alla.
glenn: A number of OpenType fonts substitute different sizes of digits
to form groups that can fit into this.
glenn: Maybe something that's dealt with in font itself.
glenn: Looks for enclosing circle followed by N digits, and has
entries for 1, 2, or 3 digits.
glenn: so font itself might want to select digit variants
dbaron: I feel like we should not try to add complexity to this
document right now
jdaggett: Examples koji brings up are relevant, but want to make sure
it works without worrying about complicated cases.
SteveZ: Ok with that provided that the way in which we limit it would
allow us to extend what's allowed in that in the future.
SteveZ: I'm ok if the limitation on content of 縦中横 area is something
we could relax in a future draft, and a note saying it would
be nice to allow markup inside 縦中横 if we can figure out how to
do that.
jdaggett: Sounds fine to me
koji: I'm not strongly arguing allowing elements, but want to preserve
what's working today.
koji: What's the downside of making this inherit?
koji: I'm happy of making this inherit and keep existing behavior.
fantasai: You get some very interesting behavior.
dbaron: I think downside of having inherit makes it nearly impossible
to extend to allowing markup in future.
koji: But text-combine-horizontal only works in vertical context, and
inside is horizontal context
<fantasai> <outer style="text-combine: all"><span>tcy</span></outer>
fantasai: Author expectation is that above markup should work.
<fantasai> <outer style="text-combine: all">a<span>bc</span></outer>
<fantasai> a
<fantasai> [bc]
fantasai: But if instead something like above.
fantasai: Then I get a followed by [bc] as a unit, which is not
expected behavior.
koji: But if you rotate bc by not inheriting, it's still not expected.
fantasai: If we do the case where pretend we're not an inheriting
property, then [bc] will just be sideways and none of it
will be upright
* Bert thinks that, until we have href on all elements, it will be
pretty common to have an extra <a> inside.
SteveZ: Could we define the 縦中横 piece to behave like underline does?
SteveZ: So if it's turned on it's turned on for the entire span that
it's on?
fantasai: The digits value needs to be inherited but the all value
ideally should be inherited.
ChrisL: Sounds like you need two properties.
fantasai: One proposal was that text-combine-horizontal a shorthand
for 2 longhands that authors wouldn't use
ChrisL: What's the downside other than being 2 properties?
fantasai: It's 2 properties.
ChrisL: Then just do it.
koji: It broke my case, right?
fantasai: Yes, your case is still broken
dbaron: Not any better than the other solution?
SteveZ: Then the outer one can behave like underline. Once you turn it
on, inner levels don't add any more 縦中横. ...
koji: Allowing elements inside?
SteveZ: Yes.
koji: That's what dbaron doesn't like.
SteveZ: Once you turn on underline it applies to everything inside.
SteveZ: If you define all to behave that way then make it inherit and
it doesn't hurt.
fantasai: dbaron had a suggestion that doesn't have separate
properties. Look; if your parent has 'all', then you pretend
like you're none. And you just have the one property, and we
could split later without breaking content.
fantasai: That solves the problem of what's establishing the
縦中横, but still have the problem of inline elements
inside it.
ChrisL: The thing about "if your parent has this than do that" sounds
like a UA rule using a selector.
fantasai: Can't select against properties.
koji: If the solution is this complex then the only downside of
keeping inherit is a<span>bc</span>.
koji: I don't think anyone would author a<span>bc</span>
dbaron: If that's not a problem, then I'm not convinced why the other
thing is a problem.
fantasai: It has to work because of content.
koji: Probably some converter generates that.
koji: Some converter puts <span> directly inside TCY span.
dbaron: What if the rule disallowing inlines is changed to say that
all the text has to be in the same element parent, but can
allow inlines?
fantasai: Or you could allow display:inline?
SteveZ: I think dbaron's solution is fairly reasonable, solves koji's
problem.
Bert: Somebody sees it, draws conclusion from that, and then finds it
doesn't work anymore.
Bert: The spec explains it, but...
[Bert gave example of multiple nested spans with all content, vs.
trying to make one char blue one char green]
dbaron: If we want to get a spec out the door, we sometimes need to
solve a problem with a not very nice solution.
jdaggett: And keep in mind we're talking about 2-4 character spans
SteveZ: I just sent an email to the list with an 8 character span in a
縦中横.
* Bert to SteveZ: your message was refused by the mailing list: too
big. Can you make it smaller or put the image somewhere else?
Israel: Does the solution allow for H<sub>2</sub>O case?
Steve: no
fantasai: One thing we could do, maybe not ??? idea, if you have any
kind of inline boundaries you still do TCY, but UA allowed
to do graphical scale and not do anything smart.
fantasai: Then generator generating markup in Koji's case would not
get pretty results, but would still work.
fantasai: Hopefully relatively straightforward?
fantasai: Rossen, thoughts? You're an implementer.
Rossen: I'm pretty sure we inherit digits.
Rossen: And I believe we don't inherit 'all' so we have conditional
logic based on the value.
Rossen: Not awesome, but it solves current problem.
SteveZ: I like David's solution, all inherited but if you have parent
that has all you ignore it.
Rossen: So you get correct layout but the property from OM is still
inherited.
SteveZ: The computed value in that case is none then it's effectively
none.
dbaron: The computed value is still all.
Rossen: In our case we did by ...
SteveZ: I think either way is the right answer; the result seems to be
the same.
SteveZ: Basically saying nested alls don't have any effect.
SteveZ: This is just different ways of saying that.
SteveZ: I don't want to rotate internal one again.
koji: It won't combine again, having no effect is just fine.
Scribe: Fantasai
dbaron: My proposal was that you slightly relax restriction on not
having markup inside, say that you can have markup inside if
all of the text is in the same parent.
dbaron: You could actually get same result by changing rule on when to
void all.
dbaron: You're limited to text and inline elements
dbaron: And all of the text has the same parent element.
<Bert> So <tcy><span/><span/><span>12</span></tcy> is OK, too
dbaron: Alternative proposal: Allow 'display: inline' elements, but if
there are any, scale-x the result instead of trying to do
fancy things.
dbaron: Alternative-alternative proposal is, void the all if your
parent is also all unless you're the only child of the parent.
dbaron: Not element-tree child, DOM-tree child
dbaron: Though collapsible whitespace might be ok.
fantasai: That makes sense to me. I can write that up.
dbaron: One thing that makes TCY dangerous is that if you have things
inside the markup, you have to worry about borders and padding
on those inlines, backgrounds, etc.
dbaron: Whereas if there's only text
dbaron: the element that establishes the TCY is still behaving as if
it's vertical
<SimonSapin> DOM-tree child meaning that text also counts as a child?
dbaron: New proposal saying that in the case Koji wants to work, you
end up with the TCY happening on the innermost element, rather
than the outermost element
dbaron: which avoids all that complexity.
rossen: If you put inline background differently on 1, 0, 2, then,
what would be the effect?
rossen: ...
dbaron: This is the thing we're trying to not deal with in this level.
rossen: Or say 'all' doesn't inherit.
fantasai: That's a different problem, we already solving that.
SteveZ: Why can't we format the string with whatever markup, and then
possibly compressing it if I need to?
dbaron: I think jdaggett is better-placed to answer that. A lot of
this will be implemented using font features.
dbaron: You'll have calculations with regard to does it fit, what
scaling do we apply to the characters?
dbaron: If you have to deal with inline margins and padding, that
makes it much more complicated.
SteveZ: Agree it becomes more complex.
SteveZ: One simple way out of that is, you simply try to set it to
fit, and then squeeze it and live with whatever result is
dbaron: Does the spec require scaling in any other cases?
fantasai: Yes, if you don't get narrow enough glyphs to fit into 1em,
you have to scale the result
SteveZ: ...
jdaggett: Up to the implementation.
jdaggett: In the case of having appropriate variants for all glyphs,
you must use those.
jdaggett: If not available, then UA does what it thinks is best.
SteveZ: If I allow borders and backgrounds around components
SteveZ: I could just set it horizontally, see if it fits, and if it
doesn't fit scale it down.
SteveZ: Borders will change, but oh well.
jdaggett: Borders inside TCY? really?
SteveZ: Not proposing that as a use case, just as a reasonable
fallback.
SteveZ: Question is, trying to limit what can be inside TCY
SteveZ: Every time we try to limit, has some disadvantages.
SteveZ: So question is, what if we don't limit? Would it be a big
implementation burden? Produce awful results?
SteveZ: If not too awful, and not so difficult...
koji: What about alternate heights?
SteveZ: might need to compress in height direction as well
koji: to 1em
SteveZ: Rossen?
koji: My first vote is just keep it inherited as it is right now.
koji: My second is dbaron's first proposal.
Scribe: TabAtkins
[fantasai is listing the options on the whiteboard]
<koji> Option A) Break TCY if contains elements, inherit to children
<koji> Option B) Break TCY if contains elements, inherit to only child
<koji> Option C) Accept all 'display:inline' content, scale to 1em
square
fantasai: [option a]
<Bert> <tcy>a<q>bc</q></tcy>
fantasai: That means that Koji's case works,
fantasai: But it also means that if you have an element with
<tcy>a<q>bc</q></tcy>
fantasai: The presence of "a" means the outer one won't form TCY, but
the inner one will.
fantasai: You have to rely on people not using TCY in cases like this.
SteveZ: But I can't, so it breaks.
fantasai: The only case you need to do this is when it's automatic,
for accessibility.
fantasai: [option b]
<Bert> <tcy><q>xyz</q></tcy>
fantasai: "If my parent has 'all', I won't form TCY, unless I'm the
only child of my parent."
fantasai: [option c]
<Bert> s/1/1em square/
fantasai: Take all display:inline content and generate TCY. If it
doesn't fit, we scale it to 1.
koji: We probably have to disable ??? or tcy ??? for option c.
[some discussion of examples on the board, which are way too small for
me to see from this distance]
SteveZ: [something about text emphasis]
<Bert> -> http://dev.w3.org/csswg/css-text-decor-3/#text-emphasis-propertytext-emphasis
in ED
fantasai: No, it's an inherited property, not like text-decoration. If
you change font size, it'll move with it.
fantasai: The escape hatch to put arbitrary stuff in a TCY thing is to
just use inline-block instead.
fantasai: Instead of actually using TCY
[???]
szilles: You'd have an inline-block where you're using font
substitution to get squished digits.
<Bert> [Discussion of differences between inline block and TCY]
fantasai: It'll also be underlined, for example, as a single glyph - a
strikethrough will be vertical.
fantasai: Other Koji point - text emphasis treats TCY as a single
character.
fantasai: If you allow arbitrary content, you won't get the right
behavior
fantasai: if you scale it.
fantasai: This is why we wanted to limit TCY only to text - all these
issues start to crop up.
dbaron: I don't feel like we have use-cases for this.
stearns: CO_2
fantasai: That's solvable with unicode codepoints for superscript and
subscript characters.
SteveZ: Not all fonts have those.
fantasai: If it doesn't, sub/sup will look ugly anyway.
SteveZ: If do C, with a couple of exceptions you don't have to do
anything special.
SteveZ: The other options require exceptions.
koji: Limiting to characters makes code 1 (?) simpler.
koji: Code only needs to measure text, not elements.
SteveZ: To do line-breaking, it already needs to do all that stuff.
SteveZ: You already have code to do inline text layout. That has
everything you need.
Bert: You don't know how long the line is going to be, as you have no
'width' property.
SteveZ: Layout as if the space was infinite, then see if it fits in
the em. If it doesn't fit, you compress.
Bert: That doesn't work for floats, though - you need containing block
size.
SteveZ: Yes, but it's typically just a few characters.
[agreement to do the rest of the tcy conversation on the side]
dbaron: This is what's holding up Writing Modes from CR?
fantasai: This, and some cleanup for orthogonal flows (but I don't
think that should hold up LC).
SteveZ: Could you add these examples and discussion in the thread?
fantasai: Okay.
fantasai: I still think we should try and solve this in this F2F.
<Bert> (I meant to say that we have to specify in case C what CB you
use for the layout, before it gets scaled down.)
Issue 2 in Compositing Spec
---------------------------
Scribe: fantasai
sylvaing: Issue 2 in compositing spec
sylvaing: Is specifically about background-blend-mode property.
sylvaing: Feedback on that was that instead of specifying backgrounds
and blending the backgrounds, could stack elements and blend
those.
sylvaing: So question is, whether property is worth it?
sylvaing: Basic scenario is, element, couple backgrounds, image and
color, gradient, etc.
sylvaing: You want to blend them together.
sylvaing: Suggestion is maybe don't need background-blend-mode
property and just do it with elements.
sylvaing: That seems pretty sub-optimal.
sylvaing: We've got to have a bunch of wrapper elements, position them
together.
sylvaing: Things get more complicated if you want to change blending
or backgrounds based on user interaction.
sylvaing: We expect that the use case for this in many cases will be
changing backgrounds.
sylvaing: Or a similar to desire to apply opacity.
sylvaing: People want background color, something on top of it,
gradient, blend them, etc. etc.
sylvaing: If you have to do that with stack of elements, it's a lot
more work.
sylvaing: People will either not do it, or use java script plugin or
something to do it.
fantasai: So you want to remove issue 2 and close as no change.
fantasai: OK, so are there any objections to that?
dbaron: I guess not?
hober: Who raised the issue?
sylvaing: Don't know?
leaverou: Are there really that many use cases, and can't wait until
Level 2?
sylvaing: Doesn't seem that hard to implement.
leaverou: This is for individual background layers, right?
leaverou: We had discussion on different modes for borders,
backgrounds, etc.
sylvaing: Think that was for filters
krit: We had that in the spec at one point
<cabanier> That was for the different parts of the box model.
<cabanier> There are multiple images so you need a list.
sylvaing: It's very common for pages to update background color on
hover or active etc.
sylvaing: Once you have blending, people still do that, say blend
color gradient + ?
<cabanier> We have a demo that shows the feature.
sylvaing: If the only option to do that is stacking bunch of elements,
add lots of divs
sylvaing: Question then becomes, is the implementation so heavy that
we should force to another level?
sylvaing: Doesn't seem so.
ChrisLilley: So you're saying that if we don't do this now, we ask
people to make bad content
sylvaing: Yeah
sylvaing: [gives more examples, this time with scrolling]
fantasai: What were dbaron's reservations?
dbaron: I'm not convinced it's all that useful, but I guess it's
easier than the other stuff in the draft, and therefore might
be the only thing we get for awhile.
<cabanier> the feature is about to land in mozilla
fantasai: So you're concerned that background-blend-mode will be
implemented and not mix-blend-mode, and so worried people
will put too much content in backgrounds or something?
dbaron: I'm ok with it. My bigger concerns are with mix-blend-mode,
but that's also where I think the useful stuff is.
dbaron: Have lots of concerns with regards to mix-blend-mode, but
think that's where all the useful stuff is.
fantasai: Do you want to put a note telling implementers to work on
mix-blend-mode first?
dbaron: Don't think mix-blend-mode is ready.
dbaron: Fine to remove issue.
RESOLVED: close issue #2
<cabanier> Yes, would like to know the issues
dbaron: Some of issues with mix-blend-mode were on www-style, also
wrote up some as a blog post:
http://dbaron.org/log/20130306-compositing-blending
dbaron: What does mix-blend-mode apply to these days?
sgalineau: All elements?
sylvaing: All elements.
dbaron: Does it estimate a stacking context?
sylvaing: Yes
rik: yes
dbaron: If it forces them to establish a stacking context, I have
fewer concerns
dbaron: Basic problem with mix-blend-mode is that, and I tried to
explain in the blog post, we've been very precise about
describing painting order
dbaron: But that assumes that composite is an associative operation
dbaron: Which is true until you have blend-mode.
rik: Or opacity.
dbaron: No, it's true with opacity.
dbaron: True until you have the stuff in the spec.
dbaron: Can get some rounding errors, but in practice people don't
care about that.
dbaron: My issue with this spec is that, in order for this to be
interoperable, we need parentheses in Appendix E
dbaron: i.e. not just the list of layers, but which pairs composite in
what order.
dbaron: Might just be that we pretend it's a postfix op or a prefix
op, and all one big operation like that.
dbaron: But that's not really the way it works in implementations
right now.
dbaron: And for this to be interoperable, need to agree on grouping in
Appendix E.
dbaron: Problem with doing that is that there are a lot of browser
optimizations.
dbaron: that interact with this stuff
dbaron: We could disable optimizations when you use this stuff, and
probably will need to do that.
<cabanier> there is really no different of drawing with opacity and
drawing with a blend mode.
<cabanier> what is the different between drawing an element with
opacity and an element with a blend mode?
<cabanier> there is a difference where you need to know what you draw
onto.
dbaron: but
dbaron: [...]
krit: ... is defined in the spec
dbaron: where is it defined?
krit: Defined in CSS
dbaron: It's not defined in CSS. We define the layering, but not the
grouping.
dbaron: I think you're assuming that CSS implicitly defines grouping
from the bottom up, in other words that the first composition
is the lowest layer with the next lowest, and then the third
lowest with that, etc.
dbaron: You're probably implicitly assuming that the defined layers
are composited in order from the bottom up.
<cabanier> Ok. I think that's what David is saying. You need to say
that you have to draw in order in order for blending to
work.
<cabanier> (I think everyone basically does that)
dbaron: I think it is worth testing if that is actually what
implementors do.
dbaron: There are definitely some things in CSS that *have* to form a
layer.
krit: Right. These form a stacking context.
dbaron: Right, but there are many other things that make a stacking
context.
krit: Like transforms.
dbaron: So do we want only the visual things to form groups, or all
stacking contexts?
<SimonSapin> + is associative <=> (a+b)+c == a+(b+c)
* TabAtkins Simon, + is a bad example - it's also commutative. String
addition is a better example.
<SimonSapin> TabAtkins, fair enough
krit: Every property that creates a stacking context today creates a
group as well.
TabAtkins: I think that's what we wanted to do when we last talked
about this in SVG as well.
sgalineau: And the spec today defines that already.
cabanier: The stacking context of the thing you're blending creates a
group too.
dbaron: Okay. I'll need to review this document.
dbaron: It's progressing.
cabanier: Can we go to LC?
dbaron: I'd like more time to review.
dbaron: Last I looked there were parts of the spec that were very
difficult to understand, and I'd like to see if that was
addressed.
dbaron: So I'd like to have more time to review.
dbaron: I can try to do it by the next telcon.
* fantasai suggests, in the spirit of renaming things, that we drop
the -mode.
<TabAtkins> http://dev.w3.org/fxtf/compositing-1/ is the document you
want to take to LC?
cabanier: ^
* fantasai might be biased against -mode properties from having worked
off of old CSS3 Text drafts, though.
<dbaron> I think "blend mode" is an existing term.
RESOLVED: Everyone review Compositing/Blending, we'll take up the
question of LC publication at next telcon.
Meeting closed.
Received on Monday, 30 September 2013 23:22:06 UTC