- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 4 Mar 2015 20:41:02 -0500
- To: www-style@w3.org
CSS Grid Publication
--------------------
- RESOLVED: Publish a new working draft of CSS Grid.
Animations Editorship
---------------------
- RESOLVED: TabAtkins and dbaron are co-editors for Animations.
Abspos Change Compat Risk
-------------------------
- RESOLVED: Do not change the current spec for now knowing the
compat risk with the change in abspos handling.
CSS3 UI
-------
- RESOLVED: Publish a new WD for CSS3 UI.
- Everyone, especially implementors, were actioned to review
Florian's proposal (available here:
https://lists.w3.org/Archives/Public/www-style/2015Feb/0445.html)
for a more precise description of how box-sizing works. There
will be three weeks to review the proposal before the issue is
revisited.
Reverting vertical % padding/margin to match block
--------------------------------------------------
- The argument for reverting was for consistency in the odd things
about CSS so people only have to learn a weird rule, not a
weird rule and its exceptions.
- The argument against reverting was to allow grid and flexbox to
work in a way that was more intuitive to app developers that
are relying on these tools.
- A compromise was raised to create a switch, such as creating ph
and pw, so that authors can choose their behavior of choice
instead of forcing one group or the other to think outside
their desired approach. This idea met with favor.
- The implementors will hold a conversation to find out more about
who is willing to implement what while discussion continues on
the mailing list to further flesh out people's opinions and
proposals.
Behavior of Selectors not in Fast Profile
-----------------------------------------
- RESOLVED: We keep selectors not in the fast profile and not
implemented as invalid and we clarify it in the spec.
===== FULL MINUTES BELOW ======
Present:
Rosssen Atanassov
David Baron
Sanja Bonic
Bert Bos
Adenilson Cavalcanti
Tantek Çelik
Dave Cramer
Alex Critchfield
Elika Etemad
Simon Fraser
Daniel Glazman
Tony Graham
Koji Ishii
Dael Jackson
Brian Kardell
Brad Kemper
Chris Lilley
Peter Linss
Mike Miller
Edward O'Connor
Anton Prowse
Florian Rivoal
Andrey Rybka
Simon Sapin
Alan Stearns
Lea Verou
Steve Zilles
Regrets:
Tab Atkins
Bo Campbell
Sylvain Galineau
Simon Pieters
Greg Whitworth
Scribe: dael
glazou: I suppose we have to start
glazou: Any additions?
Florian: Tantek and I just just mentioned two. One is a new WD for
CSS3 UI, another is a request to review an e-mail.
glazou: We can do the first first, the second after item 3.
Florian: We should wait for tantek to be on the call for both. I
think he'll join soonish.
glazou: Okay. Anything else?
CSS Grid Publication
--------------------
<glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2015JanMar/0162.html
<astearns> (the member-only link above mainly just links to
https://lists.w3.org/Archives/Public/www-style/2015Jan/0168.html
and http://dev.w3.org/csswg/css-grid/#changes )
fantasai: TabAtkins and I put in pretty much everything we
resolved on, so we thought we should publish a new WD to
get it up to date. The current draft is up to date with
the issues filed to mid-January.
fantasai: It's a major improvement, so I think the TR should get
up to date. Most of the other comments since our update
were editorial.
glazou: I'm in favor. Thank you for maintaining an up to date list
of changes.
Rossen: Sure.
<SimonSapin> +1
<Florian> +1
glazou: Other comments?
RESOLVED: Publish a new working draft of CSS Grid.
glazou: fantasai you'll deal with it?
glazou: The publication stuff?
fantasai: I don't know when/how with the new system.
glazou: ping Bert.
* Bert hasn't done the new system yet either, but we'll find out
how it works :-)
<tantek> Bert new system requires hotpatching after bikeshed.
glazou: Is tantek on yet?
* tantek is running bikeshed
Animations Editorship
---------------------
<glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2015JanMar/0165.html
glazou: This is a request from sylvaing saying we should have
another editor for the spec.
Florian: And the other should be TabAtkins?
glazou: That TabAtkins would be put on and dbaron would help.
Correct?
glazou: I guess TabAtkins is okay with it. dbaron?
dbaron: It's fine with me.
Rossen: What was the motivation for this?
glazou: I have no idea.
dbaron: I think sylvaing doesn't have time to work on it.
Rossen: So he wants help and is looking for someone to take over.
glazou: One question. dbaron you're available to help? As
co-editor?
dbaron: I'm already co-editor. I've been focusing on other things.
glazou: So any objections?
RESOLVED: TabAtkins and dbaron are co-editors for Animations
glazou: Still no tantek?
Abspos Change Compat Risk
-------------------------
<glazou> https://lists.w3.org/Archives/Public/www-style/2015Feb/0411.html
glazou: We wanted to revisit this after a week, but gregwhitworth
isn't on. Rossen, can you speak on this?
Rossen: I'm here, but I don't think this was an ask for us.
glazou: Okay.
fantasai: I think this was an "FYI there could be problems". No
one has yet said there is a problem significant enough
to revert.
Rossen: If this is rehashing...We're fine with the change and
agree this is the way to go about it. We did see some
compat issues. We raised awareness with the group.
TabAtkins said they were aware and fine with it. We wanted
to circle back to the group and make sure everyone is
fully aware of the compat risk.
Rossen: I don't think there's anyone waiting on us. I think it was
more raising awareness.
Rossen: If we have no problems, let's resolve and continue on.
glazou: There's apparently no comments.
Rossen: So can we resolve to not change the current spec knowing
the compat risk?
* dbaron tries to figure out what this change is
<fantasai> dbaron, it's the change from "abspos static position is
where the placeholder would be if it were a zero-sized
flex item" to "static position is as if the abspos were
the only item in the box"
glazou: Objections?
glazou: dbaron has a question.
dbaron: Not really.
glazou: So no objections?
fantasai: It's not an issue, just a warning
RESOLVED: Do not change the current spec for now knowing the
compat risk.
glazou: tantek you're here?
<tantek> glazou - have had trouble with my comms - trying dialing.
Behavior of MouseEvent.offsetX/Y
--------------------------------
<glazou> https://lists.w3.org/Archives/Public/www-style/2015Feb/0506.html
glazou: This was raised by Robert O'Callahan. It was under
specified. There was a short discussion on the mailing
list, but didn't seem to resolve. I thought we would have
to discuss.
glazou: Unfortunately, zcorpan sent regrets.
glazou: Is this something to discuss now? Do we wait to have
zcorpan? Have some time to review? Whatever?
glazou: No reactions?
Rossen: Let's do it next week.
glazou: Let's defer.
CSS3 UI Publication
-------------------
glazou: tantek are you connected?
tantek: Let's see. Can you hear me?
tantek: I've done all the edits for open issues except the
remaining big issue where Florian has done a lot of work.
I think we should publish as is and then take the time to
review issue 69 because those issues effect some
fundamental things and it's important to get correct.
glazou: The last WD is one week old, right?
tantek: It'll take a week to publish because we've had problems
with new system.
Florian: Last WD is a week old, but we've been trying to get that
out for a month so there's lots of changes.
tantek: Almost 2 months.
Florian: There are a bunch of differences and the new one is
better.
fantasai: I'm in favor of publishing often. No problem with
publishing another draft.
glazou: Other comments?
<astearns> +1 to publishing more often
<SimonSapin> publish early, publish often
glazou: No objections?
RESOLVED: Publish a new WD for CSS3 UI
<Florian> https://lists.w3.org/Archives/Public/www-style/2015Feb/0445.html
tantek: The issue is the box-sizing fixes. This is a thing that
took a lot of time during FX portion of the F2F. This
deserves a lot of review for anyone involved in layout.
Florian has done a lot of work, so please look at his
proposal. We're touching a lot of stuff that's hard to
touch without breaking.
Florian: The spec changes are about disambiguating what height
refers to when it's something else than content box. I
believe there isn't anything particularly hard, but
they're tedious and if something is wrong it'll be bad. I
made a bunch of tests and they conform to what I expect
in most browsers, but there appears to be a few bugs.
Florian: Review would be very appreciated. The prose is dry, but I
was aiming for correct.
* dbaron also submitted some new css 2.1 tests to cover the
Firefox min-width/height bug that we were discussing
<dbaron> (which is now fixed in nightly)
<dbaron> https://hg.csswg.org/test/file/eeefc17e6d6c/vendor-imports/mozilla/mozilla-central-reftests/css21/replaced-sizing/
Rossen: Where are the test cases?
Florian: I just pasted in IRC the e-mail with the tests.
glazou: How much time do people need for review?
tantek: Longer than a week. We have box-sizing where there was
interop problems with previous versions. I would suggest 3
weeks.
Rossen: I'd second. Box-sizing is widely used.
tantek: I'm okay with longer. 3 week minimum.
Florian: I'm not suggesting drastic changes. It's mostly
clarification. For example, the things in the F2F where
one browser seems to be buggy and there was no test to
clarify, I'm clarifying. This isn't breaking existing
compat.
Rossen: So drastic or not, little changes can take down a product.
It's about how widely a feature is used. I'm agreeing with
tantek this should be taken seriously. It's in many, many
libraries.
Florian: I agree with that.
glazou: Rossen, you're OK with 3 weeks?
ACTION everyone to review this for three week timeline
tantek: I'd like to explicitly hear from the implementors with a
thumbs up or down.
tantek: We'll be reviewing at Mozilla as well.
Rossen: I was going to ask if you have reviewed, but it sounds
like you haven't.
tantek: I need to review with other engineers, especially Boris.
I'm optimistic, but I want to make an explicit call for
implementors.
Florian: Yeah. We don't want to get this wrong.
glazou: So we'll revisit in 3 weeks.
Reverting vertical % padding/margin to match block
--------------------------------------------------
<glazou> https://lists.w3.org/Archives/Public/www-style/2015Feb/0521.html
glazou: Next item is from TabAtkins but he's not here.
fantasai: I can take it. We changed to have % reference the height
instead of width, in block layout we did in both
directions. This gets you equal padding.
fantasai: For things like flexbox and grid we went with you get %
in dimension you referred to. This change to flexbox
from initial CR we did because we realized Microsoft had
this with grid.
fantasai: We wanted to make grid and flexbox consistent so we
decided to backport the behavior. It's more intuitive
for app layouts where you have a fixed height. For
document mode you usually have auto height and the %
resolved to 0.
fantasai: Microsoft and Firefox have implemented this behavior.
Chrome hasn't. Chrome developers have said it's a
performance concern because they have to do a virtual
function call every time. They don't think it's
important and authors prefer our behavior. That's where
we're at.
fantasai: dholbert found some bugs recorded against FF and these
are mainly for cases where there is an auto height. So
we have to talk to the Chrome dev to find the exact
holdup. For the authors having these % go to 0 with auto
height isn't useful.
fantasai: We were thinking of changing auto referencing behavior
to refer to containing block. That's for us to think
about. The editors for Microsoft and Blink and Webkit
will need to talk about Blink architecture.
fantasai: We'll talk to implementors. For the WG to discuss, what
are our thoughts to defining as it's relative to the
height if the height is definite. Relative to the width
if it's not?
Rossen: I'll repeat myself. How we arrived where we are with grid.
I agree with what you said, but it puts bias toward the
document flow behavior which is resolve % out of
containing space on width.
Rossen: How we arrived there for grid was driven by that grid and
flex are layout for apps more than anything. Traditional
app dev coming from other platforms are expecting symmetry
in their layout for properties that are constraining and
handling horizontal properties and the same for vertical.
Rossen: When grid came along that was the feedback. People were
surprised that padding/margin was resolving from width.
There was strong pushback. That's how grid came about.
Rossen: The same thing will be true for any implementor, anyone
that comes with implementation experience starting from
grid will be on the same page as us since having symmetry
with grid is a lot more useful than flex.
Rossen: My fear is even if we added some relaxation in flex spec
we'll be having the discussion in another year when
everyone is working on grid.
Rossen: That's what I wanted to say before we decide.
fantasai: We have 3 options.
<fantasai> A) Keep vertical percentages against height
<fantasai> B) Revert vertical percentages to be against width
<fantasai> C) Keep vertical percentages against height, except
when it's auto, make it against width
<astearns> is anyone asking for C?
<dholbert> astearns, we have objections to A and B; C is a
compromise
* fantasai is suggesting it as a way of getting useful behavior
for auto-height cases
* fantasai currently they fold to zero
hober: Given those 3 options, I prefer B to have it against width.
This is a weird thing about CSS, but consistent weird you
only learn once.
hober: If we make it different in flexbox the weird is weirder. C
is the worst because you can't predict when the weird
applies.
hober: I think the status quo is weird, but it's simple and weird.
Rossen: When you're in the prospective of app layout it doesn't
make sense. It's the exact other way around from document
developers. We're pushing web to be app as well as
document, so stepping backwards and pretending everything
is a doc is a step in the wrong direction.
Rossen: I sympathize, but I think this is the wrong way going
forward.
<dbaron> I agree that (C) is probably too weird
Rossen: There's an option D which will be potentially something to
explore. It would be some kind of box sizing that would
control how margins are resolved inside a container. For
impl that would be more work.
Rossen: It would be something we can make everyone happy with and
also give doc dev to use doc layout and app dev to make
app layout.
Rossen: I wouldn't be excited about it, but I would lean there.
fantasai: I would do it with new units: pw + ph.
<dbaron> we could have pw for percentage-of-the-width, ph for
percentage-of-the-height, and px for percentage-of-the-
same-axis :-P
<dholbert> so the point of adding a switch would be to enable us
to do "A" (making vertical % resolve against vertical
size), while still allowing authors to ask for the
other behavior (e.g. for aspect-ratio hacks), yes?
Rossen: Either way...having the switch somehow, somewhere. The
switch is better because you want the units to be the same.
Dialing down to the unit means you're statically assuming
where the content would fall and if this is a component
model you can control from the root level.
hober: I don't think I buy the distinction between the two types
of authors and we'd do a disservice by making it harder to
learn.
dbaron: I think I do buy the distinction. doc layout systems are
set up differently: they assume width as an input and
height as an output.
hober: I don't hate the ph and pw unit to distinguish.
hober: I thought that was a good idea, fantasai.
Rossen: This comes down to, the way the Blink team came to the
issue, they were firm in saying they won't implement. You
guys ship, there will be two implementations conforming so
you can get to REC, but Blink won't implement. ph and pw
would also be moot if blink will take that tone.
<dbaron> It's not clear to me that their objection applies to ph
and pw, since the issue sounded like it was related to
*switching* behavior
<dholbert> dbaron, (I think part of their objection is that
"authors want the old behavior at least as much as they
want the new behavior". pw/ph (or equivalent) would let
them switch to the new behavior, while still letting
authors ask for the old behavior)
Rossen: I propose we wrap now and talk with TabAtkins or we wait
until impl get together and discuss why this is difficult
for Blink and then we review.
glazou: I suggest both. We revisit with TabAtkins and we rely on
the mailing list to have implementors discuss.
Rossen: And I believe there will be a one-off call between
implementors too.
glazou: I think we have to defer item #6.
Behavior of Selectors not in Fast Profile
-----------------------------------------
<glazou> https://lists.w3.org/Archives/Public/www-style/2015Mar/0015.html
glazou: This popped up several times and we need to fix or clarify.
bkardell: I think this is the first time we have something that
could not parse and still be valid?
dbaron: I would assume they don't parse.
bkardell: But if you do support in fast profile...don't they share
a parser?
fantasai: It could, but you shouldn't parse things you don't
support. If you support in one context and not another,
you parse where you support.
SimonSapin: Even if we do have parsing code, we can still reject
at parse time.
<SimonSapin> ...in some contexts.
BradK: What's the advantage of throwing away the whole rule?
SimonSapin: We could make it parse, but never match.
dbaron: In general if a selector isn't supported it's like a
syntax error so authors only have one model of not
supported.
dbaron: It's not the best form of fallback, but it allows some.
<tantek> dbaron +1
bradk: But if the media on the style sheet you might want to pull
out both. [?]
<bkardell> I'm mostly interested in this question in how/whether
it applies to the houdini parser effort... would it be
entirely outside that, or would that cause issue?
smfr: I think the suggestion was selectors on the slow profile
should be allowed to match while printing. They might have
enough that they want them to match in terms of visual media.
SimonSapin: If implementations are fast enough, maybe you should
move things into the fast profile?
smfr: Are UA allowed to decide for themselves what's in the fast
profile?
SimonSapin: That's a good question.
<leaverou> Yes please. These selectors are sorely needed in
publishing and the consistency argument against
allowing them in print is very weak.
Florian: I don't think that's a good idea. Having people catch up
is fine, but having people say they will and others say
they won't isn't helpful. So the fast profile shouldn't
be UA specific.
bkardell: Did someone address whether print stylesheets should
support fast profile?
* BradK had assumed that print was part of the slow profile in the
same UA.
<bkardell> bradk, that's what I'm asking - is that specified? I
don't think it is.
Florian: We have a blurring difference. There's print, web and in
between. Once you throw the print at an epub there's an
expectation it'll work the same. When the computing
difficulties do apply to on screen print equivalent
rather than fully developed websites. It's a continuum.
glazou: You mean tweaking the doc from inside the doc? That
depends on the rendering engine for the reader. Some use
browsers to render and that's yes, some are proprietary,
then no.
SimonSapin: Does EPUB support dynamic DOM updates?
glazou: In some implementations, not all.
<ChrisL> @media{fast}
Bert: It's not currently defined which UA does fast, is there a
way for the stylesheet author to find out which is used,
probably by a MQ?
smfr: I think that needs to be a question about a specific
selector. I hope we can over time move selectors into the
fast profile. It seems that should be the long term goal:
everything is in the fast profile.
glazou: Profiles here are the burden here more than anything else.
smfr: Yeah. Can someone explain where they are from?
glazou: Concerns about selectors especially in level 4 and the
ability to batch process.
<tantek> especially interactive user agents vs. batch user agents
bkardell: I wanted to offer that I think the idea is there are
certain selectors that aren't a problem as a one off in
JS, but during initial load that's a lot of evaluation
going on and they would prevent your ability to reason
about selectors as traditionally done.
bkardell: Doesn't flexbox and grid have this problem too?
bkardell: The problem grid has is a mutation can make the whole
thing re-evaluate.
<BradK> Ebooks would be considered interactive, right?
<glazou> BradK: not always
<glazou> BradK: you can print ebooks
<BradK> Or would the ebooks UA get to decide?
<glazou> using a batch
<BradK> Maybe some ebooks do batch processing when the book is
opened, and then doesn't allow JS or mutations or content
editable.
glazou: I think we need to revisit this section. I understand the
original rationale but I understand why some implementors
have concerns about some selectors. Our discussion today
shows the unity needs to remain a value for us.
glazou: If something is so risky for an interactive environment
that browser vendors won't implement, may it is going to
be a problem anyway. Batch processor won't use it. It
wouldn't be main stream.
Florian: The slow profile isn't meant for batch processors. It's
only for JS. I'd be against it in batch processors
because I don't want to have normative 'use' and
normative 'must not use'. If we can get things into UA
I'd be happy with it being off the slow profile.
fantasai: We had this exact discussion in the past and we changed
it so batch are not allowed.
Florian: As long as we have to have the slow profile, it's
important to do it this way. If we can do away with it,
even better.
glazou: It seems we won't resolve this now. If we leave that
section in the doc untouched, we'll need to resolve this.
We'll need to provide an answer to this question. We don't
have a solution, but this should stay on the radar.
glazou: What do we do about selectors not in the fast profile, not
implemented by the given implementation.
glazou: What do they do if they encounter such a selector in a
style sheet.
fantasai: Throw it as invalid. It's not supported by the CSS UA.
It may be by the JS UA, but that's a different UA.
SimonSapin: I agree threating as invalid is the only thing that
makes sense.
??: Yeah.
<bkardell> fantasai, at a minimum, I just think that needs to be
made clear in the spec about why that makes sense
<fantasai> bkardell: yes, Tab and I accept to clarify this in the
spec
* dbaron agrees that treating unsupported things as invalid, as
always, is the only thing that makes sense
glazou: Do we have consensus?
Rossen: What would be the summary of the resolution?
glazou: Selectors not in the fast profile not implemented are
invalid and rejected at parse time.
fantasai: Yeah, exactly. That's what is in the spec in the
conformance section. We can make it more explicit.
<bkardell> any fast profile moving into the slow would be done
behind a flag presumably?
smfr: I have an issue with it. I think it prevents UA from moving
things into the fast profile when they have a good
implementation
SimonSapin: When they do, they can discuss with us.
smfr: The browser would still have to wait for the spec to be
updated. I think UA should be able to improve by just making
things faster. I'd prefer a solution where UA can decide if
it's fast or slow.
fantasai: I think it's easier for browsers to do that. One browser
decides to do that and the others have to decide to take
it up. The goal is to have interop. The pushback is
implementors saying this will be crappy and we can't do
this for performance.
Rossen: Is the current profile in the spec supposed to be the
subset of all interoperable features so you have something
able to spearhead in one impl, it doesn't go in the spec
until everyone catches up?
fantasai: I think the problem is for a batch processor they can
just do this now and it's easy. We have a block from the
dynamic impl where they can't do that. If we didn't have
this dichotomy, we could do it. So we're putting an
artificial block on batch processors to make CSS
portable.
smfr: But people in JS are still able to call selectors and make
it slow.
dbaron: What makes the selector slow is what needs to be done to
handle a dynamic change. If you do a DOM mutation here,
where do you need to reevaluate and can you reasonably
track that.
smfr: And you're saying that means it's okay to call these from
JS, but using them in a style sheet is wrong.
dbaron: It won't be fast, but it's an entirely separate problem.
BradK: The parsing isn't slow, right?
dbaron: But that would treat it differently than everything else
that doesn't work.
fantasai: We do that for a good reason. It lets authors write
fallback and lets them plan better.
glazou: We're far past the hour. The only objection is from smfr.
smfr, given what dbaron said, do you accept the resolution?
smfr: I can live with it?
RESOLVED: We keep selectors not in the fast profile and not
implemented as invalid and we clarify it in the spec.
glazou: That's it for today. Sorry about the extra 5 minutes. Talk
to you next week.
Received on Thursday, 5 March 2015 01:41:30 UTC