W3C home > Mailing lists > Public > www-style@w3.org > September 2013

[CSSWG] Minutes Paris F2F 2013-09-12 IV: Writing Modes, Issue 2 in Compositing Spec

From: Dael Jackson <daelcss@gmail.com>
Date: Mon, 30 Sep 2013 19:21:37 -0400
Message-ID: <CADhPm3sJnPVeCdND4-96r7+e14-Ak+eHRV4N+dTqEGvhu3R=xA@mail.gmail.com>
To: www-style@w3.org
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

This archive was generated by hypermail 2.3.1 : Monday, 30 September 2013 23:22:07 UTC