- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 1 Sep 2017 08:49:51 -0400
- 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.
=========================================
CSS Shadow Parts
----------------
- TabAtkins presented his proposal for a spec called Shadow Parts
(available here: https://tabatkins.github.io/specs/css-shadow-parts/ )
- RESOLVED: Move CSS Shadow Parts to WG ED space.
Review of TTML
--------------
- Nigel joined the group to talk over the request for review on
TTML2 and to talk over the areas where TTML and CSS overlap:
https://www.w3.org/wiki/TTML/CSSRequirements
- The CSSWG will meet with TTML during TPAC.
CSS Break: Consider adding clone-most-nested
---------------------------------------------
- After discussing the use case more, the group agreed it was a
good thing to solve, but the exact details of the use case
requirements were unclear, and TTML needs to clarify.
Proposal: https://github.com/w3c/csswg-drafts/issues/1633
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/paris-2017#topics
Present:
Rachel Andrew, Invited Expert
Rossen Atanassov, Microsoft
Tab Atkins, Google
Brian Birtles, Mozilla
Bert Bos, W3C
Tantek Çelik, Mozilla
Dave Cramer, Hachette Livre
Emil A Eklund, Google
Elika Etemad, Invited Expert
Rob Flack, Google
Daniel Glazman, Disruptive Innovations
Koji Ishii, Google
Dean Jackson, Apple
Ian Kilpatrick, Google
Peter Linss, Invited Expert
Myles C. Maxfield, Apple
Jack Moffitt, Mozilla
Naina Raisinghani, Google
Francois REMY, Microsoft
Melanie Richards, Microsoft
Florian Rivoal, Vivliostyle
Simon Sapin, Mozilla
Till Schneidereit, Mozilla
Geoffrey Sneddon, Invited Expert
Alan Stearns, Adobe
Surma, Google
Jet Villegas, Mozilla
Greg Whitworth, Microsoft
Regrets:
Jihye Hong, LG Electronics
Dael Jackson, Invited Expert
Chris Lilley, W3C
Simon Pieters, Opera
Hiroshi Sakakibara, Beyond Perspective Solutions
Lea Verou, Invited Expert
Scribe: tantek
CSS Shadow Parts
----------------
TabAtkins: (summarizes previous work)
TabAtkins: (shows https://tabatkins.github.io/specs/css-shadow-parts/ )
TabAtkins: Deep combinator was too powerful.
TabAtkins: Works for transferring single values-
TabAtkins: terrible for outside of that.
TabAtkins: In particular one element, e.g. heading part of your
warning message
TabAtkins: you have to expose a lot of custom properties
TabAtkins: theoretically all 300+ CSS props
TabAtkins: then xfer each one by one.
TabAtkins: Worse if you try to style pseudos
TabAtkins: huge combinatorial problem
TabAtkins: variables fall down quickly if you want to allow ...
TabAtkins: This proposal (https://tabatkins.github.io/specs/css-shadow-parts/)
that Shane and I wrote up
TabAtkins: for letting authors expose an entire element from their
shadow dom to other parts of the page.
TabAtkins: This would go into the dom spec
TabAtkins: we'd add some pieces.
TabAtkins: (shows feature in spec)
TabAtkins: Important part in CSS, two new pseudo-elements that
appear on any shadow host
TabAtkins: ::part() and ::theme()
TabAtkins: (summarizes proposal from link)
TabAtkins: Do allow some pseudo-classes on them
TabAtkins: but can't depend on anything to do with the DOM tree,
e.g. no ::part():first-child.
TabAtkins: One aspect of vars that is available to preserve is
that they do allow you to target things further down in
the tree
TabAtkins: useful in practice for authors right now.
TabAtkins: ::part() is one level, ::theme() is what this component
chooses to expose plus what all its subcomponents
choose to expose.
TabAtkins: In general ::part is better to do, helps with
encapsulation. But ::theme helps you do what variables
do.
TabAtkins: (shows example of a custom button)
TabAtkins: There are some suggestions for more features, e.g.
elements may want to censor
TabAtkins: e.g. give theme ability to exclude certain elements
from being exposed.
TabAtkins: This is ready for FPWD.
fantasai: ED?
TabAtkins: Comments?
TabAtkins: I'd like to pursue this in the public repo, right now
it is just in my personal github
TabAtkins: at the very least as an ED.
TabAtkins: Also ready for FPWD if group is ready for it.
glazou: Part is always exposed?
glazou: But you need to expose it outside the shadow DOM?
TabAtkins: Yes that is exactly the point.
glazou: I understand the point, I'm puzzled that we need to add an
attribute for that.
glazou: Part serves same purpose as class.
TabAtkins: But we don't want to expose arbitrary class(es)
astearns: We don't want to expose arbitrary class(es), why don't
we say component say these classes that are allowed to
style
astearns: and then the selectors styling in the component could
look like the selectors outside.
glazou: I have another suggestion, give a list of attribute
selectors, name and value
<glazou> [class|="foo"], [part]
plinss: but then you're ...
glazou: unless ...
plinss: what's in the ... is not just the ... not just in the
shadow tree, but something that is deliberately exposed
plinss: and then propagate these things up to the root
plinss: this is basically what I wanted but just wanted pseudos...
plinss: Can we do structure?
TabAtkins: No.
plinss: It flattens the entire shadow tree?
TabAtkins: Yes, because exposing the entire structure exposes too
many details
plinss: ... so I'm fine with that.
fantasai: I don't understand the use case for theme.
TabAtkins: vars right now can be used to target an arbitrary depth
down the shadow tree
TabAtkins: same thing that theme does.
TabAtkins: Part gives you only one level.
TabAtkins: Not currently a way to block theme like vars.
fantasai: Why?
TabAtkins: e.g. to theme custom buttons regardless of where they
are
TabAtkins: just by setting vars.
fantasai: Second question is ...
fantasai: just wondering if ryosuke has read your draft.
TabAtkins: He has but doesn't like theme.
fremy: Why can we just not create a namespace of classes that we
expose?
fremy: Instead of a new attribute
fremy: classes that start with ...
TabAtkins: Possible, but class has traditionally be treated as a
user (author) space thing, and we don't introspect on
the internals of class name.
fremy: It seems like a bad idea to have to use part and class.
TabAtkins: Class for internal styling, use part for how external
world can see you.
dbaron: I'd be in favor of this moving to ED space.
dbaron: The structure thing that plinss brought up could use some
more examination.
dbaron: I can imagine different things that all expose the same
piece instead
dbaron: and you'd want to expose that instead of having to mirror
the names.
TabAtkins: Yes that is possible, trying to hit the minimal case
right now.
TabAtkins: Can carefully expose more structure.
plinss: Stack of custom elements?
TabAtkins: Each pseudo can expose its parts
dbaron: no particular reason author needs to know your buttons are
x-button vs button.
dbaron: One other point, I find the part and theme names confusing
TabAtkins: Which part? (lol)
dbaron: The fact that they are very similar, but have very
different names that don't tie them together.
TabAtkins: like because "theme" doesn't indicate it is like "part"?
<gregwhitworth> maybe ::parts()
dauwhe: I certainly support ED on this.
dauwhe: We have this problem in the ebook world
dauwhe: publishers creating styles
dauwhe: need users to override parts of it but not all.
dauwhe: We run into lots of problems with the cascade
dauwhe: trying to allow user to control P but not H.
TabAtkins: ... inside shadow vs outside shadow
(explains how to solve it)
Rossen: So I heard a few in favor of moving to ED to begin with
<fantasai> +1 to ED
Bert: I have a question.
Bert: Not sure I understand how you expose part.
Bert: Do you need pseudo at all?
TabAtkins: The button already has children, the may or may not be
exposed.
TabAtkins: You can take the actual dom children and pull them into
the shadow dom
TabAtkins: and two, letting you use the descendant combinator
implies you can use child combinator.
Bert: Not at same level.
TabAtkins: I would find that a little bit ...
TabAtkins: big one is that child and descendant combinators
already match the actual children.
Bert: namespace issue ok
TabAtkins: Pseudo gives you a clear context about what you're
matching.
<TabAtkins> Because of how the cascade works for rules originating
inside the shadow vs outside the shadow, you can
prevent the outer page from manipulating particular
properties on an element by just setting them from
inside the shadow dom.
plinss: One thing I like about pseudo approach, in the ExtWeb
approach, you can use ... to explain pseudo ...
plinss: I can explain that that was a ... element all along.
TabAtkins: Our inputs are implemented with shadow dom.
TabAtkins: Any objection to ED space?
Rossen: Does anyone?
Rossen: Doesn't seem like it. go ahead and move it.
RESOLVED: Move CSS Shadow Parts to WG ED space.
Rossen: ... ?
TabAtkins: The part attr will go into the DOM spec; the
pseudo-elements will go into the Scoping spec.
Review of TTML
--------------
Scribe: fantasai
Rossen: We have Nigel joining us on the call.
Rossen: Asked a few weeks ago to review TTML current WD.
<Rossen> https://lists.w3.org/Archives/Public/www-style/2017Jul/0007.html
Rossen: Some back and forth over email.
Rossen: Provided feedback, first time by dbaron, 2nd time by
Florian.
<tantek> See also dbaron's review
https://lists.w3.org/Archives/Public/www-style/2016Nov/0106.html
Florian: Feedback I wrote wasn't sent to TTML, sent to us to
decide if it was my position our position.
Florian: We haven't resolved on that officially.
Rossen: Would you want to summarize?
Florian: Roughly very similar to what dbaron said half a year
earlier.
Florian: Didn't review anything other than style and layout, but
for this part.
Florian: You have a system that is very similar to CSS, but isn't
CSS
Florian: Some attributes take the same syntax, but have different
semantics
Florian: Some take a superset, some take a subset, some overlap in
both ways
Florian: We could do a mapping, but different semantics is a
problem
Florian: E.g. 'line-height' defines the height of the line box in
CSS, in your case it defines the spacing between
baselines which is similar but not quite the same
Florian: Other times you and we solved the same problem in
parallel and came up with a different solution
Florian: e.g. your alignment properties are different from ours.
Florian: You can't really map to CSS, you can try but because of
these differences, will come out wrong
Florian: Implementing TTML will be completely different from
implementing CSS
Florian: Browsers have a CSS engine
Florian: If not compatible with CSS, unlikely to work out
Florian: There's a rough mapping in an informative part, but it's
not really going to work.
Florian: I understand the history of starting from XSL:FO, but
that's dead for client-side on the Web.
Florian: Out of context, it might be a good technology, but in the
context of the Web it's hard to fit.
nigel: Fair summary
nigel: Interested in specifics of line height issue
nigel: One thing, you mentioned an informal document that brings
out correspondences to CSS
nigel: Here's a link
<nigel> -> https://www.w3.org/wiki/TTML/CSSRequirements
nigel: We did quite a bit of this analysis.
nigel: We used dbaron's and your feedback (which we found).
nigel: Absolutely right that the syntax is different.
nigel: For us, compatibility with previous versions is important;
breaking would be a problem for us
nigel: a lot of the target devices are not browsers
nigel: but there is a growing recognition that being able to
render with CSS would be a good idea.
nigel: So there has to be a syntactic mapping, but wrt semantic
mapping...
nigel: We discussed with TAG recently, and they had useful view
that we should describe the mapping into CSS for this to be
useful implemented.
nigel: Question of whether this mapping should be normative,
unsure how much real world difference it makes.
nigel: Other recommendation from TAG was that if there were
styling requirements
nigel: then it would be really helpful if there were CSS
equivalents.
nigel: If things that we need in subtitle / caption word aren't in
CSS, we ask CSSWG to add them
nigel: this makes it easier to implement with a CSS backing.
nigel: If we can get to any detail, even offline, want to know
e.g. differences in line height semantics.
myles: I guess, we've looked into this a bit and our findings
align with Florian's findings.
myles: Our conclusions are in line with Florian's conclusions.
myles: We would be hesitant to implement if not aligned with CSS.
(Myles represents Apple, works on WebKit)
Florian: Wasn't on TAG, don't know what they said
Florian: But rather than have you define things and us define
things in parallel
Florian: better to define in terms of CSS, and if something's
missing, then we add it.
Florian: Wrt subtle differences, determining how subtle secondary,
if they are normatively defined independently
Florian: then there will be differences, and even small
differences are problems in deployment.
Florian: Differences between different and broken are subjective.
Florian: If the syntax layer needs to be different, this is a
minor annoyance but fine
Florian: But in terms of semantics, don't redefine separately
what's already defined in CSS
Florian: file bugs against us to add things.
Florian: Could go through long list of details on every property
Florian: I took line-height as an example
Florian: but given you have normative prose, there are bound to be
differences.
nigel: I understand where you're coming from.
nigel: From TTML WG PoV, it's not always so obvious how to add
things to CSS
nigel: but also there is pressure to get a new version of TTML
out, and if we had to wait for CSS, wouldn't be able to
satisfy our community.
nigel: TTML2 could be seen as a req document, and align with CSS
later.
nigel: I've not heard any dissent from view that these reqs need
to be met.
nigel: So assuming there is a requirement, we do need to support
them in subtitles and captions world.
nigel: As soon as we have access to CSS definitions we can add
them back in.
nigel: There is time, actually
nigel: We're in WD at the moment, the review ends in September
nigel: we wouldn't be in CR until after TPAC.
nigel: If there is an opportunity to get some features specified
in CSS, could contribute to that in some way
nigel: then there is time to fill some of these gaps.
nigel: Most important ones that would be useful:
nigel: filling line gap
nigel: text-representation for ideographic scripts
nigel: ruby
nigel: fontShear
nigel: these would be useful
<Rossen> https://www.w3.org/wiki/TTML/CSSRequirements#disparity
<Rossen> https://www.w3.org/wiki/TTML/CSSRequirements
astearns: Not time to define new things in CSS, but time to review
list of places where you're unsure if there's
concordance.
astearns: I saw some things, e.g. where we do have the feature.
astearns: Would be nice to have semantics map, and syntax if
possible.
astearns: Would be good to have someone from group review list to
check for actual gap.
Florian: We have a bit of precedence with this, with EPUB
Florian: Where they couldn't quite wait for us.
Florian: This is overall not a story that ends very well.
Florian: Similarly to your situation, not all EPUB readers are
browsers, but kinda.
Florian: When you ask to support things that are not CSS but kinda
it's problematic.
Florian: Originally they asked us for stuff, and if we didn't
deliver fast enough they tried to define their own thing
Florian: But realized that doesn't work, so now are planning to
just bug us to prioritize and fix things
Florian: Wrt differences we were discussing
Florian: I wonder if it's worth doing, if we don't go all the way
in.
Florian: If we can bring it to the point that browsers can
implement
Florian: Then it's worth it.
Florian: But if it's not possible to implement in browsers, then
making it less different is maybe not so useful.
nigel: wrt displaying in browsers, they do.
nigel: TTML has a profile IMSC
nigel: one of the implementations is a JS implementation with CSS.
nigel: Clearly there's a desire to present subtitles in browsers.
nigel: I imagine same would be true for TTML2.
nigel: Experience of editor of IMSC had with creating imsc.js was
that he had to work around limitations of CSS quite a bit
nigel: e.g. putting each character in its own span to tweak its
position.
nigel: Some easier things to fix, like box-decoration-break
nigel: possibly just understanding layout options in CSS better
would help.
nigel: As you guessed, ppl will want to map to browsers better
nigel: browsers natively doing is maybe ???
nigel: Making decision based on whether browsers want to natively
present TTML is maybe a step too far
nigel: just about whether to present TTML at all, e.g. using JS
libraries.
jet: It seems like we're a bit torn in that browser vendors see it
as obvious to render TTML using our existing layout engines
jet: but the consumers of TTML might want custom layout in the
future
jet: e.g. never render markup in front of a face, where browsers
wouldn't even know where to start.
jet: Need to innovate in ways beyond just render text in a fixed
location.
jet: Want to align on things like text rendering
jet: but polyfill things that we wouldn't know where to start
dealing with.
nigel: Avoiding faces is done by author positioning
nigel: but sounds really cool
nigel: Have a question to you,
nigel: TAG said it would really be good if CSS would support
requirements.
nigel: Is that something you concur with?
Rossen: So long as the feature requirements that are specific to
CSS come to us fit to overall model of what we're doing
Rossen: as long as they are coming as requests we will definitely
review and consider
Rossen: for those that don't, not much we can do.
Florian: For those already in the spec, you have a solution
Florian: But for us what would be most useful is not to tell us to
support the solution of the TTML group, but to take a
step back and tell us the use case.
Florian: Maybe the way you solved it is a perfect fit for CSS,
maybe it's not but another approach would work.
Florian: Question is does the thing you care about fit into CSS?
Florian: If so then maybe it will influence what we do in CSS,
either importing wholesale or adjusting the capabilities
otherwise
Florian: Having only the solution without understanding the use
case would not help very much.
nigel: One more thing to add... sounds like there are some actions
nigel: Whatever those actions are, we've set aside time at TPAC
nigel: best day for us would be Friday
nigel: set aside time to invite to join us
nigel: to hopefully come to some resolutions.
nigel: Will send a formal invitation.
nigel: Could also do Thursday if preferred.
Rossen: We have some requests pending for TPAC, I believe Thursday
is mostly gonna be for CSS Houdini meetings, so that's
likely to fill the day.
Rossen: Haven't settled on Thursday or Friday, so depends on that.
Rossen: Already have some a11y and few more groups that want to
meet with us.
Rossen: But definitely send an email.
CSS Break: Consider adding clone-most-nested
---------------------------------------------
Scribe: TabAtkins
github: https://github.com/w3c/csswg-drafts/issues/1633
fantasai: We had a request from Nigel to add a value for the
box-decoration-break property. Can you explain?
nigel: Imagine you're displaying subtitles, and for a11y you want
to put a high-contrast background behind the text. Not on
the whole <p>, just behind the lines.
nigel: You don't want the background to be tightly wrapped to the
text edges - you want it to extend slightly out for
readability.
nigel: But you cant predict the linebreaks.
nigel: That's okay right now with box-decoration-break: clone
nigel: But then what if you have a span in the middle of the text
with a different color background.
nigel: And the break falls in the middle of that other span.
nigel: You want the span's background to be what extends; you want
to use padding to display that.
nigel: So the most relevant background color to "extend" is from
the innermost element at the break, not the element that
sets box-decoration-break.
nigel: fantasai asked a good question.
nigel: Should it be "most nested" or "most nested thing that
*counts", paraphrasing.
fantasai: I think we have this problem generally with
fragmentation.
fantasai: At the break, you want to have a little bit of extra
padding with the background beneath it.
fantasai: It's possible that maybe we can solve this by just
saying "add this amount of padding at the break".
fantasai: Whether that solves this is, do you need borders too? Or
just backgrounds.
fantasai: Like a border around the inline that only closes if it's
the innermost nested border?
fantasai: Seems weird, I guess not.
nigel: I think for border-radius you want [...]?
fantasai: If both have border-radius; normally we'd just slice and
get the green and black backgrounds overlapping each
other on a clean break.
fantasai: If only the green gets a border-radius, you'll see the
black background peeking out from under the green.
fantasai: That's a problem.
<dbaron> a general 'break-padding' property sounds like it could
be useful...
<fantasai> dbaron, yeah, that's what I was thinking. But it
doesn't solve the border-radius case he was describing
<astearns> I think it would be helpful to have a diagram in
https://www.w3.org/TR/ttml2/#style-attribute-inlineAreaBreak
that showed a rendering using each value for cases
where there's a difference
Rossen: I think this is in conjunction with the line-padding
property in TTML, right?
nigel: Yeah.
Rossen: Box decoration and fragmentation, you're talking about
linebreaking, not general box breaking
TabAtkins: It can be about boxes too.
Rossen: Sure, but that's not his requirement.
Rossen: Also something we don't have in CSS is line-padding that
extends in every break.
nigel: Line padding was introduced to IMSC when border-radius
wasn't available in TTML; at that point the only styling
you could do was background-color and get a square box.
nigel: Now with border-radius it's gotten more complicated, and
probably need to extend it a little further than just the
line-padding semantic, to include the other background
effects (or things that otherwise affect the background).
nigel: Your point about targeting line areas specifically is well
made.
nigel: If there was a way to say "for each line in this <p>, apply
this styling" that would be really helpful, but that
doesn't seem to exist yet.
<Rossen> Here's nigel's example
https://github.com/w3c/imsc-tests/blob/master/imsc1/png/linePadding2/0.000000.png
fantasai: I think it would be relatively easy to describe a ::line
pseudo if the only things that work are background and
things on the line box like background.
fantasai: Once inheritance applies it's hard.
fantasai: We have this problem with ::first-line; it's a mess,
lots of bugs, spec isn't precise enough despite our
efforts.
fantasai: But if it's just about "background here, put a
border-radius on it", it's not too hard.
fantasai: Not high priority to do in browsers, but wouldn't be too
hard.
iank: We don't have an architecture that can support that (styling
lines individually). It's several years away.
Rossen: The existing model of line boxes in most impls, certainly
in Edge, is not easily expendable to support this. Not
impossible, but it would be quite hard.
Rossen: Though this is a valid use-case and feature.
fantasai: What's line-padding?
Rossen: Imagine you have a span - I posted one of Nigel's examples
(https://github.com/w3c/imsc-tests/blob/master/imsc1/png/linePadding2/0.000000.png
)
- that adds background to the current inline. And the span
breaks. You can put padding on the span - you'll get
padding at the start and end of the span. If it fits on
one line, great; the background will extend a little past
the text.
Rossen: But if the text breaks in the middle, you have some
padding on start of first fragment and end of last
fragment, but all other broken edges have no padding.
Rossen: line-padding feature adds padding to every break-edge.
Rossen: Basically to the linebox itself.
Rossen: If the linebox has background, it extends.
fantasai: The linebox is wider than that actually, but I get what
you're saying.
fantasai: That makes sense, and I see how adding border-radius
would be tricky.
nigel: Doing just the inline-padding isn't the only place we want
to do something with line areas.
nigel: Another feature, fill-line-gap, says "draw background areas
between lines".
nigel: Hard now, because character heights are UA-dependent.
nigel: So can't specify a padding-top/bottom that correctly fills
in the space between lines.
fantasai: Question I have - you have a line of text with some
line-spacing, say 1.5. You're seeing there's a
background under the text, and a .5em gap between the
lines.
fantasai: When asking to fill the linegap, you're filling that
.5em space, what happens at the top and the bottom? Do
you add .25em at each? So each line gets .25em of
background above and below? Or just between the lines?
nigel: At the moment we don't say.
fantasai: Ok, that's a really important question to answer if we
need to add this to CSS.
fantasai: Second question, if two lines have different lengths,
what happens?
nigel: Probably we take whatever answer is most convenient.
nigel: But as far as I know you can't set a padding value, because
you can't calculate it...
<nigel> https://github.com/w3c/csswg-drafts/issues/814
fantasai: We should specify how the content box is calculated.
TabAtkins: Why's it hard? Just the difference between font-size
and line-height, right?
fantasai: Not quite - the background area isn't the size of the
line height box of the inline that's used for layout.
The area around an inline - in 2.1 there were two ways
to calculate the area, based on font metrics, and impls
might do different things.
Rossen: This is going a bit off topic, can we bring it back to
box-decoration-break?
TabAtkins: So it sounds like box-decoration-break: inner-clone
badly solves border-radius issues, and limiting it to
just background is better solved with a break-padding
property?
<fantasai> break-padding also causes problems with border-radius
fantasai: So I think those are the main two request from Nigel,
this and figuring out the fill-the-gaps issue.
fantasai: Which I think is best done by making impls
interoperable, then just using padding on the element.
fantasai: If we have a consistent box height, then having a
line-height of 1.5 and a padding on inline of .25em
above and below *should* fix the gap; if it doesn't, we
should fix that.
fantasai: And for the other issue of cloning spaces - it seems the
solution you're proposing doesn't actually solve the
problem.
fantasai: It's not just "clone most nested"; if there is
border-radius involved, you want to copy that innermost
border-radius all the way up, so the lower backgrounds
don't show up underneath the top-most's border-radius.
Rossen: So yeah, the feature request is something we'll work on,
probably as part of Break. We'll go from there!
Received on Friday, 1 September 2017 12:50:50 UTC