- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 21 Nov 2013 18:43:22 -0500
- 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.
Transitions
-----------
- 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.
=====FULL MINUTES BELOW======
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
order?
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
conventions.
astearns: It's about document conventions?
fantasai: How to read a propdef table is largely about document
conventions.
<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
shrug.
<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
non-normative
<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.
* 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
center.
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
ambiguity.
<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
snowflake.
<fantasai> TabAtkins: It's special in having 3 dimensions of position
already.
<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
background-position
<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
level.
<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
Transitions
-----------
<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
clarify.
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
radius.
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
shape.
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",
no?
<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
area.
<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
null.
plinss: I'm concerned about cascade.
<TabAtkins> Why concerned about cascade? This is standard longhand
expansion.
<TabAtkins> (I think most (all?) list-valued props already have null
values.)
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
interest.
<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