W3C home > Mailing lists > Public > www-style@w3.org > December 2015

[CSSWG] Minutes Telecon 2015-12-09 [css-align] [css-flexbox] [css-backgrounds] [css-scoping]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 9 Dec 2015 19:46:02 -0500
Message-ID: <CADhPm3t_Y1hbMCd7Be234__7sq=gitLnBhOY7wETOJGu4aaRaA@mail.gmail.com>
To: www-style@w3.org
Telecons on 23 and 30 Dec
-------------------------

  - All working group members should note on the Doodle (available
      here: https://lists.w3.org/Archives/Member/w3c-css-wg/2015OctDec/0158.html)
      if they'll be available for the 23 and 30 December calls.

Interoperability issues on border-image
---------------------------------------

  - TabAtkins said that he had filed bugs and is putting pressure on
     the teams handling gmail and calendar so that they no longer
     rely on the improper behavior.
  - Several implementors said they would be willing to change back
     to the spec behavior once the two Google properties are fixed
     as long as there isn't a long tail of other sites relying on
     the bug.
  - TabAtkins will report back to the group in January with any
     updates on a timeline for the fixes.

Flexbox
-------

  - RESOLVED: Accept the change for issue 5 (explained here:
              https://lists.w3.org/Archives/Public/www-style/2015Dec/0018.html)
  - No one was prepared to talk about if the proposed approximation
      was the right solution to the problem with finding the
      intrinsic cross-sizes of flex items.
      - Implementors should review the proposal (available here:
          https://lists.w3.org/Archives/Public/www-style/2015Dec/0055.html)
          before next weeks' call and respond on the mailing list.
          Anyone who hasn't given an opinion on the mailing list may
          be asked to give one on the call so that a decision can be
          made quickly.
  - RESOLVED: Accept the change for issue 3

Align
-----

  - Most of the align topics on the call were about changing items
      from 'computed to' to 'behaves like'
      - These items (topics: 3-7) will all be deferred to next week
          to get more review.
  - RESOLVED: Add the 'normal' keyword with bikeshed pending.

Scoping @font-face defined in shadow DOM
----------------------------------------

  - TabAtkins brought his proposal to address the possibility of
      font name being duplicated inside and outside a shadow DOM.
      - The proposal would create a mapping where the external font
          is translated into a guaranteed unique name when passed
          into the shadow DOM.
  - dbaron raised the possibility of instead using a function that
      gets the name from the scope, which was a cleaner solution.
  - TabAtkins will write-up a new proposal using functions and send
     it to the mailing list for review.

===== FULL MINUTES BELOW ======

Agenda: https://lists.w3.org/Archives/Public/www-style/2015Dec/0116.html

Present:
  Rossen Atanassov
  Tab Atkins
  David Baron
  Adenilson Cavalcanti
  Greg Davis
  Elika Etemad
  Simon Fraser
  Daniel Glazman
  Tony Graham
  Dael Jackson
  Peter Linss
  Myles Maxfield
  Ryosuke Niwa
  Edward O'Connor (IRC Only)
  Simon Pieters
  Anton Prowse
  Alan Stearns
  Greg Whitworth
  Jeff Xu

Regrets:
  Bert Bos
  Angelo Cano
  Tantek Çelik
  Dave Cramer
  Florian Rivoal
  Ian Vollick
  Johannes Wilm

scribe: dael

Telecons on 23 and 30 Dec
=========================

  astearns: It's 5 after, we should start.
  astearns: Any last minute items?
  glazou: I sent one to the mailing list about 20 min ago.
  astearns: About end of month meetings?
  glazou: Yes.
  astearns: That would be interesting thing to have people add to
            IRC, but we'll have to use the mailing list since quite
            a few people expressed regrets for today.

  astearns: Can anyone who would like a meeting on 23 Dec put +1 in
            IRC
  <fantasai> +1 I'm free
  <bradk> -1
  <TabAtkins> -1, totally gonna be with family that week
  <dael> +1 I'm available
  <gregwhitworth> -1
  <zcorpan> -1
  <glazou> +1 doable
  <hober> -1
  astearns: Like I said, I'll put this to the private mailing list
            too.

  astearns: And now for 30 Dec. Who is available?
  <glazou> -1 for 30th
  <TabAtkins> +1 for the 30th
  <dael> +1
  <fantasai> +1 I'm free for 30th
  <zcorpan> -1
  <astearns> +1 for 30th
  <bradk> -0.5
  astearns: Okay.

  TabAtkins: Do we want to do a doodle?
  fantasai: I can set one up.
  <fantasai> Member-only link
https://lists.w3.org/Archives/Member/w3c-css-wg/2015OctDec/0158.html

  smfr: Can we move item 9 to the beginning? I have to drop.
  astearns: Sure.

Interoperability Issues on border-image
=======================================

  <astearns> https://lists.w3.org/Archives/Public/www-style/2015Dec/0080.html
  TabAtkins: Chrome has a bug where we'll honor border-image even if
             your border-style is set to none.
  TabAtkins: That violates the spec and causes problems for other
             browsers. I think calendar and gmail rely on it so Edge
             copied and I think FF is considering it. We're bugging
             internal to fix this, but does anyone think this is so
             important we can't wait a bit to get the internals to
             fix?
  gregwhitworth: It's good to get it fixed, but no rush. It would be
                 great to see more equal, but sooner or later we're
                 going to be where we can't do web compat.
  gregwhitworth: Is webkit still working toward the change?
  smfr: Webkit is same as blink.
  gregwhitworth: And will you guys change?
  smfr: I think so, but this is two high level sites broken. I'm
        worried there's a long tail of ones that will break.
  gregwhitworth: We had this a long time. It was the Google
                 properties that forced our hand. I don't think
                 there's too much of a long tail, but maybe Firefox
                 is aware of more sites.

  TabAtkins: So we have bugs on gmail and calendar and we'll make
             sure there's pressure on them to fix. There might be
             others, but those two big properties won't rely on it.
  smfr: The patch that fixed the bug in webkit did have to change a
        lot of tests since a lot had been written to assume the
        broken data.
  smfr: I think webkit would be willing to change behavior once the
        Google properties are fixed. We'll see how it goes.

  fantasai: Related note, I think Boris was complaining on Twitter
            that Firefox was having to implement a lot of -webkit
            because of the broken Google properties. Can we get that
            to be a priority to fix to never code -webkit specific
            when there's spec? How high would that have to go to be
            on the to do list next year?
  TabAtkins: I don't know, but I can get Alex Russell on the case.
  <gregwhitworth> Alex Russell to the rescue.
  fantasai: Okay. If you need more info ping Boris.

  <zcorpan> border-image
https://www.chromestatus.com/metrics/css/timeline/popularity/43
            with border-style:none
https://www.chromestatus.com/metrics/feature/timeline/popularity/1026
            (but this counter hasn't hit stable yet iirc)

  plinss: Can I suggest when implementors violate specs for Google
          properties they whitelist it for just those Google
          properties and not the web in general?
  gregwhitworth: It sounds like the CV list hell we're in at times.
                 All the sudden you're enabling...you're going to
                 enable so you might as well do it for everyone.
  TabAtkins: We have site specific code for when we had something we
             wanted to change and a big site would break.
  astearns: But when it's something like this where we're expecting
            the change in the Google properties, we would get more
            data if we whitelist them and move everyone else.

  gregwhitworth: So should this be on the agenda for a call in early
                 January to see where we're at?
  TabAtkins: I'm not sure what the group can do, but if you're
             implementing something for a Google property, let us
             Googlers know.
  gregwhitworth: But for this thing tell us where things are?
  TabAtkins: Yeah, that's cool.
  astearns: So we're in a bit of a waiting game. Let's move on.

Flexbox
=======

align-items propagation to align-self on abspos
-----------------------------------------------

  <astearns> https://lists.w3.org/Archives/Public/www-style/2015Dec/0018.html
  TabAtkins: align-items in flex and grid sets to propagate to align
             unless you set to align-self. When we broadened align
             and justify to work on everything, we want them to work
             on for example abspos, but we have to deal with the
             default of abspos right now.
  TabAtkins: The cleanest way to do it is make the default not take
             from align items so the alignment behavior on a
             container doesn't mess with abspos, but you can align
             explicitly. This is a minor change from flexbox, but
             Christian who brought this up, is fine with it.
  TabAtkins: If you have an abspos whose containing block is flex it
             will no longer be effected by align items.
  fantasai: Which for flexbox only has an effect on the staticpos.
  fantasai: The flexbox doesn't have to be the containing block, but
            it has to be the static position.
  TabAtkins: There's a big confluence to make this happen. If
             there's any concerns, speak up. We've made the change.
  TabAtkins: Also, we're not even interoperable on this case yet.

  astearns: Do you want a resolution?
  TabAtkins: Flexbox is mature enough that any change of this
             magnitude needs a resolution. We're trying to be
             responsible.
  astearns: Any objections?
  <fantasai> https://lists.w3.org/Archives/Public/www-style/2015Dec/0018.html
  fantasai: The reasoning is in the above e-mail.
  astearns: Seems reasonable.

  RESOLVED: Accept the change for issue 5

Intrinsic cross-sizes of flex items
-----------------------------------

  <astearns> https://lists.w3.org/Archives/Public/www-style/2015Dec/0055.html
  fantasai: I don't think we can close on this. It's finding the min
            and max content size of a column flex container with
            multiple lines. You have a column flex with a max
            height, they wrap until you run out of items.
  fantasai: There's two issues. One is that when you're trying to
            figure out what is the intrinsic size, how for you
            calculate? And does the flex container wrap one column
            or all?
  fantasai: Wrapping the first doesn't make sense, you're asking it
            to be shrink wrapped, but Firefox and Blink are not
            currently wrapping all the columns, stuff overflows.
  fantasai: IE does the calc correctly so we get good results.
  <gregwhitworth> Blink wrap first item, Gecko first column, Edge
                  around all columns.
  <Rossen> we aligned to the Chrome behavior for Edge in the
           min-intrinsic case due to compat
  <Rossen> we're not opposed to revert back to the IE behavior though

  fantasai: The other problem is how do you find the size of these
            columns, the width and height, given there's
            interdependencies. If you want to do 100% correct you
            have to put it in, size, put in another, see if it fits,
            resize etc.
  fantasai: All browsers are doing a heuristic that gives you a
            sensible answer. They find the largest intrinsic size
            and fit everything into that space. So if you have a
            really long word that controls all the columns, they'll
            all be that wide. It's pretty good for most cases.
  fantasai: It would be good to have a better answer, but this works
            pretty well. We're okay putting it in the spec, but it's
            a heuristic.
  fantasai: That's the discussion happening now. We need to hear
            from more implementors. I don't think we can resolve on
            the call because at least Christian is upset with our
            proposal. Microsoft is fine with it, so I don't know
            what to do with that discussion.

  astearns: Is the heuristic that you would be considering putting
            in the spec detailed enough on the mailing list for
            people to evaluate?
  TabAtkins: Yes. It's in the message in the agenda.
  TabAtkins: It says the approximation.
  fantasai: Our question is, is the approximation sufficiently
            useful for us to specify and can we come up with
            something better?
  astearns: Are there people willing to talk about this on the call,
            or should we go back to the mailing list?
  TabAtkins: We need to close the issue soon, so mandatory yea/nay
             next meeting?
  astearns: Sounds like a good plan.
  astearns: We'll put this on next week's agenda to give
            implementors time to come up with an opinion. They can
            either express on the mailing list or get put on the
            spot next call.
  fantasai: I prefer the mailing list.

  <Rossen> fantasai, can you share the test cases please?
  <fantasai> Rossen, for the flexbox issue? Sure
  <Rossen> fantasai, yup

Align
=====

justify-content: auto -> start / stretch (on grid / flex items)
---------------------------------------------------------------

  <astearns> https://lists.w3.org/Archives/Public/www-style/2015Sep/0097.html
  TabAtkins: Auto computing to start or stretch if you're grid or
             not. There's a lot of issues dbaron had about things
             computing to things. This one is justify content needs
             to default to stretch for grids but start for
             everything else.
  TabAtkins: Previously it computed to start or stretch, now it just
             stays as auto and acts like start or stretch at layout
             time. Is that okay?
  TabAtkins: Larger issue...is anyone willing to say anything about
             align spec, rubber stamp us, or take a week to review?
  <fantasai> Summary of all the alignment issues:
  <fantasai> https://lists.w3.org/Archives/Member/w3c-css-wg/2015OctDec/0143.html
  <fantasai> Tab and I just went through a bunch of Box Alignment
            issues. There were
  <fantasai> a lot of concerns about values computing to other
             values, with the
  <fantasai> suggestion being to just have used-time equivalence.
  <fantasai> The cases brought up were:
  <fantasai> * justify-content: auto -> start / stretch (on grid /
             flex items)
  <fantasai> https://lists.w3.org/Archives/Public/www-style/2015Sep/0097.html
  <fantasai> * justify-content: stretch -> flex-start (on flex items)
  <fantasai> https://lists.w3.org/Archives/Public/www-style/2015Nov/0327.html
  <fantasai> * 'left' and 'right' -> 'start' (when operating in the
             wrong axis)
  <fantasai> https://lists.w3.org/Archives/Public/www-style/2015Nov/0280.html
  <fantasai> https://lists.w3.org/Archives/Public/www-style/2015Nov/0284.html
  <fantasai> * 'flex-start' and 'flex-end' -> 'start' and 'end' (on
             non-flex-items)
  <fantasai> [rough corollary to the previous item]
  <fantasai> * align/justify-items: auto -> start/stretch (depending
             on 'display')
  <fantasai> #2 in
https://lists.w3.org/Archives/Public/www-style/2015Dec/0061.html
  <fantasai> Though we don't have a strong position, we're in favor
             of making these
  <fantasai> changes so long as the WG approves.

  dbaron: I'm happy with changes that compute less. I haven't looked
          in detail.
  fantasai: Anyone else have an opinion?
  TabAtkins: We can do a final agreement next week so dbaron can
             review explicitly and anyone else that cares can.

  astearns: Is css-align at the point where we need resolution on
            these things? Or can you make the changes and people
            review with time.
  TabAtkins: They're changes in behavior to flexbox and grid in
             several cases. Minor where you used to see one keyword
             and now you get auto, but still.
  TabAtkins: If it was internal, no, but this effects flex and grid.
  fantasai: We want someone that isn't us to review.
  <gregwhitworth> I'll take a look at it as well
  astearns: gregwhitworth will take a look.
  TabAtkins: mmmkay
  astearns: dbaron will you have time in the next week to look at
            these changes?
  dbaron: Possibly. It's hard to know.
  <fantasai> dbaron, they're summarized above

  astearns: Does that mean, TabAtkins and fantasai, that items 3-6
            are all in that state?
  TabAtkins: And 7.

'auto' values in align-items/align-content/justify-items/justify-content
------------------------------------------------------------------------

  fantasai: There's one issue we didn't cover.
  fantasai: Where we renamed to normal.
  TabAtkins: Ah, that didn't show up.
  astearns: Link?
  fantasai: Let me see if I can find it.
  TabAtkins: It did show up in an e-mail.
  <fantasai> https://lists.w3.org/Archives/Public/www-style/2015Dec/0061.html
  fantasai: I think I found it ^

  fantasai: To go over it, TabAtkins and I were going through
            computed computation. We noticed the 'auto' on
            align/justify was get this value, but in other places it
            was do magic.
  fantasai: We added the 'content' keyword to do the magic last
            time, but we'd like to avoid it in align. So we'd like
            to rename 'auto' to 'normal' where it's do the magic.
            The magic is depending on display pick a proper default.
            And then remove some computation that doesn't need to be
            there.
  fantasai: That's our proposal. Keep 'auto' on align-self and where
            we have a new auto that means do the right thing for the
            display, change that keyword to 'normal'.
  fantasai: Thoughts?
  fantasai: Good idea, bad idea? We think TabAtkins and fantasai are
            always right?

  dbaron: Is there a more specific name then 'normal'?
  fantasai: I don't know. The keyword means pick a default alignment
            appropriate to this display type.
  TabAtkins: Some are start, some are stretch.
  fantasai: It also means don't make me a BFC for the blocks.
  <fantasai> (For align-content)
  TabAtkins: If anyone can come up with a more descriptive name,
             great. 'Normal' has been in a few other properties for
             similar reasons so it seemed appropriate there.
  <dbaron> it feels a little like there isn't a philosophy behind
           what's 'normal' and what's 'auto'
  <TabAtkins> dbaron: Yeah, there really isn't. :/
  * bradk doesn't feel strongly without delving into it more.

  <SteveZ> What about "displaytype" as the name
  <fantasai> It's not a display type, it's an alignment
  astearns: SteveZ mentioned one on IRC.
  <fantasai> align/justify-self: auto | normal | start | end | etc.
  <fantasai> align/justify-items: normal | start | end | etc.
  <fantasai> align/justify-content: normal | start | end | etc.
  fantasai: It wouldn't work because it's an alignment value. Their
            properties would look like ^
  fantasai: It will eventually...the used value will be start or end
            or stretch, not a display type. Which it is depends on
            the display type, but it's the condition not the effect.

  astearns: It seems the purpose to 'normal' is something we use
            'auto' for in other cases.
  fantasai: We can't use 'auto' because 'auto' is taken.
  TabAtkins: Unless we're willing to do a compat break on flexbox
             and change its initial value.
  fantasai: I think that might break stuff, bad idea.
  TabAtkins: I would believe you if you said it broke something.
  <gregwhitworth> I want as few changes to flex as possible, each
                  change seems to break stuff :/
  * fantasai is pretty sure this would break stuff

  <SteveZ> What about align: by-displaytype OR for-displaytype

  astearns: It sounds to me like this change is in a different
            category than the list of 3-7 on the agenda.
  fantasai: They're related, but that's why we pulled it out.
  fantasai: So there's a question of what do we call it, but there's
            also a question as to if the keyword is a good idea.
  TabAtkins: We can't not have it.
  <dbaron> I think it's good to expose the behavior.
  <gregwhitworth> I agree with the keyword since it seems to be
                  necessary
  fantasai: We can resolve on the keyword, call it 'normal' for now,
            change the name if someone comes up with better.
  fantasai: dbaron, TabAtkins, and I think it's a good idea. Anyone
            think this isn't a good idea?
  <SteveZ> I think the idea is good, but the name is bad

  RESOLVED: Add the 'normal' keyword with bikeshed pending.

  astearns: To close on 3-7, we have at least one person, maybe
            another, who will look at the changes. We will take all
            of them as a group on a future call.

Flexbox
=======

Percent resolution in the presence of min-size: auto
----------------------------------------------------

  <astearns> issue #3 on
https://lists.w3.org/Archives/Public/www-style/2015Sep/0038.html
  fantasai: This is an issue where min-size: auto creates an issue
            where every flex item is intrinsically sized. So percent
            resolution won't work by default. We raised this and
            decided to ask the implementors what to do because the
            two options are we do two pass layout or they don't
            resolve.
  fantasai: We did a call with Microsoft and Blink and Mozilla
            implementors. For this one they can do two-pass layout.
            So that's what we put in the spec. So we wanted to bring
            it back to the WG to say this is what you want to do and
            resolve officially.

  astearns: Is there a summary of the implementor conversation?
  fantasai: Yeah, I thought I linked it. Let me get it out of the DoC.
  astearns: You linked to some minutes.
  <fantasai> https://lists.w3.org/Archives/Public/www-style/2015Dec/0014.html
  fantasai: There it is^
  fantasai: I did do the wrong link in the e-mail. Sorry.
  fantasai: If people need more time because I did the wrong link,
            that's fine.

  astearns: Would anyone like more time to look into this?
  astearns: silence = no. Does anyone object to resolving on this
            now?
  <dbaron> I guess I'm a little worried about performance
  astearns: We have dbaron saying he's a little worried.
  <dbaron> But it sounds like dholbert was ok with it, I guess?
  <gregwhitworth> dbaron, yes
  <fantasai> dbaron, yeah
  TabAtkins: We can discuss it with...urm...dholbert.
  dbaron: That's fine. I'm still worried about the performance here,
          but it sounds like this isn't a big change the performance
          characteristics. Is that the case?
  fantasai: We believe so. In most cases it'll optimize away. If the
            min-size doesn't control layout you won't need another
            pass
  <dbaron> ok

  RESOLVED: Accept the change for issue 3

  <fantasai> https://drafts.csswg.org/css-flexbox/issues-lc-20150514#issue-3
  <fantasai> (above issue)

  astearns: adenilson joined...are you okay with waiting to get the
            Google properties to move off of this issue and having
            the browsers change? (Topic 9)
  adenilson: Yes, totally

Scoping @font-face defined in shadow DOM
========================================

  <astearns> https://lists.w3.org/Archives/Public/www-style/2015Dec/0113.html

  TabAtkins: I've been talking about this for a bit. This sets
             font-family to foo. It inherits down, and inherits into
             a shadow tree. That's fine. If the component that
             doesn't know what's going on outside itself clashes
             with a font name where the outer page font face is the
             same as a system font, the component accidentally grabs
             the wrong font.
  TabAtkins: We've restricted shadow DOM from having these odd
             things before. We're restricted the outer pollution,
             but CSS construct that create a global name have the
             same problem. Regions could be really confusing where
             things do a total page break.
  <gregwhitworth> this really sounds like we need better css
                  encapsulation in regards to shadow trees

  ChrisLilley: I don't believe...where you said it inherits isn't a
               natural consequence. That should be a 1d thing. It
               shouldn't flow the other way. If the component
               declarers it doesn't effect the outer.
  TabAtkins: I agree. The 1d flow is the hard part. Flowing into the
             shadow is the problematic part. This is related to
             macro hygiene issues where you have variables in a
             macro that need to not interfere with user declared.
             The only solution is re-write the font name, maintain
             mapping of the original names to the re-write, but
             prevent accidental collisions between inside and
             outside names.
  TabAtkins: If the outer has foo, whatever crosses into the shadow
             is something guaranteed unique. Then if the shadow uses
             foo, it wouldn't select the outer font face. If they
             wanted to they could look at the inherited value, but
             it prevents accidental. And we would do that for
             anything that declares a global name. If they're
             exposed through inheritance we'd have a secret mapping.
  <gregwhitworth> so foo becomes shadow-foo vs global-foo?
  <gregwhitworth> This sounds feasible
  ChrisLilley: That seems to make the basic case harder where you
               want to use the same as the outer. You have to do the
               import yourself.
  TabAtkins: By default inheritance still works. The name you still
             with be a guaranteed unique name, but will refer to the
             correct font.

  ChrisLilley: Okay. And the same as variables?
  TabAtkins: Variables are a communication channel so they're
             staying the same.
  glazou: It's important to keep that.
  TabAtkins: Yeah.
  astearns: I was going to say the same. If using inheritance wasn't
            an option for a component and they did want to get
            something in, they would have variables as the vehicle.
  <glazou> exactly what astearns said
  TabAtkins: Yes, if they really want to, they could smuggle
             something in...though you wouldn't want to have that...
  gregwhitworth: So if I'm an ad on your page, using web components,
                 and I want to inherit your fonts, I don't know your
                 variables.
  TabAtkins: Using the inherited font keeps working. We just do a
             re-write and have a name mapping.
  gregwhitworth: Okay, cool.

  dbaron: It seems a little like instead of unique names you could
          use a function that refers to a name in the parent scope.
          Though I'm not sure which is better.
  TabAtkins: We'd have to stack them to know which scope, but it's
             an alternative. We just want a normal font name to
             never collide. Function could achieve that and that's
             fine too. It takes a parent function and evaluates a
             keyword there and nest to go a few scopes up.

  rniwa: Is this a proposal? I'm confused what we're discussing. Is
         this a proposal for scoping or...?
  TabAtkins: There's a concrete proposal on the mailing list. I just
             sent one...it's in the agenda.
  TabAtkins: You can read that for more details.

  astearns: For font-family property are you making the entire
            property value transformed or individual components?
  TabAtkins: Individual components that refer to a font-face rule.
             The issue is font-face rules not accessible. See what
             are @font-face names and re-write those.
  astearns: Are they user-idents? Can we spec that that it's all
            user idents?
  TabAtkins: I've have to check but probably? If it's an enumeration
             of things that are defined...yes, in general custom
             idents is what we'd want to rely on if we're defining a
             global thing.

  dbaron: One thing that seems odd is making computed value of
          font-family depend on font-face rules which it currently
          doesn't. That seems messy.
  TabAtkins: That's what it would do, but I don't see a way around it.
  dbaron: The idea of the function that gets the name from the scope
          might be a way around it.
  TabAtkins: Ooooh...that would work. You could put it on system
             fonts and it would be the same name, but that's fine.
             That works for me.
  TabAtkins: I like that.
  <gregwhitworth> sounds good
  TabAtkins: Let's go with that. If that sounds okay I'll write up a
             formal proposal for the list and make sure it's
             applicable to everything that matters.
  astearns: Sounds like a good step to me.

  rniwa: For the function, how to we solve the shadow DOM, does it
         solve that?
  TabAtkins: Let's do odd details on the mailing list with concrete
             examples, but that's a good idea.
  myles: And you'd still re-write, but with a function.
  TabAtkins: And we'd be able to do it unreservedly. We re-write all
             of them to refer to the parent scope.

  astearns: Alright, let's go with that. We're at the top of the hour.
  astearns: Thanks everyone.

  <TabAtkins> "font-family: my-custom-font, Comic Sans MS,
              sans-serif;" would inherit into a shadow as "font-
              family: outer-scope("my-custom-font"), outer-scope(
              "Comic Sans MS"), sans-serif;"
  <dbaron> although this would need some way to account for multiple
           nested scopes
  <dbaron> not sure if nesting outer-scope(outer-scope()) is the
           best way to do that
  <myles> dbaron: it seems natural to have nested function calls
  <TabAtkins> Yeah, I presume "font-family: outer-scope(foo);" would
              inherit into a further shadow as either "outer-scope(
              outer-scope(foo))", or we can give an integer value
              like "outer-scope(foo, 2)"
Received on Thursday, 10 December 2015 00:47:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:31 UTC