- From: Stephen Zilles <szilles@adobe.com>
- Date: Fri, 11 Mar 2016 02:16:49 +0000
- To: Dael Jackson <daelcss@gmail.com>, "www-style@w3.org" <www-style@w3.org>
- Message-ID: <db024j71j863j7j340lbi7pa.1457662531377@email.android.com>
Dael,
I was on the phone call as the minutes show but I was not on IRC.
Steve Zilles
Sent via the Samsung GALAXY S® 5, an AT&T 4G LTE smartphone
-------- Original message --------
From: Dael Jackson <daelcss@gmail.com>
Date: 2016/03/10 3:44 AM (GMT-08:00)
To: www-style@w3.org
Subject: [CSSWG] Minutes Telecon 2016-03-09 [css-values] [css-writing-modes] [css-ui-4] [css-scoping] [css-grid]
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
F2F Meetings
------------
- There's work being done to get bigger spaces for the May F2F.
Currently Wednesday has the worst space constraints.
- The TPAC meeting day request will be for the Monday/Tuesday slot.
Ideographic Character Unit
--------------------------
- There are two different views about how the proposed ideographic
character unit should behave; one describing what
Firefox/Safari does and the other what Chrome does.
- The use cases with examples will be posted to the mailing list
where discussion will continue. If needed, this will be added
to the May F2F where a whiteboard can be used to explain
examples.
user-select property
--------------------
- There was broad agreement around having -webkit-user-select be
an alias, but leaving it undefined as to how the alias works.
New York Grid Workshop
----------------------
- fantasai gave a brief overview of the feedback that came from
the New York grid workshop. She'll be updating the spec and
filing issues to the list.
===== FULL MINUTES BELOW =======
Agenda: https://lists.w3.org/Archives/Public/www-style/2016Mar/0138.html
Present:
Rossen Atanassov
Bert Bos
Tantek Çelik
Alex Critchfield
Elika Etemad
Daniel Glazman
Tony Graham
Koji Ishii
Brian Kardell
Thierry Michel
Michael Miller
Anton Prowse
François Remy
Florian Rivoal
Hiroshi Sakakibara
Alan Stearns
Lea Verou
Greg Whitworth
Regrets:
Dael Jackson
Brad Kemper
Peter Linss
Scribe: fantasai
F2F Meetings
------------
astearns: Working hard to get space that will fit.
astearns: Confirmed for SF for May 9-15 for CSS + Houdini
astearns: Lots of space Tues/Fri.
astearns: Less-bad for Mon/Thurs.
astearns: Wednesday is difficult- still looking for a slightly
bigger space.
astearns: Might have to split into tracks or have constrained
number of people attending.
astearns: Will try to arrange agenda to match.
astearns: Will put up a wiki page for meeting today.
Florian: We can start booking tickets?
astearns: Yes. Definitely.
tantek: Are these Google's offices in SF?
Rossen: We'll have the details with hotels/whatnot up pretty soon.
tantek: May 15th after F2F is Bay to Breakers, one of the most
epic races of the year, in case you want to stay the
weekend and participate in 12K :)
astearns: Yes, we are going to meet at TPAC in September!
astearns: Guessing we should ask for standard M/T meeting slot?
Florian: No reason not to.
<gregwhitworth> yes, since we don't have one in Aug.
Rossen: Did we want to discuss January?
Rossen: Not yet ready to talk about it, but would be good to ask
for general location?
Rossen: And if anyone is thinking about hosting?
Rossen: There was interest expressed for April in Japan.
Rossen: and for January, or soon after December.
Rossen: Alan and I were discussing Seattle;
Rossen: winter here is relatively mild.
Rossen: This will be our backup, unless someone has a different
idea.
Rossen: Think this is more of a call for where do y'all want to
meet in January?
Rossen: If North America, given Europe and Japan before/after that
Rossen: Where in America?
<Florian> +1 for Hawaii
Rossen: Don't have to close on this. Just put a pin on it and
discuss next week.
astearns: Yes, so if anyone can host elsewhere, let us know.
Otherwise we have back up in Seattle.
Ideographic Character Unit
--------------------------
<astearns> https://lists.w3.org/Archives/Public/www-style/2016Mar/0078.html
Florian: Discussed this at Sydney.
Florian: For various reasons, would be good to size things
according to CJK ideographic characters.
Florian: Talked about either 2 units or 1 unit.
Florian: In practice only need one.
Florian: So should have something like ch unit, except based on a
CJK character instead of zero.
Florian: I noticed that the ch unit is not clearly defined how it
works with writing modes.
Florian: Earlier on IRC, fantasai wrote what I think is the right
thing to do.
[fantasai's comments:
ch should always be "advance measure"
sorry "advance measure of zero"
and ic should always be "advance measure of water character"
Which dimension is the advance measure depends on writing-mode
and text-orientation
and what the advance measure is depends also on the fonts
]
Florian: This is currently what Firefox does and Safari IIRC, not
Chrome.
Florian: Dunno about IE.
fantasai: [missed]
fantasai: Does anyone have issues with this, or can I put it into
the spec?
fantasai: So, proposal is use the advance measure, which will
depend on writing-mode and text-orientation
fantasai: I can edit details into the spec.
<fremy> fantasai: ch is dependent on writing modes, this one
should be consistent with that
koji: I think ideographic character unit should just be the width.
koji: But ch is average of characters.
fantasai: No it's not, it's measured from zero.
koji: ic unit would be same as em.
[no it wouldn't]
Florian: If you have a font with non-square characters, it would
not be the same as an em.
Florian: If you look at snap proposal you have, if you don't have
this unit it doesn't work.
koji: It works.
Florian: Not for all fonts.
Florian: We can make it work 100% of time by having this unit.
Florian: Both ic and ch need to disambiguate the use of "advance
measure."
Florian: I propose we define ic exactly as we define ch, except
defined against different character.
Florian: Fallback values being .5em and 1em respectively.
Florian: Both based on "advance measure", which should be
writing-mode and text-orientation dependent.
koji: ch should remain width
Florian: What do you mean "remain"?
koji: ...
Florian: Why do you think it's useful for ch to not match the
advance measure in vertical writing?
koji: ch being somewhat narrower than em is my general
understanding.
Florian: If you want 0.5em use 0.5em. If you want the advance of a
character, use the ch.
koji: ch doesn't match characters.
Florian: It exactly matches to zero.
koji: That's not useful.
Florian: In monospace fonts its the same for all characters.
astearns: It's also useful for numerals when you're using the
opentype feature that makes them tabular.
fantasai: Nobody is arguing that you should use ch instead of
ideographic, that is clearly wrong.
fantasai: ch matches to width of narrow characters in monospace
fonts, and of numbers when they're tabular.
koji: I want to keep that definition in vertical, too.
koji: If want ideographic height, can use em today, don't need ch.
koji: ch character then would be 1em always
fantasai: I think you're confused, no one's saying to use ch
instead of ideographic.
fantasai: If you have numbers in vertical writing mode, and you
have a phone number and you want the input to take 7
chars.
fantasai: The ch is not for CJK.
fantasai: That's not necessarily true, if you have a font that
puts in vertical metrics then it will not be 1 em, it
will be less than 1em and you'll want to reduce the
spacing by the descent height.
fantasai: It depends again if it's monospaced or not.
Scribe: gregwhitworth
astearns: I'm wondering if it makes sense, with what Florian
described a while ago with a proposal, put the formal
proposal on the mailing list and have the discussion
there.
florian: The writing is there on the mailing list.
astearns: Is the ambiguity fixed in spec text?
florian: Yes somewhat, we'll need prose but there is no more
ambiguity.
astearns: ahh
florian: I think fantasai and I agree, that's what Safari/FF do.
Chrome/Koji agree.
fantasai: They do have an equivalent, the glyph orientation
property.
astearns: Maybe some examples would be helpful in actual use cases
to make the best decision.
fantasai: The most common is input.
fantasai: The use case for the behavior Florian is advocating is
"I want this input element to contain approximately X
characters"
fantasai: I would like the usecase that Koji is advocating for.
koji: I explained on the mailing list that ch is like em.
florian: If you want 0.6 em, write that.
koji: The same applies to you.
florian: No I can't, I want something in a measure that isn't
provided.
fantasai: I don't see any use case for the behavior Koji is
advocating.
<Bert> (So if I understand correctly: a 'width: 5ch; height: 5ch'
box is always square, but it becomes twice as wide when you
set 'writing-mode: vertical-rl'?)
astearns: This discussion is not productive, I suggest take it to
the list.
astearns: Please put use cases with possible visuals, if not we'll
use white boards in May.
florian: While we're on this topic, do we agree that there should
be an IC unit?
fantasai: We already have a resolution on that from Sydney.
user-select property
--------------------
<astearns> https://lists.w3.org/Archives/Public/www-style/2016Feb/0050.html
florian: This is common in webkit prefix form.
florian: We agreed to add this to the spec and we left some
functionality open.
<zcorpan> there's https://compat.spec.whatwg.org/#css-prefixed-aliases
btw
florian: Should the values accepted be just what is supported by
webkit, leave it undefined, be the alias for their prefix
form.
florian: If you do Mozilla values that aren't supported by
-webkit-user-select is supported.
florian: I'm not really interested in speccing something that
should change, just reality.
florian: I'm in favor of leaving it up to the UA
<fremy> +1
<tantek> I'm going to note https://compat.spec.whatwg.org/#-webkit-user-select
tantek: The web compat spec says it's just an alias, this is the
current state
tantek: I think that's why you're seeing what you're seeing.
florian: No, I don't think so - that was added recently.
tantek: They are consistent, which is a good place to be.
tantek: Treating it as a prefix property does not imply, prefix
property value aliases.
tantek: We can specify that part of the detail.
florian: That was my point of the second question, do we need to
define aliasing?
florian: They're very close, but not exactly identical.
tantek: That section defines how aliases are supposed to be treated.
florian: I would argue that we should not define how aliasing
works, while it's slightly different I'm not sure it
matters.
florian: I've done the best to find the differences, but I'm not
sure it's worth going into that.
<zcorpan> isn't it defined somewhere already how aliasing should
work?
tantek: There are two issues there, I'm fine leaving the
definition of aliasing undefined in the UI4, or just link
to the compat spec.
tantek: I'm not passionate one way or the other.
tantek: The other is the behavior in webkit-user-select, if the
functionality is quite different from just aliasing we
should document that, but I suggest to add that to the
compat spec.
florian: [reads his testcase regarding transitions with
webkit-user-select]
florian: I feel this is unimportant.
florian: I was told to investigate, and browsers don't narrow it
down.
tantek: I'm fine leaving it undefined until someone finds a compat
case.
florian: As for the values to be supported, I'm not in favor of
restricting to what just webkit supports as that is not
what FF/Edge do and I don't want to spec what they're not
doing unless they're willing to change.
<tantek> https://compat.spec.whatwg.org/#css-prefixed-aliases
tantek: Yeah, I think this answers that question.
tantek: I'm fine with how it's defined there.
tantek: Let's wait for a concrete reason.
tantek: Are we done?
tantek: Do we want to spread this compat information across specs,
or just in the compat spec?
florian: Not sure I want it just in the compat spec.
florian: Propose webkit-user-select as an alias, without specing
how browsers do it which is good enough for compat reasons.
fantasai: Explicitly say it is undefined.
florian: I don't detail it out, that should imply that it is
undefined.
tantek: I think you should link to the compat spec as it may not
be obvious to everyone.
fantasai: I think you should say that how alias is done is
undefined.
florian: ok, I'll leave it undefined.
fantasai: I'm happy with that.
tantek: I can live with that.
astearns: alright
<fantasai> should *either* say exactly how to do the aliasing or
*explicitly* leave it undefined
<ChrisL> not happy with it but won't object
<ChrisL> wolliness+1
<tantek> fantasai - my point is, don't say exactly how to -
instead reference compat for that, if that's what you
want to do
<fantasai> Proposed Resolution: -webkit-user-select is aliased,
it's undefined how
ChrisL: The explicitly undefined, if everyones doing it we should
specify that.
rossen: Regardless of what we say as an implementer we're not
going to change how we alias stuff. Any additional work
added, we're not going to do. If you make it explicitly
undefined leaving then that is fine.
rossen: Making it more rigorous though is different.
ChrisL: ok
fantasai: If this was on the standards track then I think we would
define it, but it's just there for web compat and we
hope it will disappear.
tantek: That's why I suggest moving it to the compat spec.
fantasai: There was another discussion about this in Sydney, but
keep it in spec with just one line of prose that state
you should implement the webkit as an alias for web
compat.
fantasai: We want it to be obscure, but close to the definition so
the implementations can be web compatible.
florian: It disappearing from the web would be nice, but since
every browser has seen a need to implement it that's
unlikely.
SteveZ: My issue with this, is the people having issues with this
is by people who have implemented it, the specs are for
people that will implement it.
Florian: There will not be two definitions since the people of the
compat spec will remove it as soon as we have it.
astearns: I think we should move on.
Scoping and Shadow DOM
----------------------
astearns: Tab said he's fine adding it to scoping and we should
comment on the spec text
astearns: I brought it up because there has been no response
<bkardell> Ok to comment on the spec text, I missed it and
actually need time to wrap my head around it.
New York Grid Workshop
----------------------
astearns: It seems, at least on twitter, is there a simpler
subgrid solution. I'm curious what that entails.
fantasai: Two things happened, the implementers got an idea how
important subgrid is, and the authors said they would
rather wait 8 months for subgrid than have grid earlier.
fantasai: They had issues with min/max dimensions and those aren't
issues since those are restricted on subgrids.
Rossen: Who were the implementers?
fantasai: Igalia
fantasai: There were some cases where we need to define what
happens when a subgrid overflows its grid area, and that
seems to be difficult to implement and we're happy to
change that in the spec.
fantasai: I'll need to go through the subgrid spec and open issues
to figure out the easiest way to handle the edgecase
rather than just a way to handle them.
astearns: It would be good to get list info on these changes since
there was only one implementer in the room.
fantasai: I agree.
astearns: I love these workshops, and like the feedback you get -
it would be great to get that feedback to the list and
would be important going forward. Get the minutes of the
group if possible.
fantasai: Normally what happens are very editorial, but if there
are actual issues I file them against the list.
rossen: One more thing, I want to reinforce the point is that
these are awesome.
<glazou> +1 to what rossen said
rossen: In this particular case there was a lot of hype.
rossen: I don't want to see statements that look like WG
resolutions and see tweets from influential authors saying
we're going to need to wait to ship until subgrid is in.
rossen: I think the workshops are great for feedback from the
community but I want to keep the resolutions of the WG
within the WG, and keep the public confusion to a minimum
if possible.
fantasai: To respond to that, I don't have any control over what
other people say, so I don't see what I can possibly do.
Do you want me to tell people to not write about it?
rossen: No, I'm not asking you to do that, just set the stage from
the beginning possibly that nothing coming out of these
discussions are not in stone until their reviewed by the
CSSWG.
glazou: Rossen, I'm not sure if that is a problem since they're
not part of the WG.
glazou: Maybe we should reach out to Igalia to join the CSSWG, we
would benefit from having them on the group.
astearns: They have provided feedback to the list and helped out
on CSS Shapes.
tantek: That's still not membership.
rossen: Good feedback, I'll reach out again
astearns: I'm looking forward to seeing the spec update.
fantasai: Me too.
astearns: Adjourned.
Received on Friday, 11 March 2016 02:17:29 UTC