- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 8 Mar 2017 19:54:46 -0500
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
Japan Dev Meetup
----------------
- The suggested date for the meetup is either 18 or 19 April (the
evening before the first meeting or the evening of the first
meeting).
Multicol
--------
- Most of the issues will continue on github- the group only
discussed the issue titled "How do elements between
column-span and its multicol ancestor appear around the span"
(https://github.com/w3c/csswg-drafts/issues/1072)
- There was some interest in simplifying to make column-span apply
only to direct children of the multicol element however there
was also concern about headings nested in sections and similar
use cases.
- There was a desire to find out what browsers do to see if
there's already compatibility which would also lead to adding
some test cases to the test suite.
Clarify Segment Break Transformation Rules when multiple segment
breaks involve
----------------------------------------------------------------
- The group was in favor of the fix:
https://github.com/w3c/csswg-drafts/commit/82deba78668e732ad15c084391ffe1910ff3e3d0
It is unclear when offsetX/Y are calculated
-------------------------------------------
- Conversation will continue on github.
What are "form controls"?
-------------------------
- The actual definition of "form control" will defer to the HTML
group's open issue.
Variation Selection of Colorful (Emoji) or Monochrome Glyphs
------------------------------------------------------------
- RESOLVED: Add font-presentation to the spec and have it effect
font fallback.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2017Mar/0035.html
Present:
Rachel Andrew
Rossen Atanassov
David Baron
Bogdan Brinza
Tantek Çelik
Alex Critchfield
Benjamin De Cock
Elika Etemad
Daniel Glazman
Tony Graham
Dael Jackson
Brad Kemper
Vladamir Levantovsky
Myles Maxfield
Thierry Michel
Anton Prowse
Jen Simmons
Alan Stearns
Greg Whitworth
Regrets:
Tab Atkins
Bert Bos
Dave Cramer
Peter Linss
Michael Miller
Florian Rivoal
Geoffrey Sneddon
Steve Zilles
Scribe: dael
Rossen: Let's get going.
Rossen: Hello, everyone!
Rossen: As usual, a quick call to see if there are any additional
agenda items.
Japan Dev Meetup
================
Rossen: There was a suggestion for a meet up before or around the
F2F in April.
Rossen: I forgot who offered to host, but someone graciously
offered.
<astearns> Oli Studholme
Rossen: It's a great opportunity. I wanted to put it to the WG and
see interest level and what day to shoot for. Keep in mind
we have the publishing meeting on, I believe, Thursday.
Rossen: Thoughts? Suggestions? Feedback?
dbaron: I think we need to think about language issues in advance
if we have the meetup.
Rossen: That's right. I believe that shouldn't be different than
the industry meetup arrangement. If we have a dev meetup
that's mostly presentation-style that might be difficult
on the translators. Maybe we have 1 or 2 presentations
where we can give them to the translators in advance or
have those that can speak the language be the speakers.
Rossen: It's a valid point. It's a prerequisite.
Rossen: Any other feedback?
Rossen: I'll take the silence as no feedback.
Rossen: Can we try and schedule for the first day of CSS meetings?
17th I think.
Rossen: Any different or better suggestions?
Rossen: Second day is the industry meetup. Other option is do it
the evening before the first F2F meeting.
Rossen: I'm not seeing much engagement. We'll say tentatively
proceeding day or first day of F2F meeting.
Rossen: We'll go from there.
Clarify Segment Break Transformation Rules when multiple segment
breaks involve
----------------------------------------------------------------
Rossen: Do we need fantasai?
Multicol
========
Specification should define interaction between 'column-span' and
'column-fill'
------------------------------------------------------------------
Rossen: Who wants this?
dbaron: I filed it, though I didn't do the agenda+.
dbaron: I think...the more interesting is #4
<jensimmons> btw there’s a very annoying bug in multicolumn that I
was running into again yesterday. Here’s a demo.
http://codepen.io/jensimmons/pen/QpdyMr The list
styling is missing from any column but the first one
in Safari and Chrome. Likely an old webkit bug (from
before the fork). It would be good to fix this.
How do elements between column-span and its multicol ancestor appear
around the span
--------------------------------------------------------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/1072
dbaron: A little bit of background. When Gecko looked at
unprefixing we got feedback that we shouldn't unprefix
without support for column-span.
dbaron: That's why we're not unprefixed. So we had an engineer
look at impl it and the spec didn't answer basic questions
about impl which is surprising to me as the spec is impl
in 3 other engines.
dbaron: Issue 1072 is about what happens with a column spanning
element that's not a child of the multicol.
dbaron: The spec doesn't say what happens to all the CSS
properties spec on those things when the column-span: all
splits them. It feels like a new version of block and
inline splitting, but more complicated since it's doing
both.
dbaron: I'm curious what people thought was supposed to happen.
florian made a comment, but I hadn't looked into what the
other implementations do.
Rossen: Our logic is what you just explained. We take into account
only first level children of the multicol for the purpose
of spanning.
dbaron: mmkay.
dbaron: I think that's more reasonable though some people say
headings are a few levels down.
Rossen: Right. I'm just describing our path.
dbaron: Yeah
Rossen: All the layout interactions for multicol happen on the
level of the multicol. Nothing propagates inside. We
didn't want another weird ancestor dependency.
dbaron: That makes a lot of sense to me.
* iank checks what happens in blink....
Rossen: So if the spec is unclear, I would be in favor of clearing
that part up so far as there's consensus around the WG.
iank: I have to check with Morton at Opera, but pending his
feedback I'm fine with simplifying it to direct decedents.
Rossen: Okay.
Rossen: Any other feedback?
Rossen: Should we record a resolution pending Morton's feedback,
waiting until next week to call it final?
<fantasai> needs a minute or two
<fantasai> I'm concerned about checking in on use cases
<fantasai> Do we really want to prevent e.g. 2nd level heading
from spanning if the author is using nested <section>
markup.
Rossen: The only thing before we can resolve, I see fantasai is
trying to get connected and she has something to bring up
Rossen: [reads]
Rossen: To restate her model: what we do for position elements and
propagate into their containing block for layouts. This is
another model we can adopt. As an implementor I wouldn't
be terribly excited about it. It's another indirect layout
dependency.
Rossen: It adds a large bit of complexity for a narrow use case.
<fantasai> If we were to define that case to work, would trigger
fragmentation rules
<fantasai> Spanning element would be effectively outside of its
container
<fantasai> But otherwise doesn't seem to crazy to make that work
within the same block formatting context
Rossen: To end quoting fantasai [reads]
[fantasai's audio connects]
fantasai: I would say the model would only work if you're in the
same BFC. If you just outside we don't span. I think
there are...it makes sense you might want to do that
within some descendants because they want to do section
level markup.
fantasai: In terms of how to impl I think when you encounter
spanning element you trigger a page break and layout as
a child of the multicol and then continue after.
fantasai: So everything would break and the spanning element would
not be inside.
dbaron: I think that produces unacceptable results where
backgrounds aren't behind descendants and confuses the
a11y rules.
fantasai: I can't say you'd get a reasonable result if you do
anything other than that. You have a blue section with
yellow text and your element spans outside there's no
way to wrap the blue
dbaron: You can say all the elements it breaks have blocks like
the block and inline splitting.
astearns: And that's what Morton's comment refers to. I read his
comment that he does allow it in blink.
dbaron: I agree it does. But I think he said he doesn't put the
background behind which I think is the wrong way to do it
if we allow. It's maybe simpler to impl.
<fantasai> dbaron, I think you *want* not having the background
behind the spanning element
fantasai: Another thing is one major use case for spanning is
images that are likely to be embedded in a section.
jensimmons: I can see wanting to see images or figures to span.
There could be complexity.
fantasai: Anything inside the spanning could be okay. The case is
using section elements. It's elements between you and
the element establishing multicol. Anything in that
section could not break out and span.
Rossen: How many impl are unprefixed? We are.
Rossen: Who else?
<iank> we are
Rossen: Webkit and Blink?
iank: Blink is.
Rossen: Webkit?
myles: I have to look.
Rossen: I'm curious to see if we have interop and if we do I'd
like to know what the compat breakage would look like.
Column-span is a fairly common behavior for multicol. I
don't want to start breaking a REC spec.
<fantasai> It's a CR, not a REC
Rossen: We could continue discussion on github. I don't feel we're
ready to resolve. To summarize: there was some impl that
were leaning toward the behavior Edge has, to only
consider first level children. fantasai brought up some
additional points. I think we need to discuss more once
iank and Blink can catch up with Morton.
Rossen: Or dbaron did you want a resolution?
dbaron: Github is fine.
myles: Our CSS is unprefixed.
Rossen: Do you consider anything other than first level children?
myles: No idea.
Rossen: Let's take discussion to github. We'll need to figure out
behavior and go from there.
dbaron: We could get some test written to cover these.
<iank> example:
<iank> https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0A%23multi%20%7B%20columns%3A%202%3B%20%20width%3A%20300px%3B%20%7D%0A%23spanner%20%7B%20column-span%3A%20all%3B%20height%3A%2020px%3B%20background%3A%20green%3B%20%7D%0A%3C%2Fstyle%3E%0A%3Cdiv%20id%3Dmulti%3E%0A%20%20text%20text%20text%20text%20text%20text%20text%20text%20text%20text%20text%20text%20text%20text%20text%20text%20text%0A%20%20%3Cdiv%3E%3Cdiv%20id%3Dspanner%3E%3C%2Fdiv%3E%3C%2Fdiv%3E%0A%20%20text%20text%20text%20text%20text%20text%20text%20text%20text%20text%0A%3C%2Fdiv%3E
<iank> https://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4924
astearns: By my reading of item #3 it's basically the same issue
as #4.
dbaron: It's a bit different, but I think we should defer all of
multicol.
astearns: All or just column span?
dbaron: All 4 are column span.
Clarify Segment Break Transformation Rules when multiple segment
breaks involve
=================================================================
<astearns> https://github.com/w3c/csswg-drafts/issues/836
fantasai: xidorn pointed out we don't merge segment breaks. We
should be removing segment breaks together so when they
transform they do so as a unit.
fantasai: I checked in a fix to do that, I wanted to check if
anyone wanted to look more closely.
astearns: Any concerns about this fix?
<astearns> https://github.com/w3c/csswg-drafts/commit/82deba78668e732ad15c084391ffe1910ff3e3d0
astearns: The actual change is ^
astearns: This is a heads up to look and if you have issues please
re-open the issue. Otherwise we'll assume it's good.
It is unclear when offsetX/Y are calculated
===========================================
<astearns> https://github.com/w3c/csswg-drafts/issues/1070
astearns: fantasai you did the agenda+ but there's been discussion
afterwards.
fantasai: Question in my mind is...there was discussion as to
what's easier to impl or makes sense we should get a
resolution, but it's fine to defer if it needs more
discussion.
astearns: Looks like discussion is going well on github. So let's
keep going on there until it comes toward a conclusion.
Unless anyone on the call has an opinion?
What are "form controls"?
=========================
<astearns> https://github.com/w3c/csswg-drafts/issues/1024
astearns: I think this is a "do we still need to do anything" Do
we still need to define form controls after the other
resolutions or do we have something workable to use?
fantasai: I think we decided we're making all form controls behave
as display:none. We need a definition, but I think we
can point at HTML and ask them to define it or put some
hand wavy discussion in the spec,
<astearns> html issue: https://github.com/whatwg/html/issues/2359
astearns: Here's the HTML issue. There's discussion. I don't see
they have anything we can refer to yet.
astearns: But I'm happy to close our issue in favor of that one.
Variation Selection of Colorful (Emoji) or Monochrome Glyphs
============================================================
<myles> https://github.com/w3c/csswg-drafts/issues/352
<astearns> specific proposal in this comment:
https://github.com/w3c/csswg-drafts/issues/352#issuecomment-284923814
myles: To give background: Emoji have 2 ways to draw them
conceptually. From any emoji you can draw in emoji style (
colorful) or text.
myles: The way this is impl inside fonts there is a unicode code
point you can put after the emoji. This one attaches to the
previous emoji and now you have the information you need to
draw.
myles: This is impl on some platforms that the addition of this
causes you to perform font fallback differently.
myles: If you have the one to say draw in emoji it will cause us
to fallback to a font that can handle color.
myles: Being able to control emoji or text style is something
we've had requests for. Currently a web author would have
to add variations at every code point.
myles: This issue proposes a new property which is
font-presentation: auto|text|emoji
myles: This property could affect font fallback. So if you set it
on elements the font fallback for come character in the
element you might select a color font.
myles: I was hoping to know if people had thoughts.
fantasai: Do normal variation selections on ideographic character
affect font fallback?
myles: They don't. There's many variation selectors...There's 2
that are special, emoji and text. Those two require
modifications to font fallback. All the others should not.
They're used for things like CJK where you have a variation
to a glyph where it's not required.
fantasai: Yeah. I was curious. Either way I think we should make a
decision if it affects font fallback based on what they
want. It makes sense to affect fallback because if you
specify this it means you care.
fantasai: I think the decision on if it affects fallback in this
case is different then the CJK case. I think the
proposal makes sense to me overall.
fantasai: Are there characters effected that are not emoji?
myles: No. The set of characters that allow the variation, there's
a list of them in unicode. And every one in that table has
both text and emoji.
astearns: So if this font-presentation is set to emoji and applies
to syntax outside that table it doesn't affect font
fallback?
myles: Yeah.
Vlad: What selectors do we have now that would control between
color and monochrome? I could easily see the more universal
where if there's monochrome or color you would want that
control. Would this allow control to switch between
monochrome and color render for non-emoji?
myles: I thought this would interact with cmap table.
Vlad: In the color font you have the cmap table where it resolves
character to glyph index. But you also have opportunity to
resolve between monochome and color. I don't know if that's
possible today.
myles: I'm not...I don't have a strong opinion. It sounds
reasonable to allow a UA to do that. It shouldn't be forced
but it sounds like it should be allowed.
Vlad: Do you see this new selector would be generic enough to
switch between versions of monochrome and color glyphs? I
just don't think it's reasonable to only use it for emoji if
you have similar condition for other glyphs.
myles: That's true. I'm a little scared because new tables can be
added all the time. Trying to overload the meaning of
this...I guess I feel this proposal is just for the concept
of variation selectors. If we want to extend maybe we can,
but I think that's secondary.
Vlad: Okay. I think that may be an additional discussion. Maybe an
issue on github where we can discuss the details.
astearns: I'd like to resolve this for this purpose and have a new
issue on if it can be extended.
Vlad: Even for this purpose...you can have one font with both
monochrome and color and a different font with only
monochrome. One case you'd want to switch between variations
and the other you'd want font fallback.
myles: In order for what's proposed it must select font fallback.
Your argument is that this should not be used for the use
case.
fantasai: I think the proposal is good. I think we should add it
to the spec, have myles sketch the details, and then
file issues. Overall I think it's a good plan.
Vlad: Okay. I don't mind looking at the specifics.
astearns: proposal: add font-presentation to the spec and have it
affect font fallback. Obj?
* fantasai thinks the name could probably use some improvement,
but is in favor of adding to the spec and working that
out later :)
<myles> fantasai: yeah, feel free to help me come up with a better
one. i just chose presentation cause that's what Unicode
calls it
<myles> but i'm happy to change it to something better
<fantasai> myles, don't have a better suggestion atm. Mark an
issue into the spec, link it to a GitHub issue, and
let's see if we can get any brainstorming :)
<myles> fantasai: 👍
RESOLVED: add font-presentation to the spec and have it affect
font fallback.
astearns: That's the end of the agenda. Anything extra?
Housekeeping Reminders
======================
astearns: Housekeeping reminder: we have Tokyo F2F coming up. Plan
your trips and add yourself to the wiki. Houdini is the
day before.
dbaron: Another housekeeping reminder: summertime in the US starts
this weekend. Our telecon is pinned to the US. So everyone
not in the US the call will be one hour EARLIER next week.
This is the dangerous one where if you make a mistake you
miss the telecon.
<glazou> +1 to what dbaron just said
astearns: This is next week and the week after?
dbaron: For Europeans it's for 2 weeks. For people that don't
observe summer time it's until November.
astearns: So be aware that meeting times will be odd for the next
two weeks+.
astearns: I think we're done. Thanks everybody!
Received on Thursday, 9 March 2017 00:55:51 UTC