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

[CSSWG] Minutes Telecon 2014-12-10

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 11 Dec 2014 10:33:22 -0500
Message-ID: <CADhPm3ukM5c9LkT-CexiUHU+FO6cXAanPdVbgkPojWVun4nj_w@mail.gmail.com>
To: www-style@w3.org
Brief Introduction to API Taskforce

  - Rossen introduced the creation of a taskforce to tackle some of
      the lower level layout primitives and exposing the
      programmability model of layout and styling to script.
  - The group will meet in person just prior to the Sydney F2F in
      February to finalize details of the charter, meeting schedule,
      and exact scope of what the taskforce will try to achieve.
  - Anyone interested in this work is invited to join the mailing
      list and follow on the wiki (available here: wiki.extf.org)


  - Everyone in the group was actioned to review the edits dbaron
      made on the spec and give feedback.

:lang() issues

  - RESOLVED: Keep allowing *-identifier when it's not digits and
      recommend a string when it is.
  - RESOLVED: Allow strings as argument to :lang()

Fixed layout

  - Everyone agreed that an errata should be created to better
      explain how space is distributed among columns. dbaron will
      write up Gecko's behavior for the mailing list and SimonSapin
      will use that to create some tests and find interoperability
      for the errata explanation.
  - This discussion transitioned to the difficulties in republishing
      a document in REC and the lack of tests for the CSS2.1 errata.
      There was a desire to make sure that changes like this are
      clear to those looking at the spec.
  - RESOLVED: Add a new link at the top of CSS2.1 linking to the
      Editor's Draft


  - RESOLVED: To the extent that the outline follows the border
      edge, it should follow the border-radius curve (issue 56)
  - RESOLVED: Implementors may directly manipulate width and height
      elements on the style attr being changed and change "resize
      factor" to "resize function" to address fantasai's concern
      (issues 47 and 53)


  Rossen Atanassov
  David Baron
  Adenilson Cavalcanti
  Tantek Çelik
  Dave Cramer
  Alex Critchfield
  Elika Etemad
  Simon Fraser
  Sylvain Galineau
  Daniel Glazman
  Koji Ishii
  Dael Jackson
  Brian Kardell
  Brad Kemper
  Philippe Le Hégaret
  Chris Lilley
  Peter Linss
  Mike Miller
  Edward O'Connor
  Anton Prowse
  Liam Quin
  Matt Rakow
  Florian Rivoal
  Simon Sapin
  Dirk Schulze
  Alan Stearns
  Ian Vollick
  Greg Whitworth
  Steve Zilles

  Bert Bos
  Simon Pieters
  Lea Verou

  Scribe: dael

  glazou: Let's get started
  glazou: I saw that Bo posted an extra item on the ML. Any other
  sylvaing: I have issues on Animations and the behavior of the key
  glazou: The delete and insertion rules?
  sylvaing: Yep.
  <dbaron> glazou, I'd like to briefly point out an email I sent
           about transitions
  <glazou> dbaron: ok ; do that after the current item ?

