- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 26 Mar 2015 06:22:20 -0400
- To: www-style@w3.org
TPAC 2015
---------
- Everyone in the group was asked to respond to the e-mail from
Bert regarding TPAC.
Review and Publication Requests
-------------------------------
- There is a two week review period for the Rounded Displays
document.
- RESOLVED: Publish Values and Units as CR
- RESOLVED: Variables to CR
- The proposed cuts to what items are in Lists (available here:
https://lists.w3.org/Archives/Public/www-style/2015Mar/0363.html)
seemed sound, so the editors will make them and request
publication once they're done.
- RESOLVED: Cascade Level 3 publish CR
- RESOLVED: FPWD for Cascade 4
- RESOLVED: Publish CR of will-change
- The box-sizing review period was extended for another week.
Constructable Stylesheets
-------------------------
- RESOLVED: Create an ED for TabAtkins' constructable stylesheets
draft.
- Short name for now is cssom-construct
Intrinsic Sizes for multicol Elements
-------------------------------------
- Defer for a week until dbaron is available.
'Font-rendering' property
-------------------------
- Defer for two weeks to give time for mailing list review and for
TabAtkins to be available on the call.
Media Queries
-------------
- Microsoft requested a week to review the proposal of changing
'should' to 'must' in the following sentence: "User agents
should re-evaluate media queries in response to changes in the
user environment"
Page-Specific Properties Outside of @page Context
-------------------------------------------------
- There were several different viewpoints on this, so discussion
will continue on the mailing list.
===== FULL MINUTES BELOW ======
Present:
Rossen Atanassov
Tab Atkins
Sanja Bonic
Bert Bos
Bo Campbell
Dave Cramer
Alex Critchfield
Elika Etemad
Daniel Glazman
Tony Graham
Dael Jackson
Brian Kardell
Toru Kawakubo
Brad Kemper
Chris Lilley
Simon Pieters
Anton Prowse
Florian Rivoal
Andrey Rybka
Simon Sapin
Alan Stearns
Ian Vollick
Greg Whitworth
Steve Zilles
Regrets:
David Baron
Adenilson Cavalcanti
Tantek Çelik
Simon Fraser
Peter Linss
Michael Miller
Edward O'Connor
Lea Verou
glazou: Let's start.
glazou: Any extra items?
Florian: Maybe a quick one on Media Queries
glazou: Let's try to do that after item 3 or something like that.
glazou: Anything else?
TPAC 2015
=========
glazou: Please take a look at the message from Bert about TPAC
2015. It will happen in Japan.
glazou: We need to pick meeting dates and if we need a big room,
etc. We usually take the first part of the week so let us
know if there's a problem with that.
Review and Publication Requests
===============================
Rounded Displays
----------------
glazou: Let's do the first one from LG. They proposed rounded
displays.
<glazou> https://lists.w3.org/Archives/Public/www-style/2015Mar/0358.html
glazou: The document is under dev.w3.org and they asked us to
review.
Florian: I've been meaning to review.
TabAtkins: Same here.
glazou: I think they did things pretty well. They came with
questions, then a proposal, then a document and an
implementation. I suggest we review the document ASAP.
glazou: For a first contribution it's a big one.
glazou: Let's take two weeks for review. It's not a small doc.
Values and Units
----------------
<glazou> https://lists.w3.org/Archives/Public/www-style/2015Mar/0352.html
glazou: We have a request on Values and Units CR
glazou: fantasai are you there?
fantasai: We finished the custom-ident edits and the changes
section is up to date. We would like to publish as a new
process CR.
glazou: So publish a new CR?
<Bert> +1 to new CR
<Florian> +1 to new CR
<TabAtkins> +1
<SimonSapin> +1. I reviewed the changes, looks good.
ChrisL: There's a DoC or something to indicate adequate review?
<fantasai> http://dev.w3.org/csswg/css-values-3/issues-cr-2013
<fantasai> Disposition of comments ^
<ChrisL> ok great
TabAtkins: Yes, we do have a DoC put together
<Bert> -> http://dev.w3.org/csswg/css-values/issues-cr-2013 DoC
ChrisL: The DoC looks good. +1
<astearns> +1
glazou: Objections?
RESOLVED: Publish Values and Units as CR
glazou: Who will deal with publication?
ChrisL: I can.
glazou: Thank you.
Variables
---------
<glazou> https://lists.w3.org/Archives/Public/www-style/2015Mar/0356.html
glazou: Next is from TabAtkins. A request for another CR for
Variables.
TabAtkins: Its never been CR. I've prepared the DoC so everything
should be good to go.
<bkardell> +1
<astearns> +1
glazou: Objections?
<Bert> +1 to CR
RESOLVED: Variables to CR
glazou: ChrisL will you do that too?
ChrisL: I can. Can I get a link for DoC?
ChrisL: And the changes list if up to date?
<Bert> http://dev.w3.org/csswg/css-variables/issues-lc-20140506.html
TabAtkins: Should be.
Lists
-----
glazou: Next is Lists.
<glazou> https://lists.w3.org/Archives/Public/www-style/2015Mar/0363.html
glazou: That's from fantasai.
<TabAtkins> display: inline-list-item
<TabAtkins> defining list numbering in terms of the implied 'list-
item' counter
<TabAtkins> list-style-image: <image> | none
<TabAtkins> (instead of list-style-image: <url> | none)
<TabAtkins> list-style-type: <counter-style> | <string> | none
<TabAtkins> (instead of list-style-image: <css21-defined-counters>
| none)
<TabAtkins> font/color marker styling by reference to ::marker in
Pseudo Elements L4
<TabAtkins> counter-set property
fantasai: That's not just a publication request. It's a we should
do this and discuss if these are what we should keep.
Then TabAtkins and I will make edits.
Florian: I was generally okay with the proposal. I was wondering
if we want font color styling.
fantasai: That's in pseudo-elements. The ability to style is in
the level 4 draft. We'll include it by reference.
glazou: So we'll revisit this.
glazou: Let's move to the next one.
Florian: Why move on? There's a question to answer.
glazou: Okay. Go ahead.
Florian: So do we try and trim the spec and go to CR?
fantasai: The proposal I have there, which was inline-list-item as
a display type.
fantasai: Let me find the message.
TabAtkins: I pasted it as text above.
fantasai: The proposal is to trim it to the things in 2.1.
fantasai: [Reads what is in IRC above]
<Florian> I agree with the proposal.
fantasai: Those were the things that we stable for the design.
fantasai: Basically there's still going to be details to work out,
but I think no one has concerns on design for these. So
is there anything the WG thinks shouldn't be one this
list? We can then trim to this list or some subset of
this list so we can get something that's stable. That's
why we cut the marker pieces because that's tricky.
Florian: Even for reference, the link to the part of markers is
tricky. We might have to cut that if it gets pulled. I
don't think that will happen, though.
fantasai: It's not going to happen.
<fantasai> Colors and fonts are fairly harmless
Florian: Then I'm good with that bit.
<Florian> To the extend that ::marker continues to exist (which it
probably will), fonts and colors are harmless.
glazou: If that's done, let's move on.
Cascade 3
---------
<glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2015JanMar/0200.html
glazou: Next is Cascade.
fantasai: TabAtkins and I did cleanup. There wasn't much; mostly
editorial. We also decided since we wanted the default
keyword and @import rule we should start a level 4 draft.
<fantasai> http://dev.w3.org/csswg/css-cascade-3/#changes
fantasai: Basically it's trivial changes on level 3 and we'd like
to republish that. We'd like the also do FPWD for 4.
glazou: We'll do level 4 second.
glazou: Your e-mail link was broken for DoC.
fantasai: Add -3 to the url and it works.
glazou: OK
<glazou> http://dev.w3.org/csswg/css-cascade-3/issues-cr-2013
glazou: No objections. Any comments?
Florian: I have a few minor comments, but I agree we should update
the spec. So yes to level 3 and 4.
glazou: One thing at a time. First level 3. Any other comments?
<Florian> the minor comments applied to level 4.
<Bert> (I'm in favor, as I said in mail.)
<ChrisL> +1
glazou: Objections? I only heard 2 okays.
TabAtkins: Okay.
RESOLVED: Cascade Level 3 publish CR
<ChrisL> DoC and changes ok for cascade 3 CR?
Cascade 4
---------
<glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2015JanMar/0207.html
glazou: And then the request to publish level 4 of cascade.
glazou: That's a FPWD request.
Florian: I'm in favor of getting it out. If it's ED or if we get
both at the same time, I don't care.
fantasai: It's very trivial changes. I don't think there's a need
for ED.
Florian: Maybe only if we want to add more things and have them
covered by the legal review. I don't strongly care.
glazou: I have no opinion.
glazou: What do others think?
<ChrisL> seems good to publish it
<bkardell> +1 what Florian said, no strong opinion tho
<TabAtkins> FPWD plz
glazou: No one cares?
RESOLVED: FPWD for Cascade 4
<fantasai> Bert, I just added the missing supports() change to the
Changes list in Cascade 4
<Bert> thanks fantasai
will-change
-----------
<glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2015JanMar/0202.html
glazou: Next is TabAtkins...will-change
TabAtkins: The will-change spec has had no change in the last year.
<TabAtkins> http://dev.w3.org/csswg/css-will-change/issues-20140429-wd.html
TabAtkins: I have two comments. There's a DoC and they're both
addressed, so lets take it to CR.
<ChrisL> any tests?
glazou: How many implementations?
TabAtkins: Chrome and FF. I'm not sure on Safari or IE.
glazou: Any tests?
TabAtkins: I haven't written any tests.
glazou: I'm in favor of publication.
fantasai: I'm in favor
<ChrisL> +1
<Florian> +1
<bkardell> +1
<andreyr> +1 to publish
<sanja> also +1
glazou: Any objections?
RESOLVED: Publish CR of will-change
glazou: There were so many publication requests. Did I miss a
document?
Florian: For publication I don't know, but for review, yes.
glazou: Any other publication requests?
box-sizing
----------
glazou: Okay, review
Florian: The 3 week review for box sizing is over today. I got
feedback only from fantasai some of which I agreed and
included. No one else has replied.
<Florian> https://lists.w3.org/Archives/Public/www-style/2015Feb/0445.html
Florian: The URL is here ^
glazou: What are you going to do? Close the feedback period?
Florian: I need more feedback. This is something we don't want to
break so implementors need to review. It doesn't make
sense to make an unreviewed change when we're not sure if
the change is correct. That's highlighted by the fantasai
comments. There's two parts to this: first is this change
correct and second if it is phrased well.
Florian: Those both need to be addressed, mostly I need to be sure
it's correct.
glazou: We gave three weeks and it wasn't enough. How much more
time should we give?
Florian: I don't think it's a matter of time, it's a matter of
doing it.
glazou: Let's give an extra week?
Florian: I don't have editor rights on the spec anyway.
glazou: Okay, let's do an extra week and action everyone.
Florian: If someone could ping Boris Z. Specifically that would
help since he had this issue.
glazou: I'm not sure if we have anyone from Mozilla...There's
SimonSapin.
Florian: I copied Boris on the mail, but not directly.
glazou: You should send him an e-mail.
Florian: Okay.
<SimonSapin> I can email Boris if it helps
Constructable Stylesheets
==========================
<glazou> https://lists.w3.org/Archives/Public/www-style/2015Mar/0320.html
glazou: This is an old problem of the CSSOM and I thought it was
worth and explanation
<bkardell> It seems like 2 things, I'm interested in both
construction and "issue 3"
TabAtkins: Right now you can't construct a stylesheet directly.
This works generally, but if you want to share one
across several things, you have to duplicate them and
hope you can dedup in the engine.
TabAtkins: That's the basic reason for my proposal so we can share
the same object. There's another bit I'd like to tack
on from the drawbacks of the authors using the deep
combinator.
<bkardell> I think what TabAtkins just said was one problem apple
had with it, right?
TabAtkins: They're using deep as a rule and it's killing
performance. If we could set up some new origin for
stylesheets that might work or if we have more API on
the stylesheet objects. So that's not strictly tied,
but I'd like to discuss that.
TabAtkins: So stylesheet as a constructor, how do we feel about
that?
<bkardell> +1 to stylesheet that is constructable.
TabAtkins: I have two API ideas. One is another stylesheet list
that's author mutable.
TabAtkins: I don't have strong opinions on how you put it on a
document, just that this should be possible.
glazou: Questions?
<astearns> +1
[silence]
glazou: Okay. Thank you TabAtkins
<bkardell> (This would be good to review at the Extensible Web
Summit in April)
TabAtkins: So, within that construct, should I get a publish
agreement for this?
glazou: Do you think you have enough feedback? You should probably
continue aggregating feedback. I'm sure you'll have
questions about the assignment of a stylesheet. So when
you have one constructed stylesheet and you put it on two
docs.
TabAtkins: Yeah. And I'm thinking this will merge into CSSOM.
We'll get further feedback.
fantasai: You could put it in the repo as an editor's draft or
unofficial draft.
TabAtkins: I'm fine with putting it as a unofficial draft in the
repository.
TabAtkins: So objections to me putting this is a repo as a
unofficial draft?
<bkardell> +1
glazou: So objections?
fantasai: If we agree we should work on this, an ED should make
sense.
glazou: I agree on ED. This is an important topic.
glazou: Objections on an ED?
Florian: I'm not close enough to have solutions, but it makes
sense.
RESOLVED: Create an ED for TabAtkins' constructable stylesheets
draft.
glazou: Shortname?
TabAtkins: I'm not happy with mine.
fantasai: cssom-construct?
glazou: That's fine.
<ChrisL> You don't need to finalize on a shortname until FPWD
glazou: That's true ChrisL but if we get ti right the first time
it's simpler.
<ChrisL> True.
Intrinsic Sizes for multicol Elements
=====================================
glazou: Next is intrinsic sizes for multicol elements
fantasai: We should wait for dbaron.
glazou: And the same thing with the next topic?
fantasai: Yeah. Is MS on the call?
Rossen: Yes.
fantasai: If you guys can look those over it would be great.
Rossen: Okay.
'Font-rendering' property
=========================
glazou: I added TabAtkins font-rendering, but jdaggett asked us to
defer that to next week so it can continue on the ML.
TabAtkins: I won't be on the call next week, so we should defer
for two weeks.
glazou: Okay. Two weeks.
Media Queries
=============
<Florian> https://lists.w3.org/Archives/Public/www-style/2015Mar/0469.html
Florian: MQ4 has this statement: "User agents should re-evaluate
media queries in response to changes in the user
environment."
Florian: It's reasonable, but it should be a must. I remember
there might have been a reason for should.
fantasai: I think it was an implementor issue.
Florian: So if we had switched to a must if it would have delayed
MQ3, but that's no longer relevant, so we can switch. The
other plausible reason is so that we can allow a special
class of user agents to layout once and then never update.
If we're interested in that, fine, but then we should
make a specific exception rather than relaxing the
requirement for everyone.
Florian: So can we just do must or make an exception for
render-once-and-forget UAs?
fantasai: They also care about the size of the containing block,
so that would be a whole different thing for them. I
think we can just do a must.
glazou: Everyone agrees?
<andreyr> +1
Rossen: On exactly what?
Florian: The change from should to must.
<Florian> "User agents should re-evaluate media queries in
response to changes in the user environment" should ->
must
Rossen: And what were the original reasons for should? Which
implementations were considered and what were the reasons?
fantasai: I think it was Opera. Some early implementors of MQ in
any case.
fantasai: I don't remember clearly.
<zcorpan> maybe background tabs?
<ChrisL> are there any tests for immediate re-evaluation?
Rossen: What do current implementations do?
fantasai: They update.
Florian: In a vast majority they update. There's a few exceptions
that I believe are bugs. For example I've heard some
browsers that impl hover don't update if you plug in a
mouse. Having it as a must will make it more clearly
wrong.
Rossen: Okay. Any test cases?
Florian: No. I just heard of this today.
Rossen: Okay. I'd push back until we know current state.
<bkardell> why isn't it must already though?
fantasai: You can use...I can put up a test case.
Rossen: So we'll test, observe what implementors do, and discuss
next week.
<fantasai> Testcase for width:
http://csswg.inkedblade.net/staging/redesign/divya/
Florian: I'm unsure what tests you want. If the question is does
every implementation of every MQ do, it's hard to test.
If there's a good reason for not must that's interesting.
But fishing for every bug everywhere, what will the test
tell us?
Rossen: There were certain reasons considered when it was first
agreed as a should. If we're changing to must we should
have a fairly good confidence that those reasons are no
longer valid. I don't know the history, but I want to know
what this means for us and I currently don't.
Rossen: Right now, I won't vote for this.
Florian: If you want an extra week to look on your side, that's
okay. But taking time to go fishing to see if someone is
breaking without a specific reason in mind, that's less
interesting.
Rossen: What do you mean about reason in mind
Florian: If we find someone doesn't, but don't know why, we don't
know if that's a bug.
Rossen: So do we remember why it was a should?
<bkardell> it would help to review the reasons for should initially
<fantasai> http://dev.w3.org/csswg/mediaqueries3/
<ChrisL> presto did not update, I suspect
fantasai: Implementations that don't update. If we look at MQ3
there's no reason not to update unless there's an
implementations that thought it was hard. There's a test
case I pasted above that shows that they all update.
fantasai: You might be able to argue on the newer stuff, but none
of the logic that applies to the item in level 4...
anything in level 3 there's no reason not to update it.
<zcorpan> You might not want to evaluate MQ for background tabs.
glazou: We're at a block here. Microsoft is requesting a week of
review.
Florian: I'm comfortable with a week of review. I don't want to
spend a week checking to see if someone isn't complaint.
Rossen: I didn't suggest that.
glazou: Let's give Microsoft another week. Defer to next week.
<gregwhitworth> tabatkins: how would this affect sizes?
<TabAtkins> gregwhitworth How would what affect sizes? The
sizes='' attribute for respimg?
<zcorpan> gregwhitworth sizes='' gets evaluated as part of "img
environment changed" algorithm, which itself is
currently a "may" (but there's an open bug on making it
more like must, except not for background tabs)
<gregwhitworth> zcorpan: that's what I was curious of, just didn't
want this to force a must, but we'll end up at
some point making it trigger as a must
Nested Fragmentainers and Break Types
=====================================
glazou: Do we want to discuss that now?
fantasai: I'd rather do that on the list. I haven't reviewed all
the issues yet.
Page-Specific Properties Outside of @page Context
=================================================
<glazou> https://lists.w3.org/Archives/Public/www-style/2015Mar/0387.html
<ChrisL> do they get thrown out during parsing if outside @page?
glazou: In the property box we have a line saying this is for
@page, but we didn't say what that means. Is it restricted
to page or do we have the property outside?
TabAtkins: We don't have them outside. They're not valid
descriptors for other rules.
Florian: They're descriptors that behave like other properties.
<SimonSapin> TabAtkins, they are properties
ChrisL: Do they get thrown out during parsing outside an @rule?
TabAtkins: They're not a valid property.
ChrisL: Then they won't show outside OM.
SimonSapin: In same context we accept other properties that aren't
part of rules.
TabAtkins: @page is weird. They have so many descriptors that look
like properties.
Florian: But we can't apply properties in the same spot.
TabAtkins: Just like how @fontface that has descriptors that are
named the same as properties.
TabAtkins: They're a different construct entirely. They're not
interpreted outside.
<ChrisL> it seemed easier at the time to name the descriptors the
same as the corresponding properties
glazou: Can someone post on IRC a link to where this is?
<SimonSapin> http://dev.w3.org/csswg/css-page/#page-properties
6. Page Properties
<SimonSapin> "Appendix A defines the normative list of CSS 2.1
[CSS21] properties that apply to page boxes."
glazou: So paged media 3 we have a block of declarations that's a
list of properties and values.
glazou: It says page properties, not page descriptors.
<ChrisL> daniel seems to be asking that we fix the spec so it says
what we know it means.
Florian: I agree on TabAtkins logic, but I'm not sure the spec is
written properly.
TabAtkins: Sure.
SimonSapin: You gave the example of @fontface, but it defines them
as proxies. For page they have the same meaning and
definitions.
TabAtkins: So if they're the same you can defer to the same...
glazou: They're not closely related. The first are about a font
selection mechanism, but this isn't a page selection
mechanism.
<SimonSapin> http://dev.w3.org/csswg/css2/page.html#page-margins
In CSS 2.1, only the margin properties ('margin-top',
'margin-right', 'margin-bottom', 'margin-left', and
'margin') apply within the page context.
<Bert> (@page is a kind of box, @font-face is not, so you expect
different things for its properties/descriptors./)
fantasai: SimonSapin is right, they're property and apply to
boxes, that it's using @rule syntax is odd for
historical reasons. It probably should have been a
pseudo element and that's how it works for the most part.
fantasai: I think that @page is a ::page and everything behaves
like that. But it was originally designed as an @rule so
there will be funniness. But there are properties that
only apply to @page and make no sense outside the
context.
fantasai: I think it would be more simple if they're thrown out
instead of hanging out in the OM.
TabAtkins: That would be new. Properties are properties and they
can hang out. So it's either a property or a descriptor.
TabAtkins: And charting a new ground to keep them from linking,
let's just call them descriptors.
fantasai: Because they're properties and inherit and cascade.
Florian: And will this be influenced by the new ability to nest?
TabAtkins: If we redefine the styling, they will be pseudo
elements.
Florian: But @page can reasonably apply to anything.
TabAtkins: I don't think we can do it syntactically.
fantasai: We have the property for the syntax to style those thing.
If you drop the second half of the selector that comes
after the page.
* BradK agrees with Elika generally, but the 'size' property
should be like 'content' outside of a pseudo-element.
glazou: I think we're diverging. So should a property like size be
exposed outside...
fantasai: I think it should be no, it should not show up. But you
can check for support in the @support.
glazou: I'm not sure about your two proposals because some
implementors may depend the second on the first. So if
it's parse-able in the first case, it's parse-able when
implemented so I'm not sure you can't relate the two of
them.
TabAtkins: I agree. It would be new syntactic way of doing an
@rule.
Florian: I think we need to say @page is a pseudo element that's
just odd so that it is treated like a pseudo.
glazou: It behaves like a pseudo element.
SimonSapin: It also inherits from the root element.
glazou: It's like properties.
TabAtkins: Inheritance is in counter styles. It's not just
something only properties can have.
fantasai: We inherit between elements too.
glazou: So there's two positions here. I suggest you contribute
your views to the thread on www-style. We'll revisit when
there's consensus on the ML.
glazou: But it's an issue we have to solve.
glazou: That's the hour. Thank you very much and talk to you next
week.
Received on Thursday, 26 March 2015 10:22:51 UTC