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

[CSSWG] Minutes TPAC F2F 2013-11-12 Tues V: Backgrounds and Borders 3, Transitions, CSS Shapes, Backgrounds and Borders 4, Longhand for List Properties

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 21 Nov 2013 18:43:22 -0500
Message-ID: <CADhPm3uTZf5t_GXwd6CAVVRCW9Vn=GP1ZPaPP+bQYVDutnSmJg@mail.gmail.com>
To: www-style@w3.org
Backgrounds and Borders 3

  - The lack of a definition for the order of shorthands was discussed.
  - A potential solution of referring to a propdef was raised, but where
         the information on how to read propdef should be placed was
         unclear with people disagreeing as to if it needed to be a rec
         track document or not.
  - Potentially removing three value positions and the implication for
         one value positions was discussed with the group leaning toward
         only allowing one value positions.
  - TabAtkins and fantasai will write up text for transform-origin to
         reduce/alter inconsistencies with background-position
  - A few other issues were briefly mentioned, but either set aside for
         mailing list discussion or to be a part of Backgrounds and
         Borders 4.


  - RESOLVED: Publish new working draft of CSS Transitions

CSS Shapes

  - A few issues remain to be addressed before last call.

Backgrounds and Borders 4

  - Potential names for what's being called border-clip and
         border-corner-shape were discussed.
  - Interest was expressed in the ability to have multiple borders.
  - Fantasai will write up a proposal.

Longhand for List Properties

  - A few issues/questions were briefly discussed, but it was decided to
         hold off on detailed conversation.


