- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 30 Jan 2019 19:52:30 -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.
=========================================
CSS Text/CSS Sizing
-------------------
- Progress is being made on Issue #3440 (When to/not to include
preserved trailing spaces). fantasai needs some more
clarification on comments from xidorn and will then put together
a proposal for working group review.
CSS Pseudo Elements
-------------------
- Originally the pseudo element object hung off the window to allow
for future use in multiple element views. However many other
decisions made by the group have made multiple element views
hard anyway, so using element will not make it any harder in the
future and will be clear to authors now.
- RESOLVED: Add Element.pseudo(type) (Issue #3541)
- RESOLVED: Specify the current behavior and use the currentColor
name (Issue #2850)
- RESOLVED: Specify stroke-color and fill-color are accepted in
highlight styles (Issue #2362)
- RESOLVED: Add stroke-width to the set of properties (Issue #2362)
- There is a desire to create a standard set of principles for the
list of highlight properties instead of evaluating properties
one by one, however there's also a need to make sure these can
fully replace the prefixed properties.
- fantasai is looking for feedback on issue #3540 (Mark
unimplemented CSSPseudoElement features at-risk) prior to next
week's call
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2019Jan/0014.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Amelia Bellamy-Royds
Oriol Brufau
Benjamin De Cock
Elika Etemad
Tony Graham
Dael Jackson
Chris Lilley
Peter Linss
Melanie Richards
Florian Rivoal
Alan Stearns
Lea Verou
Greg Whitworth
Regrets:
Tantek Çelik
Jen Simmons
Scribe: dael
CSS Text/CSS Sizing
===================
When to/not to include preserved trailing spaces
------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3440
Rossen: There's a proposal put forward and discussion on the issue.
Who wants to summarize?
Rossen: Do we have anyone from the topic? fantasai, florian, koji?
florian: I'm here, but was hoping to participate rather than lead
fantasai: I'm here, but I want more clarification from xidorn before
we do this one
Rossen: Is xidorn on?
Rossen: This one is a rather old topic that was kicked from call to
call
fantasai: With xidorn comments I think we have an idea what we can
start to do. I want to clarify and get a solid proposal
before brining to WG
Rossen: His last comment he said it seems to match his understanding
in reply to your post yesterday
Rossen: There was some acknowledgment. If we should continue working
in github that's fine. Prefer next week?
fantasai: Yeah, I want clarity on other comments and put together a
proposal
florian: fantasai in github can you clarify your last comment?
fantasai: Okay
CSS Pseudo Elements
===================
Decide between Element.pseudo(type) and
window.getPseudoElements(elem,type)
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3541
Rossen: fantasai can you summarize?
fantasai: Two proposals for how to get the pseudo element object.
One was a .pseudo function on Element and the other way
window.getPseudoElements
fantasai: They were in different specs, never discussed which we
wanted though one was dropped. I wanted to know which
should go in pseudo element spec
gregwhitworth: I like heycam proposal that hanging it off the
element makes sense but passing the domstring
fantasai: I thought that's what it was, but sure
TabAtkins: I was also confused by heycam. It's element.pseudo()
taking a type
gregwhitworth: Okay
Rossen: Title of the topic is element.pseudo(type)
Rossen: I think heycam is more or less a summary of that and making
a case for it.
Rossen: Is there a reason why we couldn't want Element.pseudo(type)?
Rossen: I know we have gCS hanging off the window
dbaron: I think one historic reason is people envisioned multiple
presentations of same document but we've abandoned that.
Given that hang off element makes sense. It's simpler
Rossen: To reiterate, if you have multiple presentations where we
resolve a MQ 2 ways due to view- one is small and the other
is large for example- based on this you might cascade styles
differently so in one case you have a pseudo and the other
not
dbaron: That's what I'm guessing it was
Rossen: This is far fetched even today
florian: Even more than it used to be
dbaron: Early API designs envisioned you might use a single doc
object in 2 presentations. That's the thing we've admitted
we're not going to do
TabAtkins: Yeah
Rossen: I totally buy the historic reasoning on this
Rossen: If we already have a decision I don't know where it's
recorded that we're not pursuing the multiple view. I don't
think there's much choice here besides hanging off element
fantasai: Are there places we've locked into not having multiple
presentations?
dbaron: Element offsetWidth and offsetTop, those kind of things
locked us in well
Rossen: Even if we get to a point where we have to disambiguate...If
there was a case where we need to support multiple views you
should be able to get element somehow. Provided there's an
api to return the element for a given view, hanging off the
element is still valid. Hiding the view information and give
all the elements and you figure out which is which is worse
ergonomics for such API
plinss: I was an original proponent for multi view and idea was it's
literally the same element so there's no different version
per element. But I do accept it's way late in the life of
the web to change that and we have many APIs presuming one
view. I'm not thrilled about adding more APIs that lock us
in if we ever want to fix. But if we're dealing with
functions you can add an argument for an extra view and if
it's not passed you get default. We can work around
TabAtkins: Without considering this issue typedOM added style based
elements as well. View will have to bend around reality
if they ever happen.
Rossen: Back to topic at hand, any reason to not go with
Element.pseudo(type) ?
<gregwhitworth> That sounds like consensus to me
Rossen: Given all the arguments to how we got to where we are, any
objections to resolve to add Element.pseudo(type)?
RESOLVED: Add Element.pseudo(type)
How should a selected spelling error be painted?
------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2850#issuecomment-454870849
Rossen: It's a level 4 question
fantasai: I think this was about defining currentColor to represent
color of the previous layer. You have the document which
has colors for text and then spelling error and the
selection layered on top. Proposal was use currentColor
keyword to use the color. This seemed a neat way to
represent that concept
fantasai: Given the way inheritance is working in the ::selection
tree
florian: Model makes sense to me. Concept of layers- is that
abstract way to describe or do implementations work like
that?
fantasai: Implementations- I don't know how they work, selection is
only thing implement. Selection is painted over rest of
doc. Text that specifies how things is painted say it's
painted over, but it's really in replacement of original
text. If each pseudo element specifies a color, only last
will paint the text
fantasai: That's a separate question on how things are painted. This
is can we use currentColor to be the color I would
otherwise be or do I need a new keyword?
<Rossen> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/highlight/explainer.md
Rossen: There was an explainer that I was told would be proposed and
discussed soon ^
<dbaron> I'm a little worried this might be too clever...
Rossen: You may or may not have gone through it. I'm raising
awareness of something discussed in context of editing
Rossen: This is being worked on more actively and there is some
interaction with CSS for styling and handling of overlays
and colors.
Rossen: I was a little involved in the beginning so this proposal is
at least in a sane state it's in currently. If fantasai you
were looking for new words this could be a good primer to
see if we can extract something
fantasai: This is about defining new layers. In the section linked
from the explainer it's future custom pseudos. This isn't
new layers of highlights. This is how to represent in the
CSS properties model the color for a highlight that's
'don't give me a color'. I think most straightforward is
currentColor keyword.
fantasai: On color it says inherit from whatever I inherit from.
That would be the ::selection's parent. We need to a way
to say ::Selection doesn't have a color. We can do magic
and say you can't spec that, or we use this, or I invent a
new word
florian: Using currentColor makes sense. The thing from Rossen
doesn't change that
dbaron: This is only doing something special for currentColor on the
color property, not any other uses?
fantasai: Yeah because rest will refer to color property
dbaron: That makes it seem a little less scary
Rossen: Some support for currentColor
Rossen: Objections to specify the current behavior and use the
currentColor name?
RESOLVED: specify the current behavior and use the currentColor name
florian: I'm very interested in that explainer and I'll look into
this. It's great that you're doing it, it was on my to do
list
Rossen: Please do, this is getting traction.
Rossen: Discussion is on WCG or Editing TF
gregwhitworth: I think it's Editing TF
florian: I'll look there.
Rossen: If you're really interested I can connect you with folks on
our end. Shoot me an email.
Add stroke-color and stroke-width to the list of highlight properties
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2362#issuecomment-456253617
Rossen: AmeliaBR wrote a nice long overview. This is back to the WG
AmeliaBR: We talked about this previously. Question is about which
properties should be allowed on highlight pseudo elements
like selection
AmeliaBR: Discussion last week was disagreement about what factors
should disqualify a property from that set. We talked
about if something would trigger scrollbars, but feedback
from impl is there are performance impacts from recall
painting dirty boxes as styles change
AmeliaBR: First question is for the group- what should be allowed in
a highlight style and what should be disqualified. From
there we can look at specific properties
AmeliaBR: As far as implementations go, we're talking about
properties that are defined for SVG but want to extend to
all CSS style text. New fill and stroke spec is not
finalized
AmeliaBR: Another thing to remember is selecting styles on svg text
has lots of interop issues that go beyond this issue.
Solving this will not solve all svg text.
AmeliaBR: Non-svg text I don't believe there are any impl that
support fill and stroke as def in new spec. We do have
implementations of webkit prefixed version which has
different syntax and relationship between the properties.
AmeliaBR: At the end of my comment I said I'm not sure we can make a
decision on fill and stroke because they're not specified.
Should we address interop in properties that are impl? The
prefixed ones that don't have a spec. That's the question
worth asking
AmeliaBR: I outlined a bunch of questions without answers. Anyone
want to jump in with an opinion?
fantasai: smfr webkit has stroke and fill for selection?
smfr: Don't recall, but I think we could easily
fantasai: My inclination is for the spec in current state I would go
more restrictive for now and add more as requested. We
should do subset of what is impl plus spelling and grammar
error. That's why we have text decor and color
fantasai: Other properties in that list I don't know if they're
problematic. I'm happy to include if impl want to impl,
but if not there's no reason to put it in the spec unless
someone asks.
fantasai: I prefer color, background color, text decoration, and
whatever impl want to implement
fantasai: Then we can consider what else we want to allow. A core
set would be good
chris: I previously argued stroke-width, but I withdraw that. I
would like to see stroke and fill if impl interest. Makes
sense for fill
<dbaron> I think it's also worth trying to write down principles
that lead to the choices -- I think one of those principles
should be that anything that triggers scrollable overflow
probably shouldn't be included...
<AmeliaBR> https://codepen.io/AmeliaBR/pen/84c95eb4cd697f031f12487cbf239480
AmeliaBR: As far as what's impl, for SVG text all are supported I
think. Haven't tested. That's ^ the test for prefixed ones
AmeliaBR: Chrome and Edge support changing stroke-color and
stroke-width. Firefox does not. Don't have Safari
myles: Why is stroke-width hard?
chris: Causes additional computation so it's not just damaged pixel
repair.
smfr: Have to do layout to recalc visual overflow
chris: Also heycam from Mozilla said problematic
dbaron: Text decorations also require recomputing visual overflow
chris: True
smfr: We used to cheat, but they can project out
AmeliaBR: We're talking about selection because that's where
performance comes in. But we're using same set of
properties for all highlight pseudo classes so that also
means spelling & grammar error. If we restrict from
performance we might need to split the category so there's
flexibility for things like highlighting spelling errors
dbaron: I don't know we're far enough along on interop on this that
we're at that point
dbaron: I think it is worth trying to write down principles that
lead to these choices. I think anything that triggers
scrollable overflow should not be on this list. Discussing
ink
smfr: Things that trigger resource loads?
chris: Definitely disallowed. If you're bringing a network transfer
you don't want that
dbaron: Resource loads are async and you see something else in the
interim
florian: I don't think that's much of a problem. Triggering network
since async isn't
dbaron: Worry about background images is we have to define
background position for these
fantasai: Right, this is why I'm against background images. I think
stroke and fill images are pinned to geometry of element
box so wouldn't have same issue. We could do that for
backgrounds in theory
fantasai: For these images you don't want the to reset tiling on
every element. As you highlight and there's a span it
breaks the tiling. I don't know how you fix that and make
it consistent, but also give controls to author. For that
reason I think don't allow images. Unless geometry is
tagged to what's in document and not selection area, then
we can consider it
fantasai: I can come up with definition pegged to document element
or controllable by author, but not both.
smfr: I'm not sure original motivation of the issue was
daniel: For completeness. I didn't think this required a re-flow at
the time. I was filling out for completeness
AmeliaBR: It's worth discussing because we have impl of
webkit-text-stroke where some implementors support it.
There are different decisions out there. But that's not a
proposal in a spec. We need to discuss properties in the
spec and where should images be anchored when painting a
span
fantasai: That's specified in the spec now. We had to get it right
to make it useful. There's a property to control that
daniel: I must have missed something. What are we trying to decide
on?
fantasai: What is the list of properties for section 3.2. I'm happy
to include stroke-color and fill-color. That seems
straight forward
AmeliaBR: Only difficulty there is currently the shorthand stroke
property which is what's impl if you're switching color to
none it's not defined how it effects the stroke-color
longhand
fantasai: There is a definition in fill stroke spec. I think it
doesn't quite match SVG and we created a shorthand/
longhand relationship and we figured it was backwards
compat on existing content
fantasai: We're going with fill stroke spec, it doesn't matter if
it's shorthand it will reset the longhand. CSS expands and
looks at longhand, doesn't look at shorthands. If author
says stroke:blue it sets stroke-color:blue
AmeliaBR: So deciding which properties apply you can use stroke
shorthand in the ::selection rule and some parts will have
effect and some not?
fantasai: Yeah. We ignore properties not supported
AmeliaBR: I can't remember who said it, but we can start with the
more restricted set and expand it
AmeliaBR: I think it's reasonable to say stroke-color and fill-color
are acceptable in the highlight styles, implementation can
extend that to prefixed similar properties if they choose
daniel: For right now just exclude stroke-width?
AmeliaBR: Yes since that seems the controversial one
daniel: I'm fine with that
AmeliaBR: I do think it's probably a good longterm strategy to think
about and outline the underlying principles for that set
of highlight styles and what should be considered when
allowing/disallowing styles.
AmeliaBR: Not sure who wants that job
fantasai: Main principles is they can't effect layout, including
scrollable. Can't trigger resource load (for now). Can in
some cases trigger ink overflow because we've got text
decoration in there?
fantasai: Not sure how we want to deal with that
Rossen: Should we take that later on and try to resolve on this
issue?
Rossen: There was some agreement around having stroke-color and
fill-color participate in highlight styles
Rossen: Anything else we need before I call for objections?
dbaron: Summary of how our proposal disagrees with current impl?
Rossen: dbaron, we need to include it as part of the resolution? Or
capture it someone?
daniel: I have a patch for webkit and I'm implemented it for
stroke-color and fill-color in that patch.
Rossen: I just wanted to hear from dbaron
dbaron: I was saying I thought it was useful to understand what was
going to have to change as a result of the resolution
Rossen: Wasn't that it needed to be in the resolution, but it has to
be clear in the issue what the effect of this is to the
current impl
dbaron: Just like to know how far from current impl is the thing
we're going to resolve on
Rossen: Sounds like webkit is implementing. Blink?
AmeliaBR: I think the only issue is we do have impl that support the
width effect which we're not including.
AmeliaBR: If there's any ones that don't...FF is only one that
doesn't support stroke and fill color changes. But we're
talking a mix of prefixed property impl. We don't have
impl of stroke-color as spec.
fantasai: We want to make sure there's a path to change from prefix
to standard. If we have features in prefix we don't allow
in standard we have to revise
fantasai: We can say stroke-width is supported, but ink overflow may
not recalculate
florian: Not sure what effect of not recalc would be
fantasai: Glitchy rendering
dbaron: Typically glitchy rendering at future repaints
Rossen: Let's see if we can resolve
Rossen: Are we ready to resolve?
Rossen: Objections to specify stroke-color and fill-color are
accepted in highlight styles?
RESOLVED: Specify stroke-color and fill-color are accepted in
highlight styles
fantasai: What about stroke-width. If it's supported in prefixed
version, what do we do?
dbaron: Does stroke-width trigger scrollable or only ink?
AmeliaBR: Only ink
fantasai: Which implementation support webkit-stroke and fill for
selection?
AmeliaBR: Chrome and Edge. I assume safari, but I need someone to
confirm using the codepen
Rossen: We're certainly supporting
AmeliaBR: Edge doesn't support fill and stroke on SVG text, but FF
does
Rossen: Depends on version of SVG. In last one we released that
should be fixed
fantasai: If it's webkit prefix it's strong enough compat that we're
going to have support the functionality that maps to.
Otherwise we don't give authors ability to transition out
fantasai: We need to figure out what the functionality is and put it
in the list. What do other people think?
florian: Reasonable to me, but I'm not an implementor
<AmeliaBR> Correction to my last comment: FF doesn't support
selection fill & stroke on SVG text, either. Demo of
selections on SVG text:
https://codepen.io/AmeliaBR/pen/15e1dec9a9f1887c904adafca7589ff0?editors=1100
daniel: What's the question?
fantasai: First is if safari supports webkit prefixed stroke and
fill properties in selection. Second is if webkit prefixed
stroke-width is supported in selection, does that mean we
have to put it in the spec? If we all impl under a prefix
we should do it in the regular.
daniel: I'm looking
<leaverou> AmeliaBR: codepen seems to work in Safari (and has
somewhat better rendering in fact)
<AmeliaBR> HTML strokes and selection:
https://codepen.io/AmeliaBR/pen/84c95eb4cd697f031f12487cbf239480
daniel: We do support stroke-width
fantasai: Then we have to do it, regardless of it's a good idea
florian: I think so unless other browsers have a good reason
smfr: Might mean selection is slightly slow/choppy because we're
doing relayout.
fantasai: Or are you assuming you left space?
smfr: I'll have to check
fantasai: Adding stroke-width to spec or will browsers remove?
smfr: I don't think we'll remove.
dbaron: I'm fine with adding it.
Rossen: User PoV it's better behavior
Rossen: Objections to add stroke-width to the set of properties?
RESOLVED: Add stroke-width to the set of properties
Rossen: That's the top of the hour
Mark unimplemented CSSPseudoElement features at-risk
----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3540
fantasai: I have ^ open for having properties at-risk. I'd like to
invite feedback for next call
Rossen: Let's put it on agenda for next week and we'll give people a
week to review
Rossen: That's the end of today's call.
Rossen: We'll chat in a week.
Received on Thursday, 31 January 2019 00:53:33 UTC