Brief intro for API taskforce

  Rossen: I can do my best. Is TabAtkins on the phone?
  glazou: He's not, apparently.
  Rossen: Okay. I don't even know what to call it anymore. There's a
          taskforce which was formed just a few days ago and it's
          something we've been talking about and trying to get up
          and running.
  Rossen: The idea and purpose is to tackle some of the lower level
          layout primitives and exposing the programmability model
          of layout and styling to script.
  <glazou> the TF’s mailing-list is public-wtf@w3.org

  Rossen: Why did we form a TF? If you read one of TabAtkins's e-
          mail in response to the original thread, he had a really
          good summary. Basically half the people in the WG are
          interested in layout and half are not. We want to have a
          focused group that deals with that alone and nothing else,
          similar to the FXTF and how the deal with effects.
  Rossen: The group as it stands is most represented with impl. We
          have people from Mozilla, Google, Microsoft, Adobe, and I
          believe we may have people from Apple join. We're trying
          to set up a first meeting in Sydney.
  <glazou> and even DISRUPTIVE INNOVATIONS !
  Rossen: Oh, and HP and Disruptive Innovations.
  <glazou> :)
  <Florian> invited experts as well
  <bkardell> I have joined - jQuery

  * bradk can't read "WHATTF" as anything other than "WTF?"
  <glazou> bradk: That’s why smfr suggested to change it
  <astearns> is there anyone from TAG besides Peter who are
  <bkardell> tag is interested, they wanted it set up

  Rossen: So we'll try and set up a meeting right before the Sydney
          F2F on Sat and Sun, I believe that's 7 and 8 Feb.
  Rossen: shans will arrange and host the meeting, I'm assuming in a
          similar or same location.
  Rossen: That's pretty much what we have for now. We're hoping
          during the initial meeting we'll clarify the charter of
          the group, so don't hold me to what exactly we'll do.
          We'll set up the charter at the F2F. Prior to that we're
          hoping the bikeshedding of the taskforce name will be done
  Rossen: The wtf name I don't think was ever meant to stick for a
          long time.
  Rossen: It turned a bunch of heads. I got a bunch of emails about
          people who were passionate about being serious. I am too,
          so don't hate me for it.
  <ChrisL> just let me know what the eventual name will be, and i
           will create the new list
  <Rossen> wiki.wctf.org

  Rossen: We'd love to have people join the list. It is public.
          plinss and I set up mercurial and extf and if it sticks
          that's what we'll use to solidify proposals and start
          creating spec.
  <Rossen> wiki.extf.org
  Rossen: And the wiki is this (above) and up and everyone in CSS
          should be cleared for access and to contribute.
  Rossen: That's the overall intro. Any questions or name proposals?

  <dauwhe> Could shans forward the original meeting notes from Santa
           Clara to the new list?
  glazou: dauwhe has a good question on IRC. shans should forward
          the meeting notes from the end of TPAC to the list.
  Rossen: Yes, once the wiki is up and running, there are some
          initial documents we'll use to introduce people to what
          we're doing and the problem space as well as meeting notes.
          At Sydney we'll figure out the telecon schedule and so
          forth. The initial meeting will be administrative and
          chartering details.
  ChrisL: I would suggest waiting to forward the notes until the
          mailing list exits. As soon as you have a name you've
          settled on let me know.
  Rossen: I will and thank you ChrisL for being so patient with this.

  glazou: Okay. Any questions?
  glazou: Thank you Rossen.
  Rossen: I hope to see as many of you as possible in Sydney.


  <dbaron> http://lists.w3.org/Archives/Public/www-style/2014Dec/0150.html
  dbaron: I wanted to point out I sent an e-mail to www-style
          yesterday about edits to Transitions spec. I'd appreciate
          review of the edits and the spec in general because
          hopefully we can take this to the new process, maybe in

  glazou: Let's do an action to the group. How much time is needed?
  dbaron: I don't know if it's on everyone. Some of these are

  Rossen: Is this the write-up that you did...in a couple of F2F you
          mentioned that the position model is broken and you would
          rewrite. Is this it?
  dbaron: No. That was in the last WD. This fixes one of the things
          that was missing from that. The edits I did then didn't
          explain how transitions get canceled.
  Rossen: Maybe now is a good time for an overall review of the
          whole model.

  smfr: Are there any tests that describe the behavior?
  dbaron: I don't think so. That would be useful as well.

  ACTION: everyone to review the document and give feedback

