- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 24 Sep 2014 19:52:17 -0400
- To: www-style@w3.org
Joint meeting with dpub
-----------------------
- The group was very interested in meeting with dpub.
- dauwhe will suggest the Monday breakout time to the dpub group.
- Rossen will also investigate a joint meeting with the user
interface task force.
CSS Images 3
------------
- TabAtkins came to the group asking for approval to bring some
items he had been working on in Images 4 up to Images 3 since
he felt they were already stable items and therefore should be
in the spec that's closer to REC.
- RESOLVED: Allow nearest neighbor for image rendering in both
directions but allow browsers to do prettier in the down
directions.
- RESOLVED: Include image rendering in level 3.
- RESOLVED: Close this issue (regarding guessing resolution from
file size) with no change because we'll fix it later in
harmony with HTML.
- TabAtkins will send an e-mail to the list regarding the details
of his plan for lifting restrictions on nesting with image set.
- RESOLVED: Have image set in level 3.
- RESOLVED: Move crossfade to level 3 of Images.
Sizing of floated ::first-letter
---------------------------------
- RESOLVED: Remove special case from ::first-letter
Overriding an important style
-----------------------------
- There was support for altering the property to conform with
author expectations, however there was some concern about
possible breakage.
- We will revisit the issue after there has been time to write
tests to confirm there's no compatibility issues.
====== FULL MINUTES BELOW ======
Present:
Rossen Atanassov
Tab Atkins
David Baron
Bert Bos
Dave Cramer
Daniel Glazman
Dael Jackson
Chris Lilley
Peter Linss
Shinyu Murakami
Edward O'Connor
Anton Prowse
Lian Quin
Matt Rakow
Florian Rivoal
Simon Sapin
Dirk Schulze
Mike Sherov
Greg Whitworth
Regrets:
Bruno Abinader
Adenilson Cavalcanti
Simon Fraser
Sylvain Galineau
Mike Miller
Lea Verou
Scribe: dael
plinss: Let's start
plinss: Any additions to the agenda?
plinss: I'll take that as a no.
Joint meeting with dpub
-----------------------
dauwhe: I didn't know what the procedure is to set this up.
plinss: Doesn't matter as long as we know.
dauwhe: They're interested in the box tree stuff. dpub has a force
on dom pagination or something like that
dauwhe: They're at the end of the week and we're at the beginning.
plinss: Are there times they would be available or would be better
for us to meet?
dauwhe: I'll ask them.
plinss: Anyone in our group that wants to be there but has time
restrictions?
<glazou> me
Rossen: I think it would be good to see what they want to bring
plinss: Should we invite them to our normal meeting or use our
breakout time?
<TabAtkins> I'm fine with taking a bit of normal time if necessary.
dauwhe: I would say the breakout time is longer and that's a good
way to use it.
dauwhe: That's what I thought. Some people in dpub were worried
that people wouldn't follow the schedule and use the
breakout time for regular meeting, but I think this is a
great use of the time.
dbaron: I think the AC meeting is also in that time.
plinss: I think that's Tuesday. Looks like Monday breakout is good
to suggest.
dauwhe: I'll start with that.
Rossen: While we're on the topic, there's the user interface task
force.
Rossen: They currently are looking at defining editing behaviors.
Based on our last F2F discussion I think there's an
overlap between some of our intentions and what these guys
want to do.
Rossen: Talking to Ben Peters they might also want to attend a
joint meeting. Same protocol?
plinss: Sounds reasonable. Maybe you coordinate a time or put them
in touch with me or glazou and we'll coordinate.
CSS Images 3
------------
TabAtkins: As part of the F2F we said we'd re-publish since the CR
is 2 years old.
TabAtkins: The older text hasn't been touched, I've only been
doing work on level 4.
TabAtkins: I thought it was more reasonable to strip 4 down and
use it in 3. It means there might be still some errors
that have level 4 references.
TabAtkins: If there's anything else we can catch those. I need
sign off on a few features that have been implemented
for a while and are stable enough for CR level draft. I
need approval.
TabAtkins: First item is image-function so it doesn't do URL
fallback.
TabAtkins: That shouldn't be controversial.
TabAtkins: Second item is I've moved 3 functions, image-set
function which is implemented by webkit and equivalent
to picture. Cross-fade function for same reason.
TabAtkins: Also image-rendering that controls interpreting pixel
as you scale up or down. It's implemented in at least 2
browsers so it's already stable.
krit: Most of the properties you mentioned were in webkit before
the fork in Images...
TabAtkins: The two functions aren't in independent. Image-
rendering is in Firefox and webkit.
florian: Other than what you've listed explicitly, are all the
changes from resolutions or are there things you thought
were good ideas?
TabAtkins: I believe all resolutions. The only other change I can
think of is that image function auto-rotates when
before it was an explicit special value, but that's
from a resolution
florian: The other changes are linked?
TabAtkins: Yes. I'll go through and verify to make sure I haven't
made further unintentional changes, but those are the
ones I intended.
dbaron: What's now in 4 that isn't pulled back?
TabAtkins: Element function, and a few other bits.
[TabAtkins looks at the spec]
TabAtkins: Conical gradients.
TabAtkins: That's it. Those two.
dbaron: And bidi images.
TabAtkins: Yes. Images 4 is now out of date because of the text
changes in 3. I'll backport in a while. Or reset 4 to a
delta spec until we're ready for it to be stable.
MaRakow: I think in general it makes sense. I feel better about
things that are in other browsers instead of the ones
only in pre-fork webkit.
ChrisL: So images 4 isn't in WD
TabAtkins: Yes.
ChrisL: So would we need another LC?
TabAtkins: This would be a new process LC/CR
ChrisL: Okay, so it doesn't matter.
plinss: Is that true? If we're in CR we can't change to the new
process?
Bert: I think it would be great to publish a WD for 3 weeks and
than go back to CR.
ChrisL: The point of doing that would give a chance to go back. So
as things coalesce it can get comments in CR.
Bert: But CR means it's cemented and WD doesn't.
ChrisL: But it used to. Now CR means we want comments.
<ChrisL> I don't oppose dropping all the way back to WD but I
don't think it is needed, we can go straight to LCCR
which is the new proceed for "edited CR"
florian: Given that there are a lot of changes, should we publish
a CR that we haven't read?
TabAtkins: You've read the level 4 draft.
florian: We haven't read it as a CR.
florian: Can we have actions to review it?
TabAtkins: I'm fine with waiting for a few weeks and brining it up
again.
ChrisL: So, to be clear, people want it to be a WD again and I
don't think we need to because LC/CR is meant to allow you
to republish and disclose new features. I'll do whatever
people want.
TabAtkins: I'm fine with give the group 2 or 3 weeks of time and
then asking for LC/CR publication
ChrisL: Makes sense.
plinss: I think that sounds reasonable. Am I remembering there was
one phase where you can't switch to the new process?
ChrisL: Old LC to CR, I think.
<ChrisL> yes, old LC to new LCCVR (which seems odd)
plinss: I'm hearing that everyone should review and come back in a
few weeks.
florian: We don't have consensus on the new functions.
TabAtkins: Image-rendering. That's implemented by two browsers. It
has auto or pixelated or crisp edges for scaling.
krit: Is pixelated the same in both implementations?
TabAtkins: Yes. dholbert just asked for a minor change that will
simplify it, but yes.
florian: Should we resolve on that suggested change while we're at
it?
TabAtkins: The change is previously the pixelated used the nearest
neighbor when things are being scaled. Nearest neighbor
doesn't have good effects when going down. It loses
information instead of scaling.
TabAtkins: Previously we said when scaling down use normal scaling.
The objection was that it was difficult to pipe in if
you're going up or down to the point you're doing the
scaling. And scaling down doesn't loose too much
information. We're mostly concerned about scaling up.
He asked it to be changed to always nearest neighbor
and doesn't care about direction.
florian: If people have something better, can we have a MAY use
different for scaling down?
TabAtkins: Current is nearest neighbor or better.
ChrisL: Currently we require bi-linear because we had
implementations that did nearest neighbor and it was
horrible. So we need to have a minimum level in the spec.
If one says explicitly nearest and the other says do what
you normally do. I'm sure we can have language that
clarifies.
TabAtkins: We have auto set up so that it can go to the cheapest
thing it can if it has limited resources.
ChrisL: I'm worried the language will get abused.
TabAtkins: People can make ugly browsers, but people will complain
about it.
florian: We do have a venue that's specifically for upscaling with
nearest neighbor? It's meant for upscale, not when you
downscale.
florian: Do we have a use case for make it ugly when you scale
down?
TabAtkins: No.
florian: So when you upscale you must and downscale you may.
TabAtkins: The spec had previously said scaling up means at least
in one dimension. Down is only if you're shrinking on
all sides.
florian: Is that reasonable with what we just said?
krit: Nearest neighbor for down and up scaling?
TabAtkins: I'm fine with adding weasel language.
plinss: Is everyone happy with the change?
<ChrisL> ok with the change, want to read exact weasel words
TabAtkins: We accept my proposal to allow nearest neighbor in both
directions but allow browsers to do prettier in the
down directions.
RESOLVED: Allow nearest neighbor in both directions but allow
browsers to do prettier in the down directions.
plinss: There's language in Images 3 [missed]. Did we ever publish
a recommendation?
TabAtkins: Yes, it was in SVG spec.
plinss: So do we need to treat as deprecated, or should it be
invalid?
plinss: If it's specified in SVG that's fine.
TabAtkins: So the large question of image rendering in level 3.
Yea or objections?
RESOLVED: Include image rendering in level 3
TabAtkins: Next is image set. Browser uses magic to decide which
one to load. This is identical to image source set.
It's implemented in webkit and matchs HTML so I thought
this was stable.
florian: This matches the latest version of HTML?
TabAtkins: The subset it addresses? This is more limited but I'd
be happy the expand in 4.
florian: This is a 3 way thing in in HTML.
TabAtkins: The third part is something I'd like to explore later.
There will be a way to do it in the future, but I don't
want to tie it into the stable set and slow everything
down.
florian: So this is equivalent to the source set in HTML?
TabAtkins: Yeah.
TabAtkins: Any other opinions or objections?
hober: I'm in favor.
plinss: There's only one implementation?
TabAtkins: Yes. Given that Firefox does source set, it may be easy
to implement image set. It's easy to translate over.
florian: This has been controversial. If people haven't agreed in
HTML I'd object, but given that HTML did settle down I'm
okay.
<ChrisL> agree with florian there.
plinss: I'm concerned about how long this will keep us in CR.
TabAtkins: We have 0 tests anyway.
plinss: We are shy on tests.
TabAtkins: I need to spend time on that. I plan to in the next
couple months.
MaRakow: There are 4 open issues. Will you port those over?
TabAtkins: They're mostly resolved in Level 3 now, I think. Let me
look.
TabAtkins: There are two issues left in Level 3. First is common
to HTML and I don't think we want to resolve on how to
address this on CSS until HTML decides.
TabAtkins: Resolution is approximate from file size, but not all
file types are like that. Vector is infinite resolution
but a small files size and image doesn't capture that
well.
hober: You can do vector without an image set.
florian: What it doesn't do is giving hints to the browser which
vector it's meant to be. The high res, the low res...
TabAtkins: Vector also suffers from small image sizes. I think we
should remove the issue, let HTML decide, and copy.
Which might be nothing.
TabAtkins: Right now vector images can be the largest resolution
and that works for now.
ChrisL: It's good as a first approximation. There's also need to
have multiple vector images.
TabAtkins: That's discriminating in a different way. Like pixel
size which image-set doesn't solve. I'm saying this is
complex and CSS shouldn't solve it. HTML and CSS should
be consistent.
MaRakow: Sounds like we should leave this is level 4 until
resolved?
TabAtkins: This isn't a large problem.
florian: There's been a lot of discussion on this and people seem
to be agreeing that what's in HTML is mostly right and
good to go. The rest may be addressed in the future, but
maybe not because no one cares enough. I don't think this
is enough to block it and being consistent make sense.
MaRakow: So can we say the issue is resolved or is it open and
pending HTML?
TabAtkins: We close for now because it's not a big deal. When it
is resolved, we participate and make it consistent.
florian: Can we make it into a note saying we know this feature
doesn't address that use case?
TabAtkins: Yes. That's something we've done before.
florian: Say it's a use case we know this doesn't address and that
will be addressed later.
TabAtkins: So, any objections to closing this with no change
because we'll fix it later in harmony with HTML?
RESOLVED: Close this issue with no change because we'll fix it
later in harmony with HTML
TabAtkins: This one is a restriction that doesn't let image set
nest. This is from when there was fallback concerns,
but we removed the functionality from image and image
set I switched to match HTML
TabAtkins: Now that there isn't a need to worry about fallback, I
think nesting is less complex and it's probably not a
bad idea to lift the restriction so you can nest.
plinss: That precludes future fallback solutions.
florian: That looks subtle enough that I'd rather read it and
think about it. You're probably right but I want time to
agree.
plinss: I'm concerned that having the nesting may restrict our
ways of doing fallback in the future.
TabAtkins: I don't believe it will. I think we can add conditions
as part of the fallback mechanism.
plinss: What do you gain?
TabAtkins: You have image set and have...
TabAtkins: Oh. You don't. You don't gain anything. It's a matter
of making it invalid to nest and we're not gaining
anything from having the restriction.
plinss: You're not gaining anything from the functionality.
TabAtkins: No, it's useless to nest. I just want to remove the
unneeded restriction.
hober: I think we can add the limitation later. Authors don't do
it, anyway.
florian: If everyone is cool, I won't stand in the way, but I'd
rather think on it.
plinss: Let's come back to it.
florian: Is there a summary in the spec?
Action TabAtkins to e-mail the list about lifting restrictions on
nesting image set
* trackbot is creating a new ACTION.
<trackbot> Created ACTION-652 - E-mail the list about lifting
restrictions on nesting image set [on Tab Atkins Jr. -
due 2014-10-01].
TabAtkins: So the larger issue is keep image set in the spec; yea
or object?
TabAtkins: We're going to have a few weeks of review.
florian: So the review is time to let me decide.
hober: Yea.
RESOLVED: Have image set in level 3
TabAtkins: So the last item lets you blend images or blend colors.
TabAtkins: It's used in blink/webkit to fill between animations.
The syntax in the spec does differ from the current
implemented syntax because we changed from the prefixed
in order to be extensible to multiple images in the
future.
TabAtkins: In the future level we want crossfade to be able to
blend 3 or more images. So I had to tweek the syntax.
dbaron: Why doesn't crossfade take crossfade as an argument?
TabAtkins: It does. It's messy.
dbaron: It's the natural thing that falls out of transitions. So
you end up with a nested case instead of a three function.
TabAtkins: You might be right.
TabAtkins: I'll give that more thought to see if we want to extend
that. I need to talk to shane because I think there was
something about additive animations.
TabAtkins: So we may revert back.
dbaron: This is also pulling the interpolation rules that depend
on crossfade into images 3.
dbaron: This almost sounds like abandoning images 3 and doing
images 4
TabAtkins: I recall an earlier F2F conversation about what it
would mean to maintain a CR level 3 and WD level 4 and
it would mean that whenever the level 4 items are ready
to advance we would take those features and pull them
into a republication of the lower level CR.
dbaron: That depends on the definition of stable. These aren't
ready to exit CR.
TabAtkins: Yes. But by that criteria Image 3 should be kicked out
of CR as well.
<ChrisL> with zero tests its clear nothing is ready to exit CR
dbaron: I guess I'm okay with it. It probably will mean it's hard
to get it to REC.
TabAtkins: That's possible. I don't think these are the first
things that will drop out.
florian: All this stuff you're adding, can it be marked at risk?
ChrisL: In some ways I'd rather put it in and see if it has
traction. If we want to move and it looks dodgy, we can
change them to at risk
florian: Is there any down side to at risk?
ChrisL: There's a slight one because it's usually a flag saying
we're going to pull this.
TabAtkins: Previously it was to allow its removal to not be a
normative change, but that's not needed anymore.
florian: Okay. So ignore what I said.
plinss: So we can delete the features and go right back to CR.
florian: So with lack of LC do we need at risk?
plinss: Let's not bikeshed the process.
TabAtkins: So put the crossfade function in? There may be tweeks
during review.
TabAtkins: And putting it in for now doesn't mean we can't put it
back into 4 later.
RESOLVED: Move crossfade to level 3 of Images
Sizing of floated ::first-letter
---------------------------------
<florian> http://dev.w3.org/csswg/selectors-3/#application-in-css
florian: In selectors 3 there's some language from CSS 2.1 that
allows something to pick the letter height of the first
letter. That was there because if you do it well you
could make it look better.
florian: Only Firefox is doing this so it's not interoperable. And
we have another value coming in that's better at doing
drop-cap. So I suggest we remove the special casing.
florian: I wrote a few test cases that should show the difference.
<florian> http://florian.rivoal.net/csswg/first-letter-tests/first-letter-001.html
<florian> http://florian.rivoal.net/csswg/first-letter-tests/first-letter-002.html
<florian> http://florian.rivoal.net/csswg/first-letter-tests/first-letter-003.html
<florian> http://florian.rivoal.net/csswg/first-letter-tests/first-letter-001-ref.html
florian: Only Firefox does anything different. I think
gregwhitworth mentioned that there might be subtle
differences elsewhere, but I don't think there's a case
for allowing the difference other than drop-caps
<gregwhitworth> agreed
TabAtkins: I agree. I think initial-letter will do it better.
Rossen: Sounds reasonable.
florian: dbaron?
dbaron: I'd like to see initial-letter be more stable, but I guess
I'm okay.
RESOLVED: Remove special case from ::first-letter
florian: I'll submit the tests.
florian: Do we submit from TTWF or is the old way fine?
plinss: Old way is just fine.
florian: What's preferred?
plinss: Author's preference.
Overriding an important style
-----------------------------
mikesherov: Basically what we have is a situation where
element.style.setProperty doesn't change the important.
To do the way cascade works it doesn't take the
declaration.
mikesherov: There's no way to change from red important to black
in one step. It's not interoperable and it fires two
mutation observers. We tried to fix this in JQuery
which cased a few more bugs.
<ChrisL> Okay, so it is an atomic operation to change value and
importance together.
<mikesherov> http://bugs.jquery.com/ticket/14394
<mikesherov> http://bugs.jquery.com/ticket/14836
mikesherov: Because there isn't interoperability, though webkit,
blink and IE are doing what the spec says, it might
make sense to switch to what Firefox is doing
glazou: I support this.
<mikesherov> https://connect.microsoft.com/IE/feedback/details/831122/assigning-to-the-style-property-initialized-to-an-important-value-isnt-applied
mikesherov: When we filled the bug (above) with Microsoft they
pointed to the spec so I think they'd change it if we
changed the spec and I'm hoping blink/webkit supports
it.
mikesherov: I'm not sure how many authors are relying on the
current behavior.
glazou: I don't think many authors are, but app authors hit it a
lot and hate it.
mikesherov: It's important for something like jQuery to be able to
do this in one step.
ChrisL: It makes sense for this to be an autonomous declaration.
mikesherov: From the mailing list it seemed there was a resolution
last August in the opposite direction. I'm not sure
what the details of that decision were, but I'd like
to see a change.
plinss: Anyone remember or have minutes from that?
dbaron: My memory is someone didn't want to change.
plinss: Are they willing to change now?
TabAtkins: I don't see reason why we'd object.
plinss: So are folks okay with resolving?
hober: I don't know either way. I don't know compatibility risk.
Rossen: Same for us. We need to evaluate the compatibility and see
if we'd need to change.
<zcorpan> I think it's ok compat-wise. Last time I looked at it I
only found scripts expecting the Firefox behavior
mikesherov: I'm new. I don't understand about evaluating the
compatibility risk.
Rossen: We can try to run some queries to see how widely this
pattern is used and once we find that we can see what the
consequences would be for site breakage.
florian: I don't know how you'd search. It's not an easy thing to
parse.
Rossen: I'm not saying it will be. We can try and mine the data. I
don't know how much success we'll have.
mikesherov: Web developers believe that they can set it how they
want to and since it's an inline style they think they
can change it. Again, Firefox does the 'expected'
behavior. I'm not sure how to research.
florian: One thing would be, does Firefox have bugs filed against
it on this issue?
dbaron: I don't think it was an issue.
plinss: Do people want time to research or can we resolve now?
Rossen: I'd like a week.
Action Rossen research changing the overwriting of an important
style
* trackbot is creating a new ACTION.
<trackbot> Created ACTION-653 - Research changing the overwriting
of an important style [on Rossen Atanassov - due 2014-10
-01].
plinss: Thanks everyone.
Received on Wednesday, 24 September 2014 23:52:45 UTC