Backgrounds and Borders
Scribe: dauwhe

  <fantasai> http://lists.w3.org/Archives/Public/www-style/2013Aug/0178.html
  fantasai: The issue in how backgrounds and borders doesn't define in
            what order shorthands are extended.
  fantasai: What should I do with this issue?
  fantasai: Should it go in spec?

  dbaron: We should test implementations first.
  dbaron: Not urgent. Worth doing, but test implemtations first.
  fantasai: Will people will be happy if we ??? this from
            level 3?

  zcorpan: Could you describe the issue again?
  dbaron: If there's a shorthand property, what order do the longhand
          properties take in the object model?
  zcorpan: The spec is aligned with what implementations do.
  [zcorpan is looking up the spec.]
  <zcorpan_> http://dev.w3.org/csswg/cssom/#concept-declarations-specified-order

  * fantasai doesn't understand
  fantasai: Don't define what happens if you expand something out.
  zcorpan: We need to define orders of longhands
  fantasai: The canonical order seems to define canonical order for
            serialization, not of longhands.
  fantasai: What should I do with the spec?
  zcorpan: I want the order defined in CSSOM.
  zcorpan: I can take an action item to test what browsers do and
           document it somewhere.

  fantasai: Should there be a list of all properties in spec in an
  dbaron: We should see what browsers do. I don't want to break interop.

  fantasai: What does that spec look like?
  dbaron: Orderings might not fit with list in spec?
  dbaron: It might be easiest to put it in propdef.
  dbaron: Must define order resilient to addition of new properties.
  fantasai: Who's doing this?
  fantasai: And in what spec?

  dbaron: Do we have definition of canonical order in propdef?
  fantasai: In CSSOM
  dbaron: CSSOM uses the term canonical order, but does not define it.
  fantasai: How to read propdef tables is not part of spec.
  fantasai: The only definition is in CSS 2.1.

  fantasai: Maybe put how to read CSS propdef tables into snapshot?
  dbaron: It used to be in syntax.
  dbaron: Or could be in values.
  <TabAtkins> I'm fine with either.
  * glazou too

  plinss: Who edits these specs?
  fantasai: Does this need to be rec track document?
  dbaron: Yes.
  <TabAtkins> ...really?
  plinss: I don't feel strongly about syntax or values but it should be
          rec track.
  fantasai: I'm not convinced about rec track; it's about document
  astearns: It's about document conventions?
  fantasai: How to read a propdef table is largely about document
  <TabAtkins> Are people talking about the same thing?
  plinss: It's meta-normative.
  fantasai: Snapshot is where you want to put it.
  <TabAtkins> I think we're talking about the format of a propdef table.
              It's just a compact representation - how to expand that
              into the normative definition doesn't need to be
              Rec-track, just recorded.
  * fantasai agrees with Tab
  * astearns thinks he does too

  fantasai: Did you see Tab's comment?

  <TabAtkins> We don't need the property grammar in a rec-track document
              either. It was just convenient to put it into Values.
  * dbaron disagrees with Tab
  <TabAtkins> I don't understand, dbaron. :/
  <TabAtkins> But the only thing that got minuted was "Yes" from you, so
  <dbaron> TabAtkins, It affects what some pretty important stuff in the
           spec means
  <dbaron> TabAtkins, stuff that changes what an implementation is
           required to do
  <dbaron> TabAtkins, it seems pretty odd to make something like that
  <zcorpan_> I agree with dbaron
  <TabAtkins> dbaron: No, the content inside of it is normative. How to
              read it is just descriptive. But whatever, I'm fine with
              it in Values or Syntax, I just don't see that it *needs*
              to be in one of those.

  plinss: I suggest we put it in values.
  fantasai: Some of it is about values,
  fantasai: Is it inherited?
  astearns: I agree it should be in values.
  <astearns> *if it needs to be in a rec track document.

  * glazou thinks that would help to reach interop here and interop
           needs a standard, ie a REC
  <fantasai> glazou, interop on how to read a propdef table? Yeah, I
             guess so, but the implementations are people here...
  <glazou> fantasai, yeah...

  plinss: Do we need a resolution?
  fantasai: We need an action.
  plinss: Who takes the action?
  <fantasai> ACTION: fantasai put something somewhere
  <trackbot> Created ACTION-598 - Put something somewhere [on Elika
             Etemad - due 2013-11-19].
  <TabAtkins> You're going to look at that later and be so confused,
  * fantasai never looks at her actions list, so meh.

  astearns: One other thing on backgrounds,
  astearns: Should we remove three-value positions?
  fantasai: We'd also have to remove one-value positions, including
  astearns: We would have to remove one value that is not keyword.
  fantasai: That's not something we can fix.
  fantasai: What are Tab's thoughts?

  plinss: do we want tab to call in?
  dbaron: If he does, would he hear us?
  <TabAtkins> No, I won't hear anything.

  <fantasai> e.g., 'center' would no longer be a valid <position>
  <fantasai> so I'm less convinced this is a good idea.
  <TabAtkins> Why do we have to also remove 1-value?
  <fantasai> When it was just 3-value syntax, well, that seemed
             unpopular enough to get rid of... but not 1-value
  <fantasai> TabAtkins, because it's ambiguous.
  <TabAtkins> The problem with 3-value is that "left top 5px" is maybe a
              <position> and maybe a <position> <length>.
  <TabAtkins> But "left 5px" isn't ambiguous.
  <fantasai> It is.
  <fantasai> It can be <position> <length>, too
  <fantasai> Or it can be <position> with 2 values
  <TabAtkins> Aw man, I thought I remembered the 2-value as being either
              2 lengths or 2 keywords.
  <TabAtkins> Sigh, okay.
  <fantasai> Close no change?
  <astearns> That last bit is asking you, Tab.
  <TabAtkins> Oh.
  <TabAtkins> Given that this is *not* intending to be a
              backwards-compatible change (we'll define the old position
              syntax as <legacy-position> and still use it in the older
              properties), what about making the 2-value change to have
              it only be lengths or keywords, not both?
  <fantasai> I think this is getting more confusing than helpful.
  <TabAtkins> Then we could allow 1-value as keywords only, and no
  <TabAtkins> I'll write it up.

  astearns: This has no effect on backgrounds?
  <TabAtkins> Right.
  astearns: For backgrounds we close no change.
  <TabAtkins> Yes.
  fantasai: That we'd have to do, anyway.
  fantasai: Syntax that's almost but not quite the same,
  fantasai: That might be confusing.
  fantasai: whether it's valid in one case or the other
  <TabAtkins> What we name the grammar term in bg-position isn't
             important anyway.
  astearns: Use different terms for left and right.

  fantasai: We don't have any cases
  fantasai: Where it make a significant difference.
  fantasai: Not worth pursuing.
  <TabAtkins> Yeah we do - we can't use something position-like for 3d.
  <TabAtkins> Because of the ambiguity.
  <TabAtkins> But anyway, I'll write this up.
  <fantasai> TabAtkins, then let's make transform-origin a special
  <fantasai> TabAtkins: It's special in having 3 dimensions of position
  <fantasai> I'm rather less convinced that we should be altering
             gradients(), shapes, et al.
  <fantasai> To be different from background-position
  <fantasai> Than altering transform-origin in that way.
  <TabAtkins> It probably doesn't matter much, but whatever.

  fantasai: My thoughts on altering transform-origin() to allow to
            expand to:
  fantasai: So the problem is that it only takes this length argument
            that represents a third dimension.
  fantasai: So we're stuck with css1 background positioning.
  fantasai: That's the problem case we have.
  fantasai: Since this is a 3-d position,
  fantasai: It's less bad.
  * TabAtkins suggests the 3d side keywords be "face" and "infinity".
  astearns: Dirk has strong opinions about transform-origin(),
  astearns: That I can't channel.

  <fantasai> ACTION: fantasai write up with Tab potential changes to
             transform-origin to reduce/alter inconsistencies with
  <trackbot> Created ACTION-599 - Write up with tab potential changes to
             transform-origin to reduce/alter inconsistencies with
             background-position [on Elika Etemad - due 2013-11-19].

  fantasai: Anything else?
  fantasai: Can we make spread continuous is still an issue.
  fantasai: I'm working on formula so we can have continuous animation,
  fantasai: Starting from zero.
  fantasai: Or we can decide we won't change and publish LC.

  plinss: Let's set time limit on a new solution
  plinss: I don't feel strongly.
  fantasai: Neither do I. I'll respond to mailing list.

  dino: I've proposed border-image-like slicing for background image.
  dino: There's some support on mailing list.
  dino: Is this enough for a real proposal?
  <TabAtkins> I find the 9-slice function idea interesting.
  fantasai: We can do backgrounds 4.
  dbaron: Don't add it to level 3.
  dino: Don't delay progress in level 3.

  dbaron: I'm hesitant about property explosion.
  dino: I haven't thought it through.
  dino: It could be like border-image,
  dino: Before the comma.

  hober: What about a new function?
  dino: Tab wanted a new function.
  * TabAtkins always wants a new function.
  Lea: Very different.

  fantasai: Maybe consider for level 4 of images?
  fantasai: We have a feature for fallbacks,
  fantasai: An image function.
  fantasai: It takes comma separated list.
  fantasai: There's lots of crazy discussion of image set,
  fantasai: Tied to media fragments and slice.
  fantasai: UA's that don't understand media fragments removing image.
  fantasai: People want to implement media fragments,
  fantasai: And drop fallback.
  fantasai: The only new functionality would be media fragments,
  fantasai: which would make it more enticing to implement.
  hober: Sounds good.
  plinss: Shouldn't be and issue to put fallbacks back.
  fantasai: Put in image sets,
  fantasai: Push to level 4
  plinss: Don't preclude doing something in future.

  plinss: Other opinions?
  hober: Sounds reasonable.
  hober: I'm worried that I'm not thinking of something.
  hober: I'd love to see concrete proposal.
  dbaron: What are you proposing?

  <fantasai> TabAtkins, ok with that?
  <TabAtkins> I don't get it. What's the value of using image() just for
              media fragments? You can do that in url().
  <TabAtkins> The point of the special image() wrt fragments was
              *because* you could do fallback.
  <fantasai> TabAtkins, no that was image slicing via media fragments
  <fantasai> TabAtkins, talking about removing the comma-separated
             multiple urls functionality of image().
  <TabAtkins> Yeah, why? The minutes above don't make sense.
  <TabAtkins> Fallback is the whole point of image().
  <fantasai> TabAtkins, well, not really. We have two features in the
             image() function

  fantasai: There's 2 features in image function:
  <fantasai> one is fallback urls, so image(foo.svg, foo.png, foo.gif)
  <fantasai> other is media fragments
  <fantasai> image(foo.png#xywh=20,20,30,40)
  <TabAtkins> No, media fragments is not a feature of image(). It's a
             feature of URLs. They're usable in url(), too.
  <fantasai> There's much interest in the first one
  <fantasai> But in the second one.
  <TabAtkins> We just happened to shove in a requirement that image()
              *must* support media frags.
  <fantasai> Yeah, which is what makes it usable.
  <TabAtkins> Explain?
  <fantasai> Also, given the desire for image-set(), would want to
             co-design fallback URLs with that
  <dbaron> Maybe this should go to the mailing list?
  <plinss> See http://drafts.csswg.org/css-images-3/#image-fragments
           example 4
  <fantasai> If you have an old UA and you use url() with media frags,
             it will display the whole image.
  <TabAtkins> ...yes?
  <fantasai> So it's not really usable atm
  <dbaron> What was tab saying yes to?
  <TabAtkins> dbaron: It was a questioning yes, like "yeah?"
  <fantasai> image() makes it possible to transitioning
  <TabAtkins> Okay, I think I understand now.
  <TabAtkins> Sure, whatever, reduced implementation.
  <TabAtkins> I'd like to keep the color fallback if possible at this
  <fantasai> ah

  fantasai: It's fine to move to next topic.
  plinss: Take this issue to mailing list?
  fantasai: Tab says ok.
  dbaron: I think it was OK to something else.
  plinss: Mark this as at risk or take out?
  fantasai: Take to mailing list
  <TabAtkins> kk


  <dbaron> http://lists.w3.org/Archives/Public/www-style/2013Nov/0192.html
  dbaron: I made the edits we agreed on in Tokyo,
  dbaron: And would like review of edits. I want to publish WD sooner
          rather than later
  dbaron: I hope there's nothing big left,
  dbaron: but still need to trawl the mailing list/
  dbaron: First, are people OK with new WD for transitions?
  dbaron: Then we can take both to LC soon.
  dino: I support publishing
  <TabAtkins> +1 to publish
  dino: The undecided thing was reversing behavior.

  dbaron: There's 2 big edits;
  dbaron: Reversing behavior
  dbaron: And starting of transitions, which was the scarier change.
  dbaron: The implementations all disagreed.
  dbaron: That's been in spec for a few months.
  dbaron: Shane said in Paris he'd implemented it,
  dbaron: And thought it worked.
  dbaron: If people are happy to resolve to publish that's fine.

  RESOLVED: Publish new working draft of CSS Transitions

CSS Shapes

  astearns: I've updated this spec.
  astearns: Some clarifications to interpolation that I need to add.
  astearns: Add section describing box keywords,
  astearns: Especially margin box.
  astearns: There's minor changes to inset circle and ellipse to
  astearns: Then I will ask for last call.

  fantasai: Sounds good.
  fantasai: I would be OK with LC.

  astearns: Interpolation stuff doesn't work.
  fantasai: Any other things?

Backgrounds and Borders 4

  leaverou: The border clip property,
  leaverou: Show only corners, etc.
  leaverou: I'm wondering about syntax and names.
  leaverou: Border clip is confusing.
  leaverou: It doesn't draw and then clip.
  leaverou: It doesn't show 2/3 of a dot.
  leaverou: Maybe call it border parts?

  fantasai: There's a couple of proposals:
  fantasai: Border parts property,
  fantasai: Awkward for common cases.
  fantasai: We need length for both what is shown and what is hidden.
  fantasai: Do we want low level syntax or an easier way to handle
            common cases?

  <TabAtkins> I think common cases are sufficient, surely. Complex
              cases, just use border-image.
  <TabAtkins> Need to show only corners, and no corners, and that's
              about it.

  leaverou: Border-corner-shape,
  leaverou: Scoop, notch, bevel.
  leaverou: I've built a demo of that property
  <leaverou> http://leaverou.github.io/border-corner-shape/

  leaverou: It only accepts one keyword.
  leaverou: I'm wondering about the name.
  leaverou: Border-corner-shape is long.
  leaverou: Corner shape isn't obvious that it's related with border
  leaverou: It's a good idea to have border radius defined the fallback.
  leaverou: Fallback for diamond is ellipse.
  leaverou: The bigger the corner, the more unrelated having border
            radius as fallback is.
  leaverou: You often want rounding where a straight edge join the
  leaverou: Maybe cubic bezier function,
  leaverou: Instead of only four keywords?

  * TabAtkins likes 50% / 50%
  <glazou> leaverou, clean, simple, understandable at first glance by
           anyone, probably possible to find better keywords for values.
  <glazou> 'curve inside' 'curve outside' 'square inside' ' square
           outside' 'diagonal'
  <TabAtkins> glazou, "square outside" is just "ignore border-radius",
  <glazou> TabAtkins, yes
  <TabAtkins> kk

  Dino: Where are these?
  fantasai: ED of backgrounds and borders 4
  <Bert> -> http://dev.w3.org/csswg/css-backgrounds-4/#border-corner-shape bg-4

  leaverou: According to ED it only accepts one keyword.
  <TabAtkins> I wanna ask implementors about cubic-bezier feasibility.
              Curves are already complicated/slow to implement, dunno if
              cubic-bezier is lots slower or about the same.
  zcorpan: If you want rounded corners on bezel, would it make sense to
           use border-radius for that rounding?

  zcorpan: What are the different shapes for corner shape?
  leaverou: Scoop which is like negative border radius,
  leaverou: Also notch.

  zcorpan: You might want a little radius on corners of the shape.
  leaverou: We don't know how to do that.
  zcorpan: You should use border radius.
  leaverou: That seems complex.
  <TabAtkins> That seems *very* complex. (zcorpan's).

  * glazou thinks his proposal above is super readable by anyone
  <TabAtkins> What if you want to bevel your notches? Use border-image.
  * glazou thinks we should start an IRC qdb

  leaverou: If you just want some rounding, do you need complexity of
            border radius?
  leaverou: Like elliptical?
  zcorpan: You're saying that's too much weight in border radius? Only
           have one value?
  leaverou: You could apply to one corner.
  zcorpan: How would it result in elliptical border radius?
  leaverou: You would have to apply to all three joints.

  fantasai: The bezier function would get you everything you want?
  fantasai: How do you join different colors etc.?
  Bert: Notch just works--it's really simple.

  fantasai: One other feature.
  fantasai: For repeat there'd be an extend keyword.
  fantasai: If you have gradient somewhere,
  fantasai: You clip it.
  fantasai: The color ends at the end of the gradient box,
  fantasai: It doesn't keep going.
  fantasai: It fills background margin area but then stops.
  fantasai: If the image has property of paint outside boundary, it
            would keep painting,
  fantasai: Rather than ending at the boundary of the image.
  fantasai: That's one of our random ideas for the spec.

  fantasai: Does anyone have other ideas? Multiple borders?
  Leaverou: I'd vote for that.

  <TabAtkins> "background-repeat:extend" lets you size a gradient with
              background-size but still have it fill the background
  <TabAtkins> Probably low-value, but it's been some time since I
              recalled why I wanted it originally.
  <TabAtkins> border-colors!
  <TabAtkins> border-colors: green 1px, red 5px, yellow 3px; Something
              like that.

  <glazou> Multiple borders have been in Gecko for ages.
  <glazou> See https://developer.mozilla.org/en-US/docs/Web/CSS/-moz-border-top-colors
  fantasai: Should we work on multiple borders?
  dauwhe: yes!
  <TabAtkins> Would probably take some pressure off 'outline' to be a
              second border.
  Bert: Use grid and allow regions to have holes in them,
  Bert: With nested regions.
  fantasai: That's pretty complicated.
  Dino: yes!

  dbaron: Does multiple borders mean multiple colors within a border?
  dbaron: Or multiple border styles?
  <TabAtkins> Probably. Don't see requests for multiple border styles.
  <TabAtkins> People just want some friggin' rainbow borders.
  <glazou> dbaron, I'm not sure the latter is needed.
  <TabAtkins> Or more seriously, 2 or 3 tone borders.
  <TabAtkins> Without the limitations of using inset/outset style.
  <glazou> TabAtkins, old iOS style buttons required 3 or 4 IIRC
  <TabAtkins> I propose we copy Moz's current behavior. ^_^
  <glazou> TabAtkins, +1
  <fantasai> TabAtkins, border-colors? No, you really really really
             don't want that.
  <leaverou> TabAtkins: god no, that's awful
  <TabAtkins> Hey hey, someone talk about *-1, *-2 longhands for every
              list-valued property.
  <TabAtkins> Hahaha
  <dbaron> Just wait until we put zero-width non-breaking spaces in all
           the things.

  Leaverou: Make it a list.
  Dino: Make a proposal.
  Dino: There's lots of little dragons here,
  Dino: Which won't happen until you try to write spec.

  Bert: multiple everything!
  dbaron: No, only one border radius.
  Bert: What about border-clip?

  plinss: There may be interesting holes there.
  fantasai: Action item to write up a proposal.

Longhand for list properties

  fantasai: If you have a list valued property, then dash-number
            represents that position in the list
  plinss: What if you have -47 with a list of 3 items?
  fantasai: The dash ones won't take comma.

  <TabAtkins> Need to make sure that every list has a "null" value.
  <TabAtkins> So unfilled values between explicitly-given ones get the

  plinss: I'm concerned about cascade.
  <TabAtkins> Why concerned about cascade? This is standard longhand
  <TabAtkins> (I think most (all?) list-valued props already have null

  plinss: I'm going back and forth about the proposal.
  plinss: It's not the time or place for serious discussion.
  plinss: Let's adjourn. Thank you everyone.

[End of Meeting]

[Post-Meeting Conversation]

  <TabAtkins> The list-valued shorthand expands into an infinity of
              indexed longhands. You only serialize up to the last
              explicitly-given index.
  <leaverou> This solves some use cases, but not all.
  <TabAtkins> Never try to solve all use-cases.
  <TabAtkins> Gotta keep 'em hanging on for more.
  <leaverou> Quite often you don't have knowledge of all the items in
            the list and just want to add something in the beginning or
            end (sort of like a .push() in arrays)
  <TabAtkins> Yeah, but that's impossible here. :/
  <TabAtkins> We just don't have the structure for it.
  <leaverou> So you'll end up with stuff like how people do z-index:
             100000000000000000 to be at the top
  <leaverou> And no solution for how to add something to the beginning
             (unless negative indices are allowed)
  <TabAtkins> Yes.
  <TabAtkins> Correct, these are limitations.
  <leaverou> These are very serious limitations.
  * fantasai supports leaverou's concerns.
  <TabAtkins> "Put me at the top" is always a self-defeating desire.
  <TabAtkins> As soon as two places want to be on top/bottom.
  <leaverou> Obviously, it's better than nothing, but I think it's worth
             it to try and find a solution that covers at least, I don't
             know, half the use cases :P
  <TabAtkins> Mine covers half!

  <dbaron> We should figure out additive cascading instead.
  <leaverou> dbaron++
  <TabAtkins> dbaron: If you think that's feasible.
  <fantasai> Then you'll need variables for the position of the thing of
  <fantasai> So property-name-variables.
  <TabAtkins> fantasai: Nah, only if you want readability.

  <leaverou> TabAtkins: Obviously it's difficult to prove that, but I
             doubt it even covers 1/3.
  <TabAtkins> leaverou: While we're throwing around arbitrary numbers,
              I'll assert that it covers at least 4/5.
  <TabAtkins> Which hits the 80/20 rule and means we don't have to try
              any more.
  <leaverou> You just pulled that number out of your bum, just like I
             did :P
  <TabAtkins> leaverou: I thought that's what we were doing!
Received on Thursday, 21 November 2013 23:43:50 UTC

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