:lang() issues

  glazou: smfr will you be discussing this?
  smfr: I don't have the background, sorry.

  <glazou> http://lists.w3.org/Archives/Public/www-style/2014Dec/0046.html
  <glazou> http://lists.w3.org/Archives/Public/www-style/2014Dec/0130.html
  glazou: Let's take the first one. That's about parsing the
          argument of :lang(). In Selectors 4 when there's a * to do
  glazou: The second message is similar but about how we tokenize
          the value of :lang(). So when we want to make *-number we
          can't because -number isn't a token.
  ChrisL: I think TabAtkins sent a message recently about making
          that a string is the best way forward. When we originally
          spec'ed it, it was an easy thing. We can't tell what the
          future will be so we need to make it a string.
  fantasai: We can't make it a string. We can allow it in addition
            to tokens.
  ChrisL: Yeah, sure.

  fantasai: One of the things Webkit folks were asking is why not
            allow escaped asterisks.
  glazou: This is ugly.
  fantasai: There's no reason to disallow, so why not allow? We
            might also want to allow strings as a less ugly option.
            The only time you need a * is in the front since in the
            middle is like not putting it there. The front is only a
            problem when the subtag is a number.
  fantasai: The only time it's an actual problem is when you're
            doing *-number. You can solve that with a string or
            escaping the *.
  glazou: I prefer the string.
  fantasai: I imagine the corner case is rare.
  glazou: But as ChrisL said we don't control this. This comes from
          another committee and we don't know what they'll do in the
          future. We should assume it's possible to happen in the
          future. It's not a complete edge case.
  * tantek dislikes escaping path.

  glazou: I'm really in favor of allowing a string and now going
          down the escaping path. What do others thinks?
  fantasai: If we allow string, we should allow both.
  glazou: Absolutely, but then we can say if you have * somewhere it
          has to be a string. This is new in Selectors 4.
  <TabAtkins> Whoops, forgot about the call. I agree with glazou,
  <ChrisL> +1 to fantasai allowing * at start
  fantasai: I think I would prefer for allowing the * in the
            beginning unquoted. That makes a minimal change for
            targeting a subtag, but allow a free range at the
            beginning. I don't mind having a string required for
            other situations. I want the common place to be as easy
            as it was previously.
  <bkardell> I think a string makes sense, it's still pretty easy,
  <bkardell> +1
  <TabAtkins> Better to make it a consistent "string if you use *"
              than an inconsistent "just type it, but if it doesn't
              work [due to arcane parsing things] then use a string"
  fantasai: For usability I'd like to allow the star. I'm fine with
            allowing the string for future weirdness and an
            alternative to escaping.
  <TabAtkins> fantasai: One of Ben's emails was precisely about a
              problem with an initial *.

  SimonSapin: An escaped is star is already a valid ident in :lang
              pseudo-class. We shouldn't dis-allow it. Escaping
  florian: That makes sense to me. Escaping is allowed.
  glazou: Do we agree on the strategy here?
  florian: I do.
  glazou: fantasai?
  fantasai: Yes? I think TabAtkins isn't sure.
  <TabAtkins> calling in now, one sec
  glazou: [reads TabAtkins comments]
  glazou: One of Ben's e-mails is about the problem with the initial
  <TabAtkins> The two problems Ben brought up:
  <TabAtkins> 1. *-1996 is a valid code via the RFC, but invalid per
              CSS parsing.
  <TabAtkins> 2. foo-*-bar is valid in the RFC.
  fantasai: I think that's weird and arcane and pretty much no one
            will run into it.
  glazou: When the problem is plausible it always happens.
  glazou: So, let's keep allowing *-identifier when it's not digits
          and recommend a string when it is.

  RESOLVED: Keep allowing *-identifier when it's not digits and
            recommend a string when it is.
  RESOLVED: Allow strings as argument to :lang()

  fantasai: I'll make the edits.
  <TabAtkins> fantasai: I recommend making the edits so that string
              is recommended, but then laying out cases when you can
              omit the quotes. Better than trying to say "you don't
              need quotes, but if you find that it doesn't work, use
  <fantasai> TabAtkins, yes, makes sense. Well, I would recommend
             unquoted for anything that's not involving *, because
             that is backwards-compatible and strings are not.
  <fantasai> TabAtkins, but for cases with * I agree.
  <TabAtkins> fantasai: Yeah, sure.

  <ChrisL> action: chris to extend the zakim bridge allocation
  <trackbot> Created ACTION-663

