- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 23 Jul 2015 07:51:14 -0400
- To: www-style@w3.org
CSS Cascade 4 Publication
--------------------------
- RESOLVED: Publish new WD for CSS Cascade Level 4
Selectors 4 Update
------------------
- The group discussed a the e-mail from fantasai regarding what
portions of Selectors 4 should be deferred or discussed as
Selectors 4 is prepared to move to CR
- The entire group received an action to read and respond to
the entire e-mail
- Most of the conversation centered around :has()
- There is some disagreement about how :has() should work and
there are no implementations to date and therefore it was
suggested that :has() shouldn't be in CR.
- It was agreed to put it at-risk for now with a note
indicating what the disagreement is.
- There was a feeling that :has() has been discussed so many
times and that developers want has so much that just
deferring it to the next level would reflect poorly on the
group.
- It was expressed that if :has() is dropped or deferred
the group needed to publicly post an explanation in
order to help the community that is so excited to
understand the process of the decision.
- In the meantime, several people will post and talk about
:has()'s at-risk status in order to encourage the
community to push for implementation if they really
care about having it.
- The draft still needs an updated WD publication, but fantasai
expressed that she needed more time to do a through review of
the spec.
- There is a hope that the publication will be ready for
voting next week.
CSS 2015 prose and prefixing policy
-----------------------------------
- There was a desire to have more time to read the small details
of the proposed text before any resolutions.
- Some browser vendors expressed concern about the language aimed
at limiting prefixing was imprecise and perhaps too harsh,
though no one was disagreeing about trying to limit prefixing.
- RESOLVED: add Florian as an editor to the snapshot
- RESOLVED: add TabAtkins as an editor to the snapshot
CSS Break
---------
- fantasai's proposal to drop cloned margins at any break seemed
to be right to everyone, but the topic will wait a week for
people to review the exact wording and look at examples.
user-select: none
-----------------
- RESOLVED: user-select: none is a useful feature and we won't
drop it.
===== Full Minutes Below ======
Present:
Tab Atkins
David Baron
Bert Bos
Adenilson Cavalcanti
Tantek Çelik
Dave Cramer
Alex Critchfield
Simon Fraser
Daniel Glazman
Tony Graham
Koji Ishii
Dael Jackson
Brian Kardell
Brad Kemper
Philippe Le Hégaret
Michael Miller
Shinyu Murakami
Edward O'Connor
Anton Prowse
Florian Rivoal
Simon Sapin
Alan Stearns
Regrets:
Rossen Atanassov
Sanja Bonic
Chris Lilley
Peter Linss
Hyojin Song
Lea Verou
Scribe: dael
glazou: Let's start
glazou: We have a few additions to the agenda. There was a message
from fantasai, I think a few hours ago, clarifying the two
additions.
glazou: We're adding CSS cascade and selectors 4 to the agenda.
glazou: She'd also like to remove one item that's answered and one
that's F2F. Anything else?
Florian: Just a clarification, the two items that are if I sent a
mail, I haven't.
CSS Cascade 4 Publication
--------------------------
<glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2015JulSep/0035.html
fantasai: We had one outstanding issue on level 4 which was to
rename default, we picked revert. I'm proposing a new WD
and treat it as a LC. There's no more issues and only 2
additions from level 3. revert and support syntax for
@import.
fantasai: If there's no comments between publication and the F2F
we can go to CR.
<glazou> +1 for a new WD
<plh> +1 for new WD
<bkardell> +1
<Florian> +1
glazou: I'm in favor. comments?
<astearns> +1
plh: Question from me. Oh, wait. Mine is for selectors.
* plh :)
glazou: Other comments?
glazou: Objections?
RESOLVED: Publish new WD for CSS Cascade Level 4
Selectors 4 Update
------------------
<glazou> https://lists.w3.org/Archives/Public/www-style/2015Jul/0296.html
glazou: plh sent a message about a new WD for selectors 4 because
the one of TR is large and the time is too long.
glazou: fantasai posted a proposal for features to keep and to
defer/drop
glazou: There was a proposal about deferring :has() to level 5
that had a lot of conversation on the mailing list.
* bkardell wonders if glazou will recount the thrust of his
comments on thread?
<glazou> bkardell: I could, yes
plh: I said that because the DOM spec was linked to Selectors 4. I
was also wondering about the stability of the path.
plh: For the purpose of defining query-selector and query-selector
all how to deal with scoped elements we don't use a :scope
selector, but we do talk about scope selection so I was
wondering if those parts are stable or nowhere near stable
and will move to 5 for example.
fantasai: Is there anything specific you needed to keep that
wasn't on my list?
plh: We didn't talk about the parsing of selectors. Is that kept?
fantasai: Yes. All the other stuff will be kept. We'll keep
everything that wasn't on the defer list.
plh: And the scoped selector?
fantasai: Absolutely.
glazou: For the people that missed it on the mailing list, I would
like to repeat what I said about :has()
glazou: The proposal from fantasai is to defer to level 5. The
proposal for this feature is >15 years old. We've put it
in documents several times and we've been advertising it
for years and we've been so vocal that web authors are
demanding it. Deferring now would give a bad picture of
the working group.
<gregwhitworth> I haven't been here for 15 years, can someone
summarize why its sat for 15 years?
glazou: It's a question of the image of this WG. In the past we
had a bad image because we couldn't deliver. I'm afraid
deferring :has() will give us that image. We have to
deliver or say we can't and drop it.
TabAtkins: It's not any different status than yesterday. We're
dropping out the parts that aren't stable so we can
push to CR. We're not doing anything different with
:has() than we were doing yesterday.
glazou: To answer gregwhitworth's question, its been on and off
for 15 years because [missed] It was at risk and then
people proposed again and its just been a cycle.
gregwhitworth: So it's not implementation complexity?
glazou: No, the initial refusal was implementation complexity.
That's why I'm saying in the ML that the current argument
to refuse it is the same as 15 years ago and if we can't
implement we have to drop it. It's not fair to let web
authors expect this if we can't do it.
<dbaron> This is what happens when the reaction to "not sure if we
can implement it" is "well, let's put it in the spec and
see what happens".
<glazou> dbaron: absolutely
<tantek> I thought it was "let's put it in the spec for broader
review / feedback"
bkardell: Two things. First is going into a little bit more of the
history of this. To do it in CSS as originally proposed-
it's really difficult. We have ideas, but they will take
a long time. Conceptually it's plain as day you want
that feature. But it is really hard and that's what kept
it out. In the meantime we've come up with qsa and
variants that let you do this in JS.
bkardell: Query has had :has() and people have been clamoring for
it more. Because it's conceptually obvious that people
want this, this has been a long running thing. Any time
it's mentioned people get excited. Doing it in the
static profile isn't very complex. It's a couple of days
work by an impl.
bkardell: That was hard fight to get that far. My second point: I
feel like it sends bad messages to authors. Dropping, I
mean, deferring it seems to send subtle signals. If it's
in level 5 people think it's not as important.
<tantek> just mark it at risk and let's move on
TabAtkins: It can't be in the CR because it's not stable. It's
either dropped or in level 5.
<tantek> how is it not well defined?!?
<tantek> what are the open issues on :has() ?
fantasai: We're going to CR. That doesn't mean every feature has
to be completely implemented. If everyone says they will
implement and don't expect issues, we can keep it in the
draft.
fantasai: What concerns me more about :has(), there have been
discussions about having different syntax from query or
something like that. As long as that's not resolved the
feature isn't stable. If the discussion about what we're
going to do isn't final we have a consistency problem.
fantasai: I would like for us to work through the issues before
:has() is in CR. If we want to leave it for now and drop
it if we can't work through the issues before everything
else is done that's fine.
fantasai: :has() hasn't existed in a CSS draft before it was in
JQuery
glazou: I proposed on the ML to keep working on :has() until the
Aug F2F and make a decision at that time.
fantasai: That's possible, but it depends on the rate of
discussion on the ML.
fantasai: The other features in the draft that we want to keep, if
we remove everything else that's unstable, publish with
:has() and then work on all the open issues, as it
happens we can discuss has and we can decide to drop at
CR transition. We can leave a note saying that if the
issues aren't resolved we'll drop at CR transition.
fantasai: There is still some refining for the rest of the draft
anyways.
<bkardell> +1 to that plan
glazou: I prefer that plan, I think.
<tantek> I am for keeping more features in CR and labeling them
at-risk, especially if *anyone* has expressed
implementation interest.
Florian: Agreeing with something fantasai said earlier, as to if
something without implementation can go to CR depends on
the issues. In the list of things to defer to level 5 I
think there are things to keep. :focus-within has a
reasonable chance of implementation soon and it's
straight forward enough to keep at-risk. I think there
are more things like :read-only. I don't think we'll
change and we might implement soon.
<tantek> Thus I support Florian's proposal to keep :focus-within,
and general criteria.
Florian: That's the criteria I'd apply here.
plh: +1 to what Florian said. We can keep it at-risk and push to
CR sooner because we can still drop.
<tantek> putting things into CR is a way to iron out issues too -
because some issues are only ironed out when
implementations try to build it!
fantasai: A lot of the things on this list were because they had
open issues or we're not sure because we didn't have
enough feedback to know if the issues had a chance to be
ironed out.
fantasai: If people have thoughts on any individual thing I'd like
them to reply and talk about it.
<bkardell> the static profile is actually a compromise between the
two (authors and vendors)
ACTION everyone to review this document and make comments.
glazou: Both bkardell and I made a comment about the image of the
WG. If we do decide to drop :has() I'd like to work with
plh to craft a blog as to why we decided to drop it.
plh: Sure, I agree with you. I wasn't a part of the debate before,
but one of the comments W3C hears a lot is that we're not
listening to devs enough. Devs want :has() and we're not
getting implementations of this. I don't know why there's
such discrepancy.
tantek: So that's why we should not drop :has() from CR. Since
there is high demand the right answer is don't politically
drop it, leave it in CR at-risk and put up a proactive
blog post saying that it's at-risk because there's 0
implementations and if you want this feature you need to
go rally your favorite browser and push the community to
push the implementors and that the WG is a conduit to the
communication. If the community cares they can rally for
it.
tantek: Then the browser vendors prioritize and it's hard or they
don't prioritize and explain why.
<bkardell> +1 to tantek's comment
<bkardell> well said
<Florian> +1 to tantek, IF we are sure that it is specified the
way we want it
<glazou> +1 too
fantasai: I'd 100% agree with you if the reason not to include it
in CR is implementation issues. The reason I'd drop if
we were going to CR tomorrow, it's that there are issues
as to if the impl even want to go in that direction.
It's not like we have a feature and they're proposing to
add a different feature, it's also about what about
doing it this way instead and that's an open issue about
the design of the feature.
tantek: If it is documented as an open issue, that should be
documented in a blog post today. :has() might not make it
because there's open issues and if you care help us
resolve it.
glazou: I'm hearing a majority that doesn't want to drop :has().
Second, we need some time to work on this and push on
implementors or devs. It's another signal saying lets give
us a few weeks and publish a CR with better feedback. We
have a F2F in Aug and that's the time to do this.
tantek: If we agree to decide in Aug, anyone blogging now should
point out that timeline to the community. Say 'hey we're
going to make a call at this meeting and you need to give
feedback before that'.
glazou: I'll use my superpower of chairmanship to publish that on
my blog and draw that attention.
<gregwhitworth> just made a MS Edge uservoice:
https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/8977591--has
plh: I believe you have all the rights to publish on the W3C blog
too if that helps.
<bkardell> https://twitter.com/briankardell/status/623892832953200641
plh: I'm happy with the plan, but in the meantime can we update
the WD in /tr? I'm not asking for CR- just updating the
issues draft and publish it in CR.
<tantek> +1 updated WD
<tantek> is Selectors still using the old pub system?
fantasai: The next publication will be a WD and we'd rather do it
soon, but I need to go through the draft. Before we
publish I want to make sure everything is correct. I
think we might want to defer non-controversial things so
there's less to review. We'll keep :has() in the next
WD, but I'd like us to go through some of the other
items.
plh: If you can do it in the week that would be nice. The draft in
tr is just too old. The sooner we can update the better.
fantasai: A week isn't reasonable because it takes a week to
publish and I have to review. Maybe 2 weeks.
plh: I was asking you to give a +1 to publish next week.
fantasai: If I go through the entire document and there's nothing
that needs fixing we can resolve to publish next week. I
likely will have a bunch of issues and have to push it
off.
tantek: What's the delay with another WD?
fantasai: I don't know of anyone else that was reviewed the
changes in this WD over the last years. I'd like someone
to review it to make sure that nothing has been dropped.
glazou: Publishing the WD is a call for the review.
fantasai: I'm an editor and either we can remove me as an editor
or we can wait until I review.
dbaron: A bunch of what's in here hasn't been discussed in the
group. It's stuff where there was a ML post and it got
into the draft.
glazou: Yes. It's sometimes more of an idea sink. That's why the
list from fantasai has almost a dozen features to drop.
fantasai: The list in the draft are ones that have been discussed
in the WG.
tantek: The right criteria for TR is if it's better than the last.
I find it hard to believe that publishing this wouldn't be
better than having a draft that's 2 years old. However I
sympathize with fantasai's concerns about not having
reviewed as a co-editor. Can you consider what's the
minimum level of review you need to publish? I understand
wanting to be thorough, but I think we need to update.
fantasai: If I review I'm going to be thorough. The changes that
need review are detailed.
tantek: Okay, fair.
<dbaron> I'd want section 3.2 either removed or rewritten if we're
going to publish on TR.
<TabAtkins> dbaron: The thread on 3.2 died off waiting for a
response from you, iirc
<dbaron> TabAtkins, there's one message from you in the thread, to
which I replied
CSS 2015 prose and prefixing policy
-----------------------------------
<glazou> https://lists.w3.org/Archives/Public/www-style/2015Jul/0261.html
glazou: So fantasai and Florian requested review.
Florian: It was fantasai and TabAtkins, but I was a part of
writing an older draft. I have reviewed the latest and it
matches my memory, but I didn't review enough to speak on
details so I'd like another week. High level, though,
it's good to me.
Bert: I like it overall. It's a bit vague in some places, but I'm
not sure that can be helped. It mentioned browser instead of
UA and I'm wondering if that could be a problem for the
features that are only done by UA.
Florian: There's a difference between things exposed to the web
and things that aren't. So if we define browser as
something exposed to the web...we need to clarify, but we
need to clarify the difference between exposed to web and
not.
glazou: A batch processor prints something without a dynamic
environment.
Florian: It should be a browser.
glazou: It's going to be tricky.
Florian: That's why I want a week.
hober: The blog post write-up I think makes assumptions about how
browsers are shipped that aren't necessarily true.
hober: I think we shouldn't as a WG impose specific release
strategy on browsers. In section B there's a line that says
"experimental features ship only in non-release builds"
which assumes there's a thing as a non-release build and I
don't think we should demand that.
TabAtkins: It's an implicit case.
hober: Where do you ship experimental features?
fantasai: You don't. You're not allowed.
Florian: You could tweek the wording to allow a flag. Taking one
step back I remember what you said and when trying to
word that I remember that the general way to do it didn't
match with Apple and it was generally a 'you should do
this' rather than a 'you must do this'.
hober: I think your suggestion of a run-time flag improves the
degrees of freedom that we're giving browsers. What I was
trying to say is it's a mistake for the WG to impose a
release strategy so allowing a diversity is better.
TabAtkins: We want a policy that works well for the web in the
future. If it's something like that make a suggestion
in the thread and we'll word-smith it.
smfr: Historically iOS apple hasn't had experimental releases so
we can't ship if we follow these rules. So we wouldn't have
shipped transitions, animations, etc. It feels like it's
impeding progress. I understand wanting less prefixing, but
I don't want to prevent browsers from innovating.
<tantek> smfr is making good points
<tantek> OTOH we're now stuck with having to support -webkit-
prefixes for some properties on mobile because they've
taken root in some geos
<TabAtkins> Note: transitions/animations/etc, while great, are
PRECISELY THE SITUATION WE'RE TRYING TO AVOID because
of how crazy annoying and painful they've been to iron
out inconsistencies that were baked in due to early
shipping.
<tantek> TabAtkins it's a tradeoff - no easy answer :(
Florian: We considered this specific case. It was good that Safari
pushed for innovation, but the standardization wasn't
good. That's why in general the prefixing policy says you
shouldn't release what hasn't been discussed. It also has
'if you end up doing it, here's how you prefix and here's
how others should react'. We realize you will and it's
innovative, but will also screw up with standardization.
smfr: I think that's why we're okay since it's a should.
* fantasai reminds everyone that this text is attempting to
reflect http://www.w3.org/blog/CSS/2012/08/30/resolutions-53/
smfr: Another high level question, is any of the text actually
normative?
Florian: Given that it's shoulds and musts it sounds normative.
fantasai: This is the in the boiler plate for every module. In
that instance it's most definitely normative.
fantasai: We discussed how the snapshots used to be WD because we
wanted it to be non-normative. The WG resolved to make
it a note. You can conform to a note, but it's not a
required. In regards to a note its status isn't REC
track. So you can conform, but I don't know what the W3C
thinks of that.
fantasai: We do need this stuff to be normative. You're
non-conforming if you, for example, you parse things you
don't support.
smfr: That sounds fine. I think that this will appear in every
spec means we must agree.
gregwhitworth: TabAtkins have you spoken with Chris Wilson and the
other people that were working on it so that
authors can rely on it working?
TabAtkins: We've discussed it, but not beyond 'maybe this is a
cool idea'.
gregwhitworth: It might be good to loop those people in. Come up
with even above the WG so authors can have the
flags and can turn them on so real users are
supplying real feedback.
TabAtkins: It might be good to bring to TAG so they can discuss.
fantasai: This is intended to reflect a bunch of resolutions three
years ago and a bunch of discussion we had around this.
hober: I haven't clicked through to the minutes, but I was
surprised to see that we thought this was resolved. My
recollection was we didn't resolve anything. It was three
years ago so I can be mis-remembering.
<fantasai> hober: yeah, you're right, we didn't put final approval
on it
<fantasai> hober: due to lack of proposed text
<tantek> yeah, agreed
Florian: We did on some high level concepts but not all the
details. Based on the agreed high level ideas I was
tasked to write it, I did it with fantasai, passed it on
to SimonSapin and we've juggled the hot potato.
hober: Okay, that makes sense. It seems risky to resolve without
details. I guess if we resolved on a bunch of things
without details that could effect how people felt.
Florian: There's tension between discussing first and shipping
first-discussing later. The rules are drafted in favor of
browsers who can discuss before shipping, but they don't
ignore that it happens.
hober: I like what you just said. I wish this said that. If you
can do it, do blah. If you can't, don't.
Florian: The intent is the same. It's details in the wording and
that's important, so let's take a week or two and decide.
fantasai: While we're here, Florian would you like to be an editor.
Florian: Sure.
glazou: Objections?
RESOLVED: add Florian as an editor to the snapshot
fantasai: Can we add TabAtkins?
glazou: And objections?
RESOLVED: add TabAtkins as an editor to the snapshot
glazou: We have 8 minutes.
Florian: And we've done topic 1.
<fantasai> hey, we pre-emptively dropped a bunch of topics already!
CSS Break
---------
<glazou> https://lists.w3.org/Archives/Public/www-style/2015Jul/0285.html
fantasai: I'll summarize. First issue is a concern about
break-before 'any' and 'always'. Second is margins. When
you have a forced break and you preserve the margins
after the break. If you're doing unforced we collapse
the margin into the page break so your content is flush
with the top.
fantasai: Because of how cloning works you might have a clone
margin at a forced break and you might end up with it at
the top of the page. I wanted to add a rule that drops
the cloned margins even if you're at a forced break,
because the element requesting the margin isn't the one
forcing a break.
fantasai: Just wanted to make sure people are okay with that or if
anyone has a different opinion on how things work.
Florian: Conceptually I understand, but I can't decide without
examples to look at. You're probably right, but it's too
abstract for me.
fantasai: So do cloned margins ever get kept at page breaks at the
top of the page or do we always drop them?
SteveZ: I think you're moving in the correct direction. I just had
trouble understanding the wording you put it as saying
that. My concern is a bit like Florian's. I'd like to make
sure you're still preserving the behavior on first pages,
but not when it's not quite first page. It's not clear to
me that it's only the cloning case.
fantasai: It's just the clone case.
SteveZ: I'm happy with that, but people need to look at the
wording.
bradk: Could this be solved with collapsing the page margins?
fantasai: Sort of. That's sort of what happens.
bradk: There are really big margins if you want it off the top of
the page.
SteveZ: These are fragments, not elements.
fantasai: Please continue to think about it and if you're still
not sure next week we can talk more.
glazou: So let's defer to next week. 2 minutes on the call.
glazou: I don't think we have a 2 minute item.
user-select: none
-----------------
<glazou> https://lists.w3.org/Archives/Public/www-style/2015Jun/0132.html
Florian: This is user-select: none and a question of should we
have it. I think we should, but a number of people say it
can be abused horribly as copy-protection. Given its been
raised a couple of times it would be good for the WG to
decide. It can be abused, it has valid cases, there are
warnings not to misuse it and permission to browsers to
work around the abuse.
glazou: I'd like a week of review. I want to make absolutely sure
it won't harm my software.
<tantek> I think the abuse is more likely than the valid
use-cases, thus I'm leaning towards drop
<tantek> especially since there's already sites working even
harder to block users
<tantek> the evidence is there that sites would abuse
<tantek> let's not make abuse easier
Florian: If you disagree with how it behaves we can keep working
on it.
TabAtkins: We consider it a useful feature.
<tantek> if you consider it a useful feature, then perhaps we need
specific documentation of such use-cases
<Florian> tantek: I have that in the spec already
Florian: So if we agree it's useful and we may need to tweek it,
but won't drop, I want a WG resolution that I can point
to next time someones says it should be dropped.
glazou: I consider it a useful feature.
SteveZ: abstain
glazou: Anyone else?
smfr: I think in webkit we have valid use cases.
tantek: I have mixed feelings. I sympathize with useful features,
but the evidence I have from sites that try to hone the
experience more make me think that if we lower the barrier
to abusive sites it makes it more likely sites will be
abusive. I'm not sure the usefulness outweighs the abuse.
TabAtkins: Its been in webkit and blink for years and there isn't
much abuse.
tantek: Okay. That's a good data point.
<Florian> Mozilla has had it as well for years.
glazou: tantek, can you live with it's a useful feature and we
don't drop it.
tantek: Yeah.
glazou: Any objections?
<tantek> 0
RESOLVED: user-select: none is a useful feature and we won't drop
it.
glazou: Thank you for today, talk to you next week.
Received on Thursday, 23 July 2015 11:52:12 UTC