- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 16 Apr 2014 20:41:49 -0400
- To: www-style@w3.org
Fallback for "ch"
------------------
- RESOLVED: Default for CH unit is 0.5EM
Add -x/-y longhands to background-* properties
----------------------------------------------
- RESOLVED: background-position-x/-y, background-repeat-x/-y
approved for level 4 of backgrounds and borders.
- background-size-x/-y was also discussed, but didn't garner much
support.
Image Orientation for Backgrounds
---------------------------------
- RESOLVED: Make the image() function always respect EXIF
orientation metadata.
- The future of comma delimited lists in images was also raised,
but there was a feeling of unpreparedness, so discussion
will continue on the list.
Changing MediaQueryList to use events
-------------------------------------
- There were lots of questions about the implications of this
change.
- The main issue was how a single event that would change multiple
items would be handled. TabAtkins will bring this item to
the mailing list for feedback.
Scrollbar Tracking Control
--------------------------
- TabAtkins presented the idea for being able to position the
scrollbar at a certain distance from the bottom once you
scroll to the bottom of the content.
- There was discussion about the use cases for a property like
this and the interplay between this proposed property and
sticky positioning.
- RESOLVED: Discussion continues over e-mail
Subgrid
-------
- Deferred to next week
calc() pow operator
------------------
- The working group wasn't against adding a pow operator, but some
people didn't feel there were sufficient use cases. General
feeling was that this is something that can be done in the
future, but is not a priority.
====FULL MINUTES BELOW======
Present:
Glenn Adams
Rossen Atanassov
Tab Atkins
David Baron
Bert Bos
Dave Cramer
Elika Etemad
Sylvain Galineau
Daniel Glazman
Koji Ishii
Dael Jackson
Brian Kardell
Taichi Kawabata
Brad Kemper
Philippe Le Hégaret
Chris Lilley
Michael Miller
Matt Rakow
Florian Rivoal
Simon Sapin
Dirk Schulze
Alan Stearns
Greg Whitworth
Steve Zilles
Regrets:
Simon Fraser
Peter Linss
Simon Pieters
Anton Prowse
ScibeNick: dael
glazou: Let's get started.
glazou: plinss isn't going to be here today, so I'm chairing. Any
extra items? I saw TabAtkins's.
Extra Item: Fallback for "ch"
-----------------------------
TabAtkins: The ex unit says that if font metrics are impossible
you can use a fallback, but ch doesn't have similar
wording.
TabAtkins: I just suggest we have similar wording that allows the
fallback of 0.5em in the exact same cases.
TabAtkins: Any objections?
glazou: I saw ChrisL say he's okay
glazou: Any other opinions? Objections?
glazou: No one cares?
<fantasai> seems fine to me
<dbaron> I wouldn't want this fallback to happen too often, but it
sounds ok
glazou: No objections?
SimonSapin: There was an IRC comment that said it would be easier
to just register not support the ch unit.
TabAtkins: That seems inconsistent with the ex unit.
SimonSapin: I don't really have an opinion.
TabAtkins: If it means a syntax error you won't know it's font
stuff after parsing time. If it's something else you'll
fail weird so it may as well be as close as possible.
SimonSapin: Okay.
glazou: Any obj?
RESOLVED: Default for CH unit is 0.5EM
Add -x/-y longhands to background-* properties
----------------------------------------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2014Apr/0085.html
TabAtkins: So several browsers, webkit blink have supported
background-position-x/-y
TabAtkins: There's been some debate on this but I believe the plan
on record is that we're going to add both variants of
names and have a mechanism to decide which.
TabAtkins: That allows us to add both background-position and
background-repeat -x-/y
TabAtkins: So I think we should add because authors rely on it.
TabAtkins: I think it gets odd with size, but we can make it work.
I'm not sure if there are others that need to be split;
position, size and repeat.
dbaron: I'm definitely in favor of it for background-position, but
I'd like to see data on who supports the others,
especially size because of the difficulties with cover and
contain.
TabAtkins: I don't know if anyone does size, but webkit does
repeat with some odd work arounds. I'm not sure if
anyone else does, though.
MaRakow: For IE we support it with the value of repeat-x and
repeat-y.
TabAtkins: They do background repeat property with those keywords?
MaRakow: Right.
MaRakow: We don't support the individual properties, just the one
property with those values .
<gregwhitworth> Yeah I'm testing background-position-x and that
doesn't work in IE.
<gregwhitworth> So webkit only.
koji: I think that possibly fantasai or someone from Mozilla was
especially opposed in the past.
fantasai: It was largely because concerns about interactions with
logical version of properties and if that's sorted, and
I think it might be, than there's not reason not to.
fantasai: It's a question of if this is compatible with start and
end keywords.
TabAtkins: Plan is to support background-position-inline and other
features.
koji: We had to use adjust position?
TabAtkins: Right now position and repeat. Those are the two I'd
like resolution on today.
fantasai: I think dbaron wanted more data on repeat.
fantasai: Let's just position now
TabAtkins: He only asked who supported repeat.
dbaron: So what are the values of repeat x/y?
TabAtkins: yes/no/repeat and no-repeat
dbaron: I'm okay with position and repeat.
SimonSapin: I'd like a proposal on how we'll do logical directions.
fantasai: I think this should be B&B 4 along with the logical
keywords.
TabAtkins: I don't want to delay to 4 since it's not real yet and
both these properties have been supported for a long
time.
TabAtkins: Position definitely can get into 3's CR and repeat
could likely too.
dbaron: I'd rather not add to 3. We've done it too much.
krit: So if we do it in 3 it should be in version CSS Masking 1 as
well?
fantasai: I think we should do this in 4 and people can support
earlier.
fantasai: -x and -y have been around for a long time.
fantasai: We have a legacy prefix and clause.
TabAtkins: So add background position and background repeat -x/-y?
Bert: The reason to have these in the past was to quickly switch
background but now that we're using media fragments, do we
still need it?
* fantasai glazou, I have a follow-up to Bert's point
TabAtkins: No one supports media fragments yet.
dbaron: Gecko supports it.
<dbaron> ... or we're very close to it
TabAtkins: They're used commonly.
glazou: dbaron did you say Gecko supports?
dbaron: I'm not sure. We're close.
sgalineau: It'll be a while before people can depend on it.
fantasai: So one of the...this is different but related. In the
images 4 draft we have a function that takes comma
separated list, but no one supports it.
fantasai: But there were various reasons to support. We marked
comma separated as at-risk and I think we should drop
that.
krit: Webkit, it is mostly the test suite that's missing.
TabAtkins: I can work on that now that I know it's a thing.
fantasai: The test suite for what?
TabAtkins: Image function.
fantasai: I still think we should push commas to level 4 and
figure out how it can interact.
TabAtkins: Can we defer since that's tangential?
fantasai: Yes.
TabAtkins: So from before, are there objections to background-
position and background-repeat -x/-y in Level 4?
fantasai: I'm okay if we add logical keywords at the same time so
we can make sure they work out correctly.
TabAtkins: Sure.
glazou: Sounds like a compromise
krit: I would like to have a follow-up resolution.
glazou: Okay.
glazou: Any objection to setting -x/-y to background-position?
bert: I don't think we should add properties that make things
confusing for authors. They can use position already, so
unless there is a really strong use case, don't add more
redundant properties
glazou: I think browsers are implementing the longhands.
rossen: For the background-repeat we support repeat-x repeat-y
because we thought of those as mutually exclusive. What
would the both specify to repeat?
TabAtkins: That's a longstanding part of background. Those values
for position translate into longhand values.
TabAtkins: Background-repeat-x becomes background-repeat-x-repeat.
rossen: So when I spec that they both repeat, are you saying only
one repeats?
TabAtkins: That's the repeat value. It has four values, repeat on
either end.
Rossen_: Okay, than it's fine.
glazou: So any objection?
RESOLVED: background-position-x/-y, background-repeat-x/-y
approved for level 4 of backgrounds and borders.
krit: Should we also do this for masking level 1?
TabAtkins: I'm fine either way.
glazou: Is there a use case?
TabAtkins: I don't know
krit: There's prefixing so perhaps we need it for alignment
krit: It can wait for masking 2
<SimonSapin> background-repeat/position: also, resolved to add
logical directions at the same time
Image Orientation for Backgrounds
---------------------------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2014Apr/0149.html
glazou: This is something Boris posted.
TabAtkins: I'd prefer for that to stay on list. Well, not talk
syntax now, but we can discuss ideas.
TabAtkins: Does anyone need refresher on the idea?
[general consensus of yes]
TabAtkins: If you're familiar with EXIF metadata, orientation can
be whatever and some cameras will record that.
TabAtkins: So later it can be displayed however you held your
camera.
TabAtkins: The web doesn't normally care, it just displays the
same as in image. This would allow you to display how
you took it.
TabAtkins: Boris brought up where people were asking to auto-apply
the rotation in the background. So the suggestion was
to add this to the image function either as auto or as
a keyword you can opt into.
ChrisL: I think option 2 is better, first because some cameras get
it wrong and second, because some viewers don't do it so
people manually rotate.
<gregwhitworth> Not to mention it's possibly creates a huge compat
issue
dbaron: I actually disagree because in a vast majority of cases,
they want EXIF to be honored.
dbaron: If image always honors EXIF people will see it's wrong and
fix it first so then when we build new things we should
honor it.
TabAtkins: If we do by default, should there be a way to turn it
off?
ChrisL: There's lots of content such as JPEG where it is not
honored. So we'd change existing webpages.
dbaron: We're not changing existing webpages because it's only if
people use this new feature.
ChrisL: That's what I mean by opt-in.
dbaron: We want to say all the features of this new thing rotate.
<Bert> (url() continues to ignore EXIF, but image() honors it.
Subtle, but might just work...)
glazou: So the conclusion is this is a feature we want and want to
continue technical discussion on the ML?
TabAtkins: We may have resolved. I'm okay if image() should always
respect EXIF metadata.
* ChrisL yay go for a resolution
???[attributed to dbaron]: That's fine
<dbaron> that wasn't actually me, but I'm also fine with it
Bert: I think that's okay, given that we don't have tests for it
yet, anyway.
florian: As long as it's contained to image() it's fine.
RESOLVED: Make the image() function always respect EXIF
orientation metadata.
<sylvaing_> always or will we ever want an override in image()
fantasai: On that topic can we have the image() function drop
comma separation and decide if we want that level 4?
TabAtkins: I'm cool with that. I'd like fallback to
interoperability better so let's do that.
krit: Wait, then you can't extend image later and attach
mediaquery-like features like adding images.
krit: You can't do that later without commas.
TabAtkins: We're not removing commas, just the list feature. We're
recasting image() as a better url for images.
<fantasai> http://www.w3.org/TR/2012/CR-css3-images-20120417/#image-fallbacks
fantasai: We're dropping this feature (above), but keeping image
fragments and solid color images
krit: But not comma separated values, just one value, one string.
krit: That's a big step. Wasn't image supposed to allow fallback
features?
fantasai: That's the intent, but we want to address it in level 4.
fantasai: You may want to change which image due to supported,
size of screen, and visibility and there's no coherent
solution.
fantasai: Since we have those requirements when we designed
fallback, we want to come up with a solution that makes
it work together.
fantasai: For now we know for sure we want EXIF metadata and solid
color images to work as well as mediaqueries.
fantasai: That's all straightforward and should stay in CR.
krit: Do we need to rush this decision or can we stay on the ML?
krit: You can get feedback so people that are interested can speak
TabAtkins: Are you implementing?
krit: No, I know there's a patch.
krit: In general I don't feel confident resolving. Can we talk
next week?
sgalineau: Quick question, if you want to override you'd have to
do it manually or is there override?
TabAtkins: Right now you'd have to do URL, but I'm fine with a
keyword.
* fantasai override what?
* fantasai missed that
<SimonSapin> fantasai, EXIF orientation
* sylvaing_ override EXIF i.e. if you need to do that, do you use
url() or would we some day add a flag to image()
* sylvaing_ was clarifying the resolution which said image() would
*always* respect EXIF
* fantasai ah, right. :) Yeah, i think just tossing in an <angle>
into image() would do it
* sylvaing_ fantasai, an angle, really? So I could set 31.7deg?
there is a use-case for that?
<BradK> sylvaing: I also question the use case for angle (
something like [vertical | horizontal] seems better to me)
but that's a separate topic.
<sylvaing_> BradK: yes. my understanding is that there is at most
4 angles here so <angle> seems odd
* sylvaing_ actually, EXIF has 8 orientations but <angle> seems
even odder here:
http://www.impulseadventure.com/photo/exif-orientation.html
* MaRakow sylvaing, agreed there doesn't seem to be a great use
case for arbitrary angles, but seems difficult to put
appropriate names on the orientations of an image where
you don't really know which way is up
<BradK> sylvaing: Spec has it rounding up to 90deg increments, but
even so, seems to rely on knowledge of content of whatever
page and image it is used on.
<sylvaing_> MaRakow: my initial suggestion was to have a flag that
says 'behave like url()'. Specifying an orientation is
something else...
* MaRakow ah, I see -- yeah, that sounds simpler
<sylvaing_> MaRakow: yeah, the idea was there is a feature of
image() you want to use but you want the EXIF metadata
ignored. not sure it matters. we'll see...
* krit TabAtkins just to make sure, it is not an existing patch
for WebKit that makes me careful on changing image()
without thinking about it more.
Changing MediaQueryList to use events
-------------------------------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2014Mar/0603.html
TabAtkins: The thing returned by the match function has a custom
fallback for when they stop matching.
TabAtkins: The suggestion is to switch to using the event listener.
TabAtkins: This is a very minor behavior change if you're
depending on specifics on how events vs callbacks are
registered.
TabAtkins: I suspect that's rare.
TabAtkins: The benefit is this makes us more standard event style
and reduces special case code.
TabAtkins: Boris said there's no code, but Elliott from Blink said
there's a lot of extra code to do this in Firefox,
Webkit and Blink
TabAtkins: We'd like to drop and use standard event process.
<dbaron> I don't know where this extra code in Firefox is.
florian: If we're starting from scratch, sure, but this has been
out.
TabAtkins: You can move cleanly to the event-base except for a few
edge cases that are difficult anyway.
TabAtkins: Only change is timing and, if you register the same
function multiple times, if it gets called once or twice
florian: If it's that tiny, why is it so much code?
TabAtkins: Because it's re-implementation a portion of what we do
for events.
TabAtkins: With events we just do a few lines of hookup code which
works.
TabAtkins: From the thread I don't believe there were strong
objections. Boris had minor objections because he said
it was easy in code, but Elliott pointed out it wasn't.
TabAtkins: Are there objections now?
dbaron: What are the rules?
TabAtkins: I don't know if current spec defines them, but event
spec does.
dbaron: What does event spec define as?
TabAtkins: I don't know.
dbaron: I'd like to know before I agree.
dbaron: I want any added listeners to not effect...Like if you add
a new listener in the middle I want the event not to fire.
TabAtkins: Is that specific to mediaquery, or is this in general?
dbaron: I don't know.
dbaron: Part of the problem is you can fire the event on multiple
listeners so multiple MQ change as a result of same thing.
Event spec will define a single event, but not multiple.
TabAtkins: That's because it would be multiple callbacks.
dbaron: What we have to define is that a single thing causes
multiple things to change. The MQ change adds an event to
another event that changed and does that event happen if
it's fired later?
TabAtkins: It seems like you just want this to be well defined in
general, not just in this case.
dbaron: I think the problem is if we make the change we'd have to
define order. If you can define listeners that fire within
each other it matters what order they happen.
TabAtkins: And I think the callbacks don't handle order
dbaron: But the callbacks don't effect each other, at least not in
Gecko.
florian: Is that gecko specific? Because unless it's in spec we
have the same problem.
dbaron: So I guess I'm okay with it.
TabAtkins: I'll post to the thread to make sure we get some
discussion about that.
glazou: Okay. So discussion continues on ML
Scrollbar Tracking Control
--------------------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2014Apr/0112.html
TabAtkins: This is an issue that I've been trying to bring up for
a year.
TabAtkins: It would be convenient if CSS could declare that a
scrollbar in an element, once it's close to the bottom,
attaches to the bottom
TabAtkins: This is common in chat windows and things were you
continually add content to the bottom of the list.
TabAtkins: It's quite hard to get this to work well. Gmail has a
constant fight with the chat windows; getting them to
stick when the height can change unpredictably.
TabAtkins: So have something where if a user scrolls a certain
distance from the bottom it stays.
florian: Do we need a distance or can we say distance zero?
dbaron: I was trying to find my objections and I think I've found
them.
<dbaron> http://lists.w3.org/Archives/Public/www-style/2012Dec/0077.html
dbaron: I think my biggest one is that I think it's not
particularly related to distance from the edge.
dbaron: It's more to which end the content should stick to no
matter where you are relative to the edge.
dbaron: There's cases where people will add to the top and you
want to maintain scroll relative to top such as with
twitter.
dbaron: So you want to hold scroll close to bottom.
TabAtkins: Twitter adds content on both sides. So that would be if
you're sufficiently far from the content added so you
adjust your scroll so the content doesn't move.
florian: So you may not want to maintain because if you scroll up
to read more, you want to stay there unless you're at the
bottom.
florian: I think I'm with TabAtkins, but with that user case.
TabAtkins: I think that's interesting and useful, but different.
I'd be willing to look into it.
<BradK> When you are at the bottom of twitter, you do NOT want to
stay at the bottom when new content is added to the bottom.
You want to stay on the tweet you are on.
dbaron: But I think what I'm objecting to is that it should be two
properties, not one.
TabAtkins: Can you elaborate?
dbaron: It's too long ago.
TabAtkins: Maybe it was semantic, where it should be about any
edge?
TabAtkins: That way you could add to either side and it would
stick?
TabAtkins: Is this something you'd like to discuss on thread?
dbaron: One this was which end the content was coming from and the
other was how different you are from the edge.
florian: I'm not sure that would work in twitter. Content can add
from both sides.
TabAtkins: If you're willing to discuss on the list, that's okay.
I've brought it up and got crickets and I want to make
progress.
dbaron: You should go ahead ... I don't have time to discuss it.
florian: If we get snapping to scroll would that fix it?
TabAtkins: Current proposal is that the user agent defines. There
may be cases where you want to say exactly how far you
are from edge.
florian: Where would you want to not be at the edge?
TabAtkins: For example, when I use IRC cloud it does only at edge
and it messes up because you can't scroll through the
edge. I'm not sure where the bug is, but you can be 2px
from the edge and can't get all down.
* sylvaing_ hasn't noticed that in Aurora fwiw.
* sylvaing_ uses IRCCloud.
* krit sylvaing_ me neither in Safari
* sylvaing_ agrees; hasn't seen it in Safari either
florian: But if you do scroll snapping, you can do it.
MaRakow: I think if you have multiple snap points and the content
changes enough you may snap to a point that's further
away and snap to the middle. But that would happen here
too if you can define multiple.
TabAtkins: This is just top, bottom, left, or right. And if you
define distance from edge you stay the same distance.
MaRakow: So this is on the scroller?
MaRakow: So when you're resizing and want to keep your content it
would be off?
TabAtkins: That's part encompassed by twitter case, but it's
beyond what I'm asking for. It's interesting, but
doesn't tie in.
florian: Your 2px thing sounds like a bug not a use case.
TabAtkins: Could be, but sometimes I don't scroll all the way down
and it doesn't recover.
* sylvaing_ thinks we should establish that this is a reproducible
cross-browser issue that derives from CSS
* sylvaing_ specifically, some simple repro of the Gmail chat
logic may help here...
florian: If you scroll close the the edge but not quite with this
new prop, the person that designed the thing with
incorporate scroll snapping, take you to the edge, and
have you stick there.
MaRakow: Also, I feel like this is similar to the use case for
keeping the same content in view while resizing
responsive web pages.
<dbaron> I think this design isn't great for extending to say
whether it's distance-from-top or distance-from-bottom
that you want to hold constant when the current scroll
position is in the middle
TabAtkins: I don't think this links to snapping. Because having
something that moves you all the way is sometimes
useful, sometimes annoying.
TabAtkins: They work well together, but shouldn't be tied together
explicitly.
glazou: So any objections to continuing discussion in email and,
once stable, TabAtkins requests an ED?
glazou: I think this is interesting and want to see a proposal.
TabAtkins: The proposal is in the e-mails, but we can discuss.
glazou: I'm going to contribute too. Let me think about it.
TabAtkins: Contribution is what I need
RESOLVED: Discussion continues over e-mail
glazou: Any remaining items that can be done in 4 minutes?
Subgrid
-------
fantasai: There was no discussion on ML
TabAtkins: Yeah, not in 4 minutes
glazou: Okay
TabAtkins: I think the pow operator?
calc() pow operator
------------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2014Apr/0057.html
TabAtkins: So it was suggested to add pow operator to calc().
There's a unit as the base on one side and the exponent
on the other.
TabAtkins: Seems reasonable and no odd problems as long as we keep
the exponent non-negative.
TabAtkins: Only issues is precedence. You'd have to use
parenthesis for anything more than a single number.
TabAtkins: Presumably this is only when both are unit-less
TabAtkins: Given that we're not using unit algorithm both things
need to be a number, but you can multi by 1px to
convert to px.
fantasai: I missed the use case
glazou: Me too.
glazou: I wonder if it's worth the implementation. Of course the
browser vendors get final word.
TabAtkins: The use case was in the link. It's for mathematically
pleasing things.
* dauwhe I'm skeptical about the use case
glazou: I have no real opinion. I think we can, but don't see the
interest.
TabAtkins: It's low value, but simple and does have cases.
glazou: If we follow that path we'll need sin/cos etc. because
that's what we do with complex animations.
glazou: I'm not sure if we want CSS to have a full calculator.
TabAtkins: I'm not sure it's slippery slope, but I can understand
it's not important enough.
fantasai: I think we don't have to address this. We can do
variables now so you can do variable constants. This can
be a preprocessor.
SimonSapin: Did I miss the use case?
TabAtkins: It's the link in the agenda.
glazou: I'm not hearing consensus. I think consensus is we can do
this in the future, but it's not high priority.
sylvaing_: I think the common opinion is we're unsure what it is
for.
glazou: So I think we won't resolve for the time being.
glazou: So we're 2 minutes past the hour. The two remaining items
will be for next week. Talk to you next week!
Received on Thursday, 17 April 2014 00:42:20 UTC