Fixed layout

  <glazou> http://lists.w3.org/Archives/Public/www-style/2014Nov/0580.html
  SimonSapin: The part of fixed layout that is spec'ed in CSS2.1 has
              one of the sentence. When all columns have the
              specified width and the table has a specified width,
              if the table is larger, the extra space should be
              distributed between the columns. The spec doesn't say
              how, but it turns out webcompat depends on it being
              proportional to the width of the columns.
  SimonSapin: It seems like the spec needs to say this so we should
              add an errata.

  Florian: There was an extra comment on the mailing list about
           needing exceptions.
  dbaron: And you have to consider if it has percentage width as
          well. What Gecko does is it distributes extra space...if
          there's a non-0 width in column with a specified length,
          it distributes among them with nothing to the column that
          have percentage. Otherwise it distributes to those with
          percentage width.
  Florian: Do we have interop on when there's col-span somewhere?
  dbaron: I don't think it interacts, well, maybe you are looking at
          cell width. I'm not sure if this is looking at cell widths
          or only...fixed only looks at the first row. It may skip
          those with col-span.
  SimonSapin: It does distribute to those with col-span.

  glazou: So do we have an answer to the question?
  SimonSapin: We need to change something. It's unclear as to what
              the exact behavior should be. dbaron can you write on
              the mailing list what the Gecko behavior is?
  Florian: And we want to make sure other browsers do the same?
  SimonSapin: I can try to do that.

  glazou: plh are you on the call?
  plh: I am.
  glazou: You want to mention something about CSS2 errata?
  plh: It would be nice to leave the spec as it is online. I brought
       this to the group and we were lacking tests. I'm not saying
       we should stop everything, but it would be great to update
       the TR version of CSS 2.
  glazou: Comments?

  glazou: SimonSapin will you create an errata based on the changes
          you want from your tests?
  SimonSapin: I'll do more tests to find interop and then propose an
  fantasai: While you do that, can you submit a test?
  SimonSapin: I can do that.

  tantek: What is the status of the lighter-weight TR process?
  fantasai: The process for updating REC is worse in the new version
            of the process.
  plh: There has been discussion on the process list. There is a
       high bar to update REC and there's been a discussion about
       lowering that bar.
  <ChrisL> we published a CR under new process recently. actually it
           was the first one
  tantek: I thought it was further than that. Allowing a group to
          update a TR page without the heavy lifting.
  fantasai: That's not about what W3C process we're on. For 2.1
            we're stuck on process issues. We can't publish
            substantiative changes unless they pass CR and we have a
            bunch of items without tests or implementation reports.
            So for passing the current version of 2.1 we need all
            the reports to publish, or re-publish.
  tantek: That's a long list of dependencies. I understand the need
          to not update the TR CSS2.1 immediately, but this long
          list of dependencies seems like a bad problem. Can we
          publish as an ED?
  fantasai: It is.

  tantek: Can we slap a warning on the top of CSS2.1? Why not do
  plh: Because no one has asked. I don't think that we've done it
  fantasai: We have. We put something at the top of CSS2 saying look
            at 2.1
  tantek: So I'm saying put something at the top of 2.1 that links
          to the ED.
  fantasai: I'm in favor.
  glazou: I am if we say there's extra ongoing work.
  tantek: Saying we have substantial changes in process.
  liam: The usual is to put it in errata rather than link to an
        unstable doc.
  tantek: I object to hiding it the the errata.
  glazou: We should put it in the real document.
  tantek: This is a warning at the top.

  glazou: So we have a proposal to put a new link at the top of
          CSS2.1. Support?
  <Florian> +1
  <SimonSapin> +1
  <tantek> +1
  <dbaron> in favor
  <astearns> +1
  <antonp> +1
  <gregwhitworth> +1
  <fantasai> +1
  <smfr> +1
  <dauwhe> +1
  fantasai: I'm in favor. Someone mentioned a link to both the
            errata and the ED and that's good.
  <SimonSapin> we already have an errata and a link to it
  <tantek> we already have a link to the errata - no need to
           duplicate that
  glazou: Any objections?
  <liam> -1 but not objecting
  <KeshavP> +1
  <tantek> this is ONLY for linking to the editor's draft
  <SteveZ> +1
  <ChrisL> so this is an in-place edit on CSS 2.1 Rec?
  * fantasai is pretty sure nobody can see the errata link unless
             they know it's there, so thinks having it in the
             warning is probably a good thing
  <ChrisL> errata must already be there for a rec
  tantek: We have a link to the errata, so I don't think we should
          confuse it.
  glazou: Yeah, fine.

  RESOLVED: Add a new link at the top of CSS2.1 linking to the
            Editor's Draft

  <tantek> "There are substantial changes in progress"

  * plh wonders who got the action to update CSS2.1
  <glazou> plh: good question BTW
  <SimonSapin> plh, nobody yet, I think
  <glazou> am stram gram :-)
  * plh nominates Chris or Bert to do the update :)
  <tantek> glazou - who put the warning at the top of 2.0?
  <glazou> tantek: ChrisL or Bert?
  <glazou> oh wait you said 2.0
  <glazou> no idea
  <tantek> glazou any volunteers to update 2.1 with the warning?
  <glazou> hey that was EONS ago
  <glazou> tantek: plh and I recommend ChrisL or Bert
  <SimonSapin> Can we make the warning fixedpos, like
               http://dev.w3.org/csswg/css-box/ ?


  glazou: You have 20 minutes. Choose well.
  <Florian> http://lists.w3.org/Archives/Public/www-style/2014Dec/0145.html
  Florian: Let's start with this.

  Florian: We have a resolution about rounded outline. We had a
           short discussion that raised issues, didn't answer them,
           and then concluded that if you have a rounded border, the
           outline should be rounded as well. I agree this is what
           you'd normally want, but due to the vague definition, I'm
           not sure what it means.
  Florian: We have interop on not doing that. Every browser keeps
           square corners. I'm not sure if there's a webcompat issue
           with switching.
  Florian: Options are 1) do nothing 2) do the same explicitly
           saying you may, but not how 3) we do it with a must,
           probably don't say how, and test the obvious case.
  Florian: I would prefer an explicit may to allow experimentation
           and spec it completely in level 4. I have ideas on how
           we'd attempt a full spec, but it's not a one-liner

  fantasai: The definition wouldn't be that difficult. To the extent
            that the outline follows the border edge, it must follow
            the rounding.
  Florian: Not always. If the children overflow, some browsers
           include the overflowing bit in the outline. Also, the
           spec doesn't say if you transform the outline when you
           transform the elements.
  fantasai: You can say to the extent that you follow the border
            edge. So when it does, you follow the curve. Where it
            doesn't follow the border edge it's left undefined.
  Florian: That sounds like something we can spec. If we spec as a
           'must', no one passes.

  Rossen: I think we can easily push it to level 4. I don't see us
          rushing to implement this given everything else on the
  Rossen: On the priority level, this will be low for us. I'd be
          surprised if others rush to impl rounded corners. I'd be
          okay with this going to level 4.

  tantek: This feature started from the really good outline and
          focus of WebTV. It did round the corners and provide a
          nice rounded implementation. We knew this was non-trivial
          to implement which is why it's loose in the spec. I don't
          expect every implementor can do that, we need to allow a
          broad range of fidelity. I'm okay with adding some more
          'may' to the existing spec with known best practices but
          it's premature to agree one spec'ing this on any future
  * Rossen agrees with tantek
  <fantasai> tantek +1
  tantek: I find it disturbing that the rounded-ness disappears at
          times, but I don't know how to say it's broken without
          breaking other implementations. I'm okay with 'may'
          statements, but not saying how to do it.

  Florian: So we have fantasai's proposed sentence with a 'may' in
           it for level 3.
  tantek: fantasai can you put your sentence in IRC?
  Florian: That the extent that the outline follows the border, the
           outline should be rounded just like the border, I think.
  <fantasai> "To the extent that the outline follows the border
             edge, it should follow the border-radius curve."

  Florian: I don't know about if we should use 'should' vs 'may',
           but not 'must'.
  tantek: So 'should' vs 'may' is are we sure that it's desirable
  fantasai: We're sure it's desirable, but not sure about webcompat.
  tantek: If we're sure, we should use 'should'.
  Florian: That's why we resolved before on 'must', but that's a bit

  RESOLVED: To the extent that the outline follows the border edge,
            it should follow the border-radius curve

  <tantek> Florian said he would edit the CSS3-UI issue
  <astearns> tantek: issue 56?
  <Florian> tantek: rounded outlines was
  <tantek> thanks Florian

  glazou: 10 more minutes
  <Florian> http://lists.w3.org/Archives/Public/www-style/2014Dec/0063.html
  Florian: Next one, resize. It is spec'ed in terms of a resize
           factor. They do it by updating a style attr and they're
           interoperable. Regardless of if the spec behavior is
           good, we should drop it in terms of what's implemented.
  fantasai: I'm not sure if what's in the spec is ideal, but I'm not
            sure on what's impl either. So if you resize a form
            element to make it bigger and it was, say, fill to
            viewport, and then you resize your window to make it
            significantly narrower or wider, the form element will
            no longer attempts to fit in your new layout.
  fantasai: In which case the UA may want to do something smart. I
            don't know what's right, though I think what's in the
            spec shouldn't be what's there. It should be close to
            what's impl or more similar.

  Rossen: So if the resize-able element is relative to a containing
          block and the containing block is resized, do you resize
          the element again. You can decide which is the desirable
          behavior and you can re-spec by saying either it remains
          fixed or resizes on the next containing block resize.
  glazou: We see that when you resize a table in an editor. When
          nothing is fixed length, you resize a field and then a
          container, you have that problem.
  Rossen: I think that half the time you want to resize and half the
          time you don't. Perhaps we're missing an additional
          behavior which will further define what happens during
          resize. It'll be up the the author to set the expected
          behavior for if it will be resize as fixed or relative.

  fantasai: That makes sense. We should explore that in the next
            level. For this level we may have the spec what's there
            and say the UA may reset the size when it feel like it.
  glazou: I can agree to that.
  tantek: That's a lot wording to restate what we have. The current
          language was chosen to cover all these variants.
  tantek: That was the most expedient way to implement and it's not
          a coincidence that they arrived there.
  Florian: I'm not sure they're equivalent.
  tantek: I said covered by. The language is very deliberate to
          cover the existing behavior and something in the future
          where the UA does something more intelligent in the future
          depending on how the item was laid out etc. I don't think
          the impl know what's optimal.
  tantek: Right now we don't have widespread use of Flexbox, but I
          think we will in the future and detailed language will
          make an obstacle in the future.

  dbaron: So, I don't think what implementations are doing is
          conformant to what the spec says.
  fantasai: I agree. Interacting with the cascade is not an internal
  dbaron: The spec is clear that it's after width, so these are
  tantek: I would be okay with expanding what the spec allows to
          explicitly allow the style attr manipulation.

  Florian: So I'd like to ask if the impl are ever willing to change.
           If they're not, we shouldn't spend time discussing the
           change. But if they're willing to change we can spend
           time deciding where this should be in the future. I don't
           have an opinion on which is better, I just want spec and
           impl to match.
  dbaron: I think there's a difference between willing to change and
          willing to put in the energy to make the change happen.
          What's in the spec is more work, probably substantially.
  tantek: That's why I'm saying the spec language should be
          broadened to allow what impl are doing now and allows
          better approaches in the future.
  Florian: I'm not sure how you do that given the infraction to the
  tantek: We add a sentence saying something like impl may directly
          manipulate width and hight elements on the style attr
          being changed.
  tantek: That's my proposal.
  glazou: Florian what do you think?
  Florian: I'm willing to go with tantek. If impl are willing to go
           with what is in the spec, why not, but if impl won't
           change there's no point in specing something they won't
           use. I don't see much willingness to impl the other one.
  fantasai: I think someone that isn't on the core impl team will
            find a need for a better approach and will put pressure
            for the changes. If we think it's a better route we
            should leave it open. If we think we'd like to go there
            if we have the resources, we should leave it in the spec.

  fantasai: The current language talks about a resize factor and
            that's multiplicative. Right now it's a fixed size. I
            think we might want to change it to information.
  fantasai: Might want to be additive rather than multiplicative.
  tantek: How about a resize transform?
  fantasai: Sure.
  tantek: That reasoning makes sense. That allows implementors to do
  Florian: I'm not sure about the word transform because people
           might think it's the transform property.

  glazou: We have to wrap up.
  <tantek>  proposal: change "resize factor" to "resize transform"
            to address fantasai's concern
  Florian: If we allow the current in the spec, I'm good with that.
           I'm not sure it's obvious that the rest is useful, but
  fantasai: An alternative to tantek's language is to say
            information which is more vague.
  tantek: Or function.
  <fantasai> I like function
  <fantasai> let's use function

  Florian: So we won't have tests for this?
  tantek: Nothing more than we have now.
  <fantasai> f(x) = x + 20px
  <fantasai> f(x) = 278px
  <fantasai> f(x) = x * 1.5
  Florian: I'm not sure how you test if we can say this way or that
           way with one way not defined.

  <tantek> proposal: change "resize factor" to "resize function" to
           address fantasai's concern
  glazou: So can we continue offline or resolve?
  tantek: I want a resolution on what I typed.
  <tantek> both proposals
  Florian: Was it your line plus the earlier? As long as you can do
           it with a style attr, I'm good.

  RESOLVED: Implementors may directly manipulate width and height
            elements on the style attr being changed and change
            "resize factor" to "resize function" to address
            fantasai's concern

  glazou: alright, bye!

  <tantek> that was for CSS3-UI issues 47 and 53
Received on Thursday, 11 December 2014 15:33:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:49 UTC