- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 25 Jun 2015 07:36:00 -0400
- To: www-style@w3.org
status of will-change
---------------------
- The request for CR publication was never made, so that will be
addressed offline as to continue the progress of the spec.
Spec Publication Process
------------------------
- Everyone was okay with moving to a process where spec authors
handle the publication instead of the team contacts doing it.
The exact details of the process will be decided on the
mailing list.
CSS UI 3
--------
- RESOLVED: Publish CR for CSS UI 3
- Florian will handle the publication
calc() serialization
--------------------
- RESOLVED: For computed values and further, if the calc() is a
single unit, remove the calc() and just have the naked
value
Resolution Media Query
----------------------
- RESOLVED: Accept TabAtkins proposal for removing ambiguity from
Resolution MQ (thread with proposal:
https://lists.w3.org/Archives/Public/www-style/2015Jun/0131.html)
Unicode Range Tokens
--------------------
- TabAtkins brought the problem he had creating a replacement for
unicode-range-token to the group with two solutions
1) We call it a failure and we have have weird special purpose
token.
2) We accept that the current syntax is hosed and invent a new
syntax. Specify the old way for backwards compat, but with
a strong warning not to use it.
- Opinion was a bit mixed in the group, but ultimately they need
to wait to hear back from SimonSapin and the rest of the
Mozilla team.
an+b selectors
--------------
- Everyone felt this was possible, but that there wasn't enough
demand to justify the implementation time.
- RESOLVED: Reject an+b comma separation without prejudice
Proposal to modify how inline-block with non-empty block descendants
are baseline-aligned
--------------------------------------------------------------------
- The editors will continue to discuss this on the mailing list
once they have had time to look into the mechanics of making
it happen, but they are generally in favor of it.
Elements and nested scrollers
-----------------------------
- smfr had some concerns about the reintroduction of elements to
nested scrollers as well as the ability to scroll in a diagonal
- The group will wait until the spec text is finished to continue
the conversation so that there is something solid to base it
on.
CSS Text
--------
- Florian requested that people respond to his e-mail with
suggested solutions for the issues created by introducing
pre-wrap-trim in level 4 (e-mail here:
https://lists.w3.org/Archives/Public/www-style/2015Jun/0099.html)
===== FULL MINUTES BELOW ======
Present:
Rossen Atanassov
Tab Atkins
Bert Bos
Adenilson Cavalcanti
Tantek Çelik
David Cramer
Alex Critchfield
Elika Etemad
Simon Fraser
Daniel Glazman
Tony Graham
Dael Jackson
Brian Kardell
Brad Kemper
Philippe Le Hégaret
Peter Linss
Myles Maxfield
Michael Miller
Anton Prowse
Matt Rakow
Florian Rivoal
Andrey Rybka
Hyojin Song
Lea Verou
Greg Whitworth
Regrets:
David Baron
Sanja Bonic
Tim Dresser
Edward O'Connor
Simon Sapin
Alan Stearns
Takayuki Tsukitani
Ian Vollick
scribe: dael
plinss: Let's get started.
plinss: Anything to add to the agenda?
Florian: To clarify, item 10 is named CSS UI Issues, but links to
a mail of mine that has other issues besides CSS UI. For
CSS UI, all issues have fixed and I'd like to go to
publication. If we could discuss publishing early in the
call that would be nice.
plinss: We have other publication things to talk about too so
that's fine. I wasn't sure if you were ready for CR.
Florian: I'm ready.
status of will-change
---------------------
plh: So I'm trying to see, was there a transition request? I
didn't see any.
plh: So it was never asked.
plh: As far as I can tell.
glazou: We have a resolution from end of March to publish so let's
do that.
plh: I'm happy to help, the action wasn't asked so that's why it
didn't get a response.
plinss: Sounds like something got dropped. We'll take care of that
offline.
Spec Publication
----------------
plinss: There was a question about letting editors publish their
own specs.
TabAtkins: So according to Robin every other WG lets spec authors
publish own spec. There is literally no requirement for
team contacts to do that, so why aren't we letting
authors publish their own spec?
plh: The answer is I don't know. Not every other WG does let
authors publish; some do, some don't. It varies widely. There
is no requirement that it be team contacts.
glazou: So that's mostly the WG history. We've always gone through
team contacts.
Florian: It has pros and cons. Given that it's annoying to
publish, having team contacts manage it is nice. But we
have lots of specs and requests. Some pub requests
get delayed and following up is a bit of a hassle.
plh: My recommendation would be if you could move to the Echidna
system, that would be better.
TabAtkins: I'm working on getting bikeshed on it.
plh: There are some use cases for this group that we're not
supporting yet. We're working on it.
plh: It only supports WD from a single WG. It doesn't support any
other status. If your WD is with another WG that doesn't work.
plh: We also don't support exceptions such as the CSS Validator
stuff this group has been asking about. We have ideas on how
to support it, but it's a question of the most urgent thing
at the moment.
Florian: Where we can use it we should try, but it's not
everywhere. Another downside of our way is when something
bad happens the editor doesn't know.
glazou: Let's not go back to that. We discussed that during the
last F2F and I've discussed it with the webmaster. The
webmaster will use the original e-mail with CCs for other
authors to notify about publication.
smfr: Is that written anywhere?
TabAtkins: There's a page on the wiki. I'm not sure if it is
there, but it should be in the how to publish on the
wiki.
<TabAtkins> (Step-by-step guide, I check it every time:
https://wiki.csswg.org/spec/publish)
glazou: I think I sent an e-mail to the WG a few weeks ago saying
that all publication requests should be CCed to the
editors.
glazou: Yes, I did it on 29 May.
Florian: That removes one down side.
Florian: But can editors do it themselves?
plinss: I have no objection to editors publishing themselves.
According to the guidelines we've discussed I'm okay.
TabAtkins: Lets work out the details on the ML.
CSS UI 3 to CR
--------------
<tantek> yay!
<tantek> Thanks Florian
<Florian> http://dev.w3.org/csswg/css-ui/ changes
Florian: Yes, it's down to 0 issues. I updated the spec to have
the list of changes WD by WD.
Florian: I also made the DoC
<Florian> http://dev.w3.org/csswg/css-ui/issues-2012-2015.html
Florian: There are a few changes since last WD, very small. They're
listed in the URL above. I think we can go to CR, though
if people disagree we can do a WD for a week. I don't
think we need that.
Florian: We'll publish and likely update again.
<tantek> we made changes that the group expected, e.g. dropping
padding-box
<tantek> I think we should go directly to CR
TabAtkins: I'm fine.
plinss: Any objections to CR?
RESOLVED: Publish CR for CSS UI 3
plh: So who has the action to send the transition request.
<tantek> transition request? up to staff?
Florian: If there's a how to guide I'm happy to do it. Or I can
bother a team contact to tell me how to.
plh: I'm happy to point you to them.
ACTION: Florian to handle publication for CSS UI 3
<trackbot> Created ACTION-697
* glazou thanks plh for stepping in on that one :-D
Florian: Is that okay tantek?
tantek: That's fine. I thought it was just a staff thing.
Florian: Yes, but we just talked about letting editors do it.
tantek: Alright, whatever makes it faster.
glazou: The transition call will still be between W3C staff and
chairs.
glazou: We have to make sure whoever is invited to the call is in
the loop.
Florian: Just give me the how to and I'll do it.
plh: I'll be happy to draft it, Florian.
<tantek> Does there always need to be a call? Just curious
<tantek> in terms of what's required for process
<tantek> thanks plh
calc() serialization
--------------------
TabAtkins: So, it's not defined how calc() serializes. I agree it
should be specified. There's one bit I'm not sure
about, which is if you can simplify something down to a
single unit, does it have to be maintained as a calc()
or can you reduce that to a simple value, like 5pm?
TabAtkins: I'm fine with serializing down all the way and I'm fine
with writing what we decide in Values and Units.
TabAtkins: If there are opinions let me know here or on the ML,
otherwise I'll spec it up.
Florian: If that's the question, it implies for other situations
you're trying to simplify as much as possible. I'm not
objecting, but that's what you mean.
TabAtkins: Yes, I think we're not going to remember the exact
form, we're serializing to the smallest tuple.
glazou: I'm looking at the original e-mail. What is the
serialization about, everything?
TabAtkins: All of them.
glazou: I'm objecting to the OM part. It is a complete blocker for
editors.
glazou: If you add to a stylesheet calc(something complex) and
you're editing through a UI and the serialization
somewhere gets rid of the complexity that is good for
editing, it invalidates it.
TabAtkins: Okay, so we should give back the exact.
glazou: Computed is whatever you want. Reduction to a unit is fine.
For the OM when you serialize you shouldn't tweek the
value of calc(). You can do some optimization, but if you
have different units it should be preserved.
TabAtkins: How about we preserve everything as is?
<bkardell> tabatkins, what would it look like in devtools?
<TabAtkins> bkardell: DevTools has hooks into low-level stuff,
can represent however they want (probably keep it
literal).
<bkardell> TabAtkins, doesn't _glazou want the same sort of powers
as devtools there?
Rossen: I know a lot of expressions go down to a single value,
what is the motivation of just reporting the value and
dropping the calc()? Is there a use case or ask for it?
TabAtkins: We'd like to be able to simplify in the engine so
dropping the calc and just having a plain value is nice.
Florian: We have 2 use cases. glazou's where we want author intent
or in the case where we want to simplify as much as you
can including dropping the calc()
TabAtkins: There is still...the policy of it being exactly
equivalent, I don't think we can keep. When there's a
pixel and %, I think the % is meaningful. If you're in
a transition, you don't want a sudden shape change.
Florian: If it means the same thing, don't preserve...
TabAtkins: Where there are multiple units written in, we should
preserve the units.
TabAtkins: If you are writing something that works on string
values and you do 5px, 5% and -5px, -5%, you hit a
point where it's 0 when you transition. If you get rid
of the % you have a problem at 0.
Rossen: I'm in favor of preserving. We're not going to keep the
calc() when we go to a single value unit in the computed
style, serializing it back we can always have the calc
around the value, but it's easier to serialize just the
value without the calc and that has nothing to do with the
specified value so glazou scenario isn't effected.
Rossen: I was asking why you brought it up to see if there were
users asking for it.
TabAtkins: It needs to be specified and we have differing
implementations. I have a mild preference, but we have
to decide.
Rossen: Should we resolve?
TabAtkins: Yes. If anyone disagrees with the rest, raise those
issues. Elsewise we need to decide if we're stripping
the calc()
TabAtkins: For computed values and further, if the calc is a
single unit, remove the calc and just have the naked
value.
Rossen: Serialize out the simplification.
TabAtkins: In specified values we'd only combine identical units.
Florian: I'd rather that be nothing at all.
TabAtkins: I don't know if we keep around exact strings or
re-serialize the exact value.
Rossen: The computed one if it reduces to a single unit, it would
be better to serialize out the single unit.
glazou: I agree with Rossen from an editing POV.
plinss: My only concern is we don't have anyone form Mozilla and
we can provisionally resolve and let them ask to come back
to it next week if they disagree.
plinss: Any objections?
<tantek> no objections
<tantek> plinss - I'm from Mozilla - do you want me to check with
dbaron too?
* glazou tantek yes please
* plinss taktek, yes please, and SimonSapin (or someone else from
servo) as well
* TabAtkins tantek, yeah, getting dbaron signoff would be great
RESOLVED: For computed values and further, if the calc() is a
single unit, remove the calc() and just have the naked
value
Resolution Media Query
----------------------
Florian: I realized we define what happens when printing, but it's
not how typical printing works. They render to a PDF that
is sent to the printer and we don't define what happens
to the Resolution MQ when the medium is a vector
environment.
Florian: Even when you are in a vector medium, it happens that if
your page contains any raster image, it will be down
sampled.
Florian: That's the space we're in. TabAtkins and I have been
talking on the ML. TabAtkins do you want to explain your
solution?
TabAtkins: We add an infinity value to the Resolution MQ to
indicate it's vector. Then we add an additional MQ with
the same syntax and is the max resolution of the raster.
It will be no larger than the resolution, but may be
smaller.
Florian: 600dpi is a common value you could expect. It's common to
have a quality setting that includes down sampling.
Florian: We're both okay with that. I also suggested a boolean MQ
to say if you're in vector or raster medium.
Florian: I think the advantage of that is it doesn't let me do
non-interesting cases, but TabAtkins syntax is easier.
TabAtkins: When I was doing examples on the mailing list, you have
to use both the boolean and the resolution together. I
think that's non-intuitive. With my solution you can
use them independently.
Florian: I think TabAtkins proposal is fine. The only issue I have
is when the raster is higher than resolution. It's more
expressive than we need, but it's easier to understand so
I'm okay.
TabAtkins: If there are opinions express them on the ML.
smfr: When the browser is printing, it may know the resolution of
the output device.
TabAtkins: I agree that if you're going through an intermediate
format you're right, but if you're going just to a PDF,
getting that you want it better.
Rossen: Would this have an impact on source set? Would any
re-evaluation need to happen?
TabAtkins: No more than today.
Florian: They're orthogonal. source set needs to deal with the same
situation, but there's not dependency. Maybe a need for
clarification, but there's not behavior change.
Rossen: Okay.
plinss: Do people want to let these guys sort it out or make a
decision?
Florian: I'm okay with TabAtkins' proposal. If people want
something else we can go to the ML.
Rossen: How critical is it?
Florian: Not really. I don't know anyone is asking for it, I just
realized it was ambiguous and I wanted to fix that.
Florian: My use case is if you're high resolution use serif and if
not use sans-serif and resolution MQ couldn't do it.
Rossen: Okay.
plinss: Sounds like we're learning toward TabAtkins's proposal.
Should we resolve?
Florian: Sure.
plinss: Objections?
RESOLVED: Accept TabAtkins proposal for removing ambiguity from
Resolution MQ (thread with proposal:
https://lists.w3.org/Archives/Public/www-style/2015Jun/0131.html)
Unicode Range Tokens
--------------------
TabAtkins: A while ago there was a bug where something likE U+A
was triggering as invalid. I agreed it was weird and
the unicode-range was odd in CSS syntax. I tried to
remove it with something like An+B. That almost worked
until I realized we have exponentials and those are
giving me numbers instead of the correct value.
TabAtkins: This just screws it up. Certain hex numbers just won't
show up right. We have two choices. A) we call it a
failure and we have have weird special purpose token.
TabAtkins: B) we accept that the current syntax is hosed and
invent a new syntax. Specify the old way for backwards
compat, but with a strong warning not to use it.
TabAtkins: My suggestion is just replacing the + with a -
TabAtkins: SimonSapin was the person who most wanted to comment on
this and he's not here so we can't decide, but I want
other opinions.
TabAtkins: You can write a unicode as U+ or U- and we say don't
use U+
Florian: And you mean only fully support it for legacy?
TabAtkins: Yeah.
* fantasai thinks we need to hear from dbaron & jdaggett on this
Florian: What about webcompat?
TabAtkins: I don't know, but I could figure it out. It's not hard
to find all the ranges in unicode that show up. We can
see if there's stuff that would trigger this. I should
get someone to help me run that query.
TabAtkins: Assuming it shows up with no webcompat, what do we
prefer?
TabAtkins: And if there's no strong opinion, I'll wait for
SimonSapin to get out of his meeting and wait for the
results.
Florian: Uses of unicode ranges that happen to be scientific
notation aren't that common, but the selectors aren't
that common either.
TabAtkins: We know selector breakage happens because there's a
Mozilla bug report. We'll see if we'll cause any
breakage if we make this change.
Florian: My guess is they're both rare and both used.
plinss: My thoughts are if we're going to have weird behavior I'd
rather have it in places where unicode-ranges will occur.
TabAtkins: That's my opinion too. So you're leaning to option B?
<jdaggett> this is entirely an edge case
<jdaggett> u+a breaks, u + a won't
plinss: Yeah. I'm also concerned that you're proposing these as
the only two solutions and I can think of more. You
special case a Unicode where if it is in a selector you
have to break it down.
TabAtkins: That doesn't work well because you have to recombine.
plinss: It's not pretty, but it is possible. If you know it's a
unicode token treat it as a string.
TabAtkins: That's currently not allowed in the syntax spec.
TabAtkins: Yeah, so I had thought of those ideas and rejected them.
plinss: I'm happy to wait for Mozilla feedback.
an+b selectors
--------------
TabAtkins: Danial Tan suggested allowing a comma separated list of
an+b in the selectors that allow that. It's fine
grammatically and works great for nth of type. The
complication is there are a few places you could comma
separate in child. The easiest way is saying that the
entire an+b piece has to be comma separated.
TabAtkins: Or we reject the whole thing. Daniel came back and said
it might not be worth it.
<tantek> my initial feeling is it's not worth it
<bkardell> +1 this is pretty minor sugar - there are bigger fish
to fry
glazou: As you said, I understand the request and the use case,
I'm not so sure the number of people using it is worth the
implementation time.
glazou: I have no real technical objection, we can solve the
issues, but is it worth it?
<tantek> exactly what glazou said
<fantasai> +1 to what glazou said
<tantek> consensus on rejection then?
TabAtkins: That's my conclusion too. I'm comfortable with
rejecting until there's more author need.
Rossen: Agreed.
Florian: I like it, but can live without.
TabAtkins: I'm fine to reject an+b comma separation without
prejudice.
RESOLVED: Reject an+b comma separation without prejudice
fixed z-index interop issue
---------------------------
gregwhitworth: We don't have the people we need on the call, I
think.
gregwhitworth: We don't really, Blink, Edge, and Webkit agree. The
only people who may reject is Gecko. They started
hitting some of the things that made us bring this
up, but they're the ones that will be affected
still.
plinss: Okay. Deferred.
Proposal to modify how inline-block with non-empty block descendants
are baseline-aligned
--------------------------------------------------------------------
TabAtkins: That e-mail was from koji, but it was before we had
control over baseline more so maybe we should refine. I
don't have strong opinions on it.
TabAtkins: I defer to fantasai
<Florian> +1 to defering to fantasai
TabAtkins: This is koji suggestion to make inline-block different
in the presence of different baselines.
fantasai: I'm happy to do whatever makes the most sense to the
people who use it. If he thinks that we should change
it, I'm happy to do so, but I need to dig into the
mechanics.
fantasai: Do they want to be central aligned to first or last
baseline, or be centered?
TabAtkins: I don't know. I think we should look at the e-mail more
and deal with it on the ML.
fantasai: Yeah.
TabAtkins: Okay.
plinss: Okay, we'll take that back to the list.
Elements and nested scrollers
-----------------------------
smfr: Should I summarize?
smfr: This is with scroll-snap-point. If you have an overscroll
and has position absolute with a containing block, but it's
container is outside the scroller so it seems wrong to spec
that scroll-snap-points with elements will take position
from the absolute things.
smfr: I think it needs to be reworded to talk about an in-block.
MaRakow: I've been going through and I'm trying to wrap it all
into one thing.
smfr: Do you expect a new ED?
MaRakow: I'm working through it now.
smfr: The other issue is if it's independent of x and y
TabAtkins: I think they are.
MaRakow: One thing we brought up previously is if you should have
the ability of non-grid snap points. There was some
interest in that, so I'm wondering if there's a way to
satisfy both approaches.
<fantasai> Maps is a use case for snap points in 2D
smfr: The non-grid worries me because the user case of scrolling
and suddenly getting pulled sideways.
MaRakow: Yeah, right now the mandatory snap points are implying
that it makes no sense to have scroll and a non-mandatory
point. With that interpretation it would make sense to
move in both direction. I can see a way that makes sense
with nested columns and rolls.
smfr: It could be where you allow diagonal but if you're scrolling
sideways, your locked on that axis. Maybe the spec should
say more on how it moves on each axis.
MaRakow: Do you have a a motivating story we could use?
smfr: The typical brick wall style layout that an image designer
was trying to use. It's not written down.
TabAtkins: Like the typical Google image search. It fills in with
what it needs.
Rossen: So are we expecting a WD?
MaRakow: I'll be coming up with ways to satisfy both scenarios.
That's the idea.
TabAtkins: Sounds good.
plinss: So we're just waiting for spec prose?
MaRakow: Yeah, I need a little bit of time to work through
feedback.
CSS Text
--------
<Florian> https://lists.w3.org/Archives/Public/www-style/2015Jun/0099.html
Florian: Just something worth mentioning, I'd like fantasai and
maybe other people to reply to that e-mail.
Florian: We resolved to add pre-wrap-auto to level 3, and
pre-wrap-trim to level 4. The pre-wrap-* values in level 4
are tricky because white-space becomes a shorthand, and
it's not quite clear how to split these values between the
longhands. There are some suggestions in the mail above,
please look at it and reply.
plinss: Okay, that's the top of the hour. Thanks everyone and
we'll talk next week.
Received on Thursday, 25 June 2015 11:36:28 UTC