- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 12 Sep 2018 20:34:54 -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.
=========================================
F2F
---
- Group members are asked to begin to populate the topics list for
the F2F.
Review HTML fieldset/legend spec
--------------------------------
- There were concerns that some portions of the spec were extending
functionality instead of just defining what is needed for
compat. This is an ideal topic to address during TPAC where
conversation can happen with members of the WHATWG. Until then
conversation will continue on github. (Issue #3094)
CSS2
----
- A separate issue will be created for CSS2.1 to create a term that
means "things that create a stacking context" and use that in
the spec where appropriate. Once this is done other specs can
use this term too. (Issue #2717)
CSS Contain/SVG
---------------
- RESOLVED: Containment should apply to outer SVG but nothing else
in SVG. (Issue #2987)
Filter Effects
--------------
- Chris Harrelson is added as a co-editor.
- There needs to be details on blending added to the document about
the visual effect of filter() on the document element. (Issue
#282)
- The behavior on the root element needs to be considered in
reference to the current behavior for iframes. (Issue #282)
CSSOM
-----
- RESOLVED: Disconnected elements don't have stylesheets (Issue
#3096)
- There is a use case to be able to set values on a disconnected
element through different APIs; plinss will investigate
current work on this use case and, if necessary, file an
issue.
CSS UI 4
--------
- RESOLVED: Add sentence "Authors should use pointer on links and
may use on other interactive elements" To UI4. (Issue
#1936)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2018Sep/0010.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Amelia Bellamy-Royds
Tantek Çelik
Emilio Cobos Álvarez
Dave Cramer
Benajmin De Cock
Elika Etemad
Simon Fraser
Chris Harrelson
Dael Jackson
Brad Kemper
Chris Lilley
Peter Linss
Thierry Michel
Manuel Rego Casasnovas
Melanie Richards
Florian Rivoal
Jen Simmons
Alan Stearns
Lea Verou
Sean Voisen
Zheng Xu
Fuqiao Xue
Regrets:
Tony Graham
Michael Miller
Scribe: dael
astearns: Let's start and let people straggle in
astearns: Any extra agenda items? I saw the break issue from
fantasai. Anything else?
New co-editor for Filter Effects
================================
astearns: We had a volunteer. I've talked to current editors.
They're fine. Chris H. is now a co-editor.
astearns: He's been active so hopefully will get things done.
FTF topics needed
=================
<astearns> https://wiki.csswg.org/planning/tpac-2018
astearns: We need agenda items. It is TPAC so there is less time.
Right now agenda in repo and in wiki is light. Please add
things.
fremy: I would love to discuss, you know the color filter proposal
from Apple, I haven't seen anything but I'd like to discuss.
I will add to wiki.
Review HTML fieldset/legend spec
================================
github: https://github.com/w3c/csswg-drafts/issues/3094
astearns: Looks like fantasai, Mats, and florian have commented in
issue.
astearns: If you were not aware, please take a look at the issue
astearns: If you have anything to contribute please do.
fremy: I didn't write anything on the issue and I haven't seen
fantasai comments. It's an amazing document. One concern is
in Edge webkit-appearance is cosmetic. We only support none.
I'm concerned to see it overriding display and other
essential properties to CSS.
fremy: If this is how it works in blink maybe, but I get this
impression this is not a thing it does. If this is not how it
works in blink I would not make it this way. I have not had a
chance to verify
florian: You can I need to be involved in parallel conversation.
There's a WHATWG standardization of the webkit property
where they're specing half of it. They're not super happy
with out proposal so we should talk
chrishtr: The blink engineers are opposed to adding more
functionality to prefix properties.
florian: Good to know, I agree
tantek: I also agree
<Rossen> +1
tantek: I don't think should be adding anything to appearance.
Adding functionality feels like pointing someone to a giant
mess.
florian: Total agreement, but there are 2 groups of people not
talking. Our side saying this and another group saying we
should standardize on webkit-appearance
Rossen: Upcoming F2F event coming up...good thing to talk about
there. I propose we keep looking and see if we can reach
agreement at TPAC
tantek: Sounds good to me
astearns: Add to wiki agenda?
Rossen: Definitely. We'll see if we can pull people from WHATWG
astearns: Other thing I noticed is there is a lot being discussed.
Threading is hard to follow. If anything can split to its
own issue please do
florian: It's tricky. It's a giant spec. Having 25 issues separate
is different then one list where everything is bad and
maybe we should reconsider.
astearns: Just pointing out as we find separate issues to solve we
should split
dbaron: Another point here: interop is bad and this spec is doing a
lot to improve it. Shouldn't ask for it to be thrown out. We
should question what is not needed for interop, but a bunch
of this is needed given web compat
florian: Taking as dependencies as things not defined and assuming
they work as they do in chrome. But they're not defined to
work that way. Until solve dependencies not clear the spec
works
<tantek> agreed with specing backcompat interop
<tantek> but disagreed with extending appearance OR
-webkit-appearance
<tantek> also disagreed with methodology of "just spec what Chrome
does"
fremy: Let's put this on TPAC agenda where we can work together and
talk once everyone has read the spec.
fantasai: I think 2 things to add. This is fieldset stuff but also
appearance property.
Rossen: For appearance property good to summarize the principles as
to what we'll take. Also making clear position on prefix
properties. Then go from there
<tantek> can we counterpropose deprecating FIELDSET and LEGEND?
<fantasai> tantek, no
<tantek> they are too much trouble for authors to bother trying to
use in any compat / interop way
<fantasai> tantek, they're perfectly fine HTML elements, we just
need to be able to a) make them not magic b) ideally
define the magic so it can be controlled and/or reused
<tantek> lol "perfectly fine HTML elements". ok agree to disagree
florian: And also people sync internally. Mozilla here and Mozilla
in compat spec seem to be different to take one example.
Talking internally would be nice
florian: Maybe TPAC is the place for that
astearns: Good for now? This will all go in the issue. Please
continue there before TPAC.
CSS2
====
Anything that creates a stacking context should sort in the positioned
descendants z-ordering list
----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2717#issuecomment-416803673
florian: I ran into this again while writing tests for Contain.
Summary: place in the spec that defines how things stack is
in css2.1 That bit of prose assumes only things that can
create stacking context are positioned elements so it's not
careful in phrasing. We've introduced other things so we
need to clarify if they stack same or not.
astearns: Stacking or painting?
florian: I'm not the expert on stacking and painting. I just want
this closed.
dbaron: I think most of answer in the issue. Someone needs to
propose edits to css2 with a new term, only one thing in
css2 uses the term, all other specs use that term.
chris: Not just css2. Also compositing defines more. I agree we
need clarity and changes, but all in css2 is not optimum.
dbaron: Things that should be in compositing, I agree. Term in css2
is 'thing that creates stacking context'. When css2 refers
to that term it says 'positioned elements' and it needs a
term so other specs can say this thing creates stacking
context so all things css2 says about stacking context
applies
chris: agree on that
florian: Given css2 has editors can we assign somebody?
tantek: File an issue and take it from there
fantasai: gsnedders is still looking for funding to work on css2 so
if you want him to be an effective editor give him some
money
astearns: I like idea of separate issue for css2 work on this
florian: Is it separate or just the same?
tantek: Yes, new issue
dbaron: There are edits for other specs. Separate issue makes sense
tantek: Fixing css2 is not signing up for all other specs
dbaron: And fixing css2 is complicated because you have to find all
the places to change for the new term
astearns: tantek can you create issue?
tantek: Not familiar. I'd ask current issue creator
dbaron: I'll file an issue
astearns: Anything more?
CSS Contain/SVG
===============
containment probably shouldn't apply to most SVG elements
----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2987
florian: Looking to raise attention and get a consensual answer.
Last issue on containment.
florian: Seemed dbaron and AmeliaBR were getting somewhere
chrishtr: Agree with dbaron on outer svg and nothing else
florian: Can we say that or need to be more specific?
dbaron: I think applying to outer SVG is pretty straight forward
astearns: Don't have AmeliaBR on the call. Shall we resolve on outer
SVG and ask Amelia?
chris: I think there's agreement on outer SVG. And it's what's
outside foreign object. TabAtkins is correct foreign object
establishes containing block but that's all it does.
Rossen: Equivalent of iframe basically
astearns: Proposal: containment should apply to outer SVG but
nothing else in SVG
astearns: Objections?
<chris> +1 to proposed resolution
RESOLVED: Containment should apply to outer SVG but nothing else in
SVG
astearns: I'll tag AmeliaBR for review
florian: I expect next call to have spec ready for CR. Thanks to
Gerard for the test suite
Filter Effects
==============
What is the visual effect of filter() on the document element?
--------------------------------------------------------------
github: https://github.com/w3c/fxtf-drafts/issues/282#issuecomment-418954332
<astearns> https://docs.google.com/document/d/1iN0LiaKPF3NZ2PCXD9gdWz1WmruhQIER8fJ_EYMm5YE/edit#
chrishtr: In previous WG meeting we discussed a couple of issues.
One was filter is a containing block for all elements
unless filter is on root. Reason for that is that it's
important for impl reason and rationality of platform for
it to be containing block. For root we want fixed to
behave correct
chrishtr: Second issue from smfr is that it's unclear what happens
when you put a filter and what happens to default white
backdrop
chrishtr: Discussed and had somewhat resolution similar to my
proposal, but needed use cases
chrishtr: There's 3 drawing layers for every doc. UA background
layer, canvas layer, root element layer. Blended for final
output
chrishtr: Want to make sure final is opaque. That's function of UA
background
Rossen: Always meaning per discretion of UA right?
chrishtr: Yes but don't think it's good idea
Rossen: If a UA wants blending enabled for, say, webview with
different composition other then opaque they should be
allowed. Saying background is always opaque is too strong
chrishtr: Would you agree it's important for dev not to be able to
cause blending there?
Rossen: Agree. Trying to distinguish that UA layer is controlled by
UA only. Opaque or not is per discretion of UA. Rest is
correct
chrishtr: Canvas layer is second. Purpose is a blending backdrop for
root element. Root element never has a background, always
stolen by canvas layer. That's as is. Other cases in HTML
where body gets its background stolen, but that's not
valid here
chrishtr: I want mixed blend mode and filter to apply to canvas
layer as it mixed blend and filter of root element and
canvas. Default color of canvas is white. If you don't
spec a color on html element canvas will be white
Rossen: Purpose of root element layer?
chrishtr: Content that's not the background but drawn into stacking
context. If you have a non-stacking div that's filtered in
Rossen: Makes sense
smfr: There was a step to propagate the UA background layer color to
the canvas. If you make canvas white you prevent UA from
transparency.
chrishtr: Default color of the canvas is white. Step 1 in the
algorithm is paint white into UA. Step 2 is put background
of root into canvas and if no background put white.
Guarantee of opaque comes from UA layer, not canvas. UA
layer forces the opaque, not canvas.
<dbaron> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Abody%20%7B%20background%3A%20aqua%20%7D%0A%3C%2Fstyle%3E%0A%3Ciframe%20srcdoc%3D%22%3Cdiv%20style%3Dbackground%3Ablue%3Bheight%3A30px%3E%3C%2Fdiv%3E%22%3E
dbaron: Question on your assumption. I put a test case in^
dbaron: Only tested FF, but iframe is transparent. Canvas does not
always have white background
chrishtr: I think the demo is in case of iframe...yeah...white
background is root frame but not sub frames. Right. And
iframes can be transparent. Right.
astearns: Should that be added to algorithm?
chrishtr: Yeah. White color is specific to root document. For
subframes it's transparent
chrishtr: Transparent iframe is legitimate
Rossen: There is no ua background layer in this case
chrishtr: There is eventually if you go up stacking
Rossen: Yes, for the frame itself
chrishtr: Right. And as dbaron said it doesn't draw white by
default. There is no infinite canvas for an iframe. That
needs to be thought through
chrishtr: Another comment on github from earlier today that asked
about clipping and masking order relative to filter and
blend. Compositing says filter first and then...there's an
order
<chris> yes, filter should be applied first.
<chris> so there are two separate clip stages?
chrishtr: Clipping is clip-path. I think it's important to be after
scrolling and overflow clip. Not masking or clip-path. Not
sure you can mask or clip-path root. Does anyone know?
chrishtr: It would apply to iframes but not root document
Rossen: Question was?
chrishtr: Masking for css clip to the root
chrishtr: Any way to cause clip on root element
chrishtr: Not sure it makes any sense for root of webpage or if UA
impl. Makes sense for an iframe
Rossen: Not sure
Rossen: Assume the use case for iframe I would question why that use
case doesn't apply to top level root
chrishtr: Reason would be iframes are in a larger drawing surface.
Rossen: Yes, unless root is inside an iframe. If use case applies to
doc in iframe, why when it's not.
fremy: Also if you're drawing on a glass screen I can imagine
websites wanting to be transparent and only white background
when they want it. I don't think there's a reason to think
iframe use case doesn't apply on root
chrishtr: Okay. I see.
Rossen: Where do we go? Your summary in the explainer is decent.
What's next?
chrishtr: Need to go into more detail about iframes and clipping/
masking. Then I think it'll be ready to come back
Rossen: This is great chrishtr. Thank you for putting this together.
CSSOM
=====
Need to agree on when LinkStyle.sheet gets updated in shadow trees
------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3096
emilio: cssom spec- the first spec when an element has a stylesheet
to html. Html doesn't specify so implementations did
different things. Gecko loads stylesheets in shadow trees.
Blink and webkit don't. I'm fine spec webkit and tying
loading a sheet to connected to a document. Makes shadowroot
stylesheets useless unless root is connected
emilio: Overall that makes sense. Example a style element.sheet is
also useless when style is not in doc.
astearns: Any concerns?
astearns: Makes sense to me.
emilio: Fine for me if we get a resolution I'll make edits
astearns: Proposal: Specify webkit/blink behavior for disconnected
shadowroots
emilio: Disconnected elements don't have stylesheets
astearns: This goes into html?
emilio: May need to. I'll discuss with html editors who should spec.
It's right now nowhere
astearns: Proposal: Disconnected elements don't have stylesheets
astearns: Objections?
Rossen: Disconnected elements have no stylesheets. If I make an
element through OM and make a style element the contents are
dropped?
emilio: Not dropped, but they're not associated.
<chris> what about style elements in the disconnected element? or
style attributes?
Rossen: Once I merge into main tree style sheet becomes
emilio: Yes, it's non-null
Rossen: There's a temporary style sheet not accessible through OM,
but it's created and retained for lifetime of subtree
Rossen: My assertion is there is an actual style sheet not
accessible through OM until element is merged into main tree
emilio: In gecko we have no style sheet. We parse when becomes
connected
Rossen: So you're saying if the stylesheet has external reference
you won't download until merged into tree
emilio: Right. That's the only thing HTML specs.
Rossen: Then I'm fine with the proposal. That answers my question
plinss: If you're creating a custom element you cannot manipulate
stylesheet through cssom until connected to document.
Rossen: That's current
emilio: You don't want to trigger loads. Rune said he's in
agreement. You can create stylesheet via inner html but
can't access via OM
Rossen: This is also related to our previous discussions about css
on disconnected trees. We'd give them stock style answers
was our conclusion so you don't trigger style computation.
That's why asked if we'd specify so downloads don't occur
until merge with main
plinss: If I create web component it cannot be made ready until
plugged into doc
Rossen: Correct
plinss: So I plug it in wait for style to download and parse, get a
flash of unstyled and then can manipulate.
Rossen: Not defending, but it is the current
plinss: Do we want this?
emilio: For small components you use inline styles and defer parsing
until you insert it.
Rossen: plinss perhaps is alluding to a separate issue that perhaps
we need a trigger that forces download when not connected.
plinss: At least parse and manipulate
Rossen: Yeah, this is a fair point.
<AmeliaBR> Remember, there is always <link rel="preload"
as="stylesheet" />, which you can add to the main
document to trigger a download without applying styles
just yet.
emilio: I think there are proposals in Google for document.tree to
allow. Wouldn't work like current style sheets. It's a
different API. But I think would address that use case
plinss: This is something I ran into in the last week or two. I want
to set values of custom property and I can't do it through
clean APIs. We should allow authors to manipulate style
sheets before connection
emilio: I think Google proposal addresses that. I don't think we
want current style and link to trigger downloads
plinss: Understood. Not proposing we change legacy. There is a use
case here.
emilio: File as a separate issue?
plinss: Fair enough.
astearns: plinss do you want to investigate current proposals and
file an issue if they're not enough?
plinss: Yes
<emilio> plinss: https://github.com/w3c/webcomponents/issues/468 is
what comes to mind
astearns: Proposal: Disconnected elements don't have stylesheets
astearns: Objections?
RESOLVED: Disconnected elements don't have stylesheets
CSS UI 4
========
Pointer Cursor wrangling
------------------------
github: https://github.com/w3c/csswg-drafts/issues/1936#issuecomment-419616109
florian: I think we have strong consensus that we do NOT want to
change UA requirements as to what they should do with
pointer cursor. But there is a fairly large contingent of
authors that think this is an author requirement and if you
do pointer on anything other then link it's invalid.
florian: Large part of web does things like pointer on button
florian: Is there room for a note or some wording to say UA do links
and links only, but authors can put it in other places
astearns: Last comment in issue TabAtkins suggested the sentence
"this value SHOULD be used on links, and CAN be used on
other interactive elements to indicate 'clickability'"
astearns: Is that sufficient? Acceptable?
florian: Replace can with may but yes
fremy: Not thrilled but don't want this thread open for 250000 years
and this coming back up all the time. Still wrong because
people have been misusing something and people pointed out
we're misusing it and now we have to change requirements
because we pointed that out
fremy: It doesn't make sense. Either we say it should be used and
change UA style sheet. Why say can if we don't do it? I have
mixed feelings. I won't object to a may. It's wrong, but I
won't object.
TabAtkins: That browsers can't change their behavior doesn't have
baring on how a lot of heavy usage leads to the value's
usage. Legacy constraint on browsers shouldn't constrain
us here. This is about matching author expectations.
People expect this to work in a particular way.
astearns: Objections to adding the proposed sentence "this value
SHOULD be used on links, and MAY be used on other
interactive elements to indicate 'clickability'" to UI 4
astearns: The pointer value SHOULD be used on links, and MAY be used
on other interactive elements to indicate 'clickability'
<tantek> +0 sounds ok, still reading issue
florian: Should this be "authors should use" instead of "should be
used"
TabAtkins: It's on UAs.
florian: Do we want to say UA may apply to others?
TabAtkins: That's why I started with a can
florian: Is sentence meant for author and UA or just author?
TabAtkins: Both author and UA. I don't think it's bad if a browser
changes to pointer on clickable things
AmeliaBR: We already agreed to UA must apply pointer on hyperlinks
AmeliaBR: More passive voice this cursor should be used could be
included without canceling the must.
florian: I don't object to current. If it's meant as vague I'm okay
with vague.
dbaron: Good to be clear who requirement is on
astearns: Not vague, it applies everywhere
<tantek> ok with CAN or MAY
<tantek> though slight preference for MAY
<tantek> also going to note for the record that no one followed up
with tests as I requested last year in the issue :P (unless
I missed something? searched whole issue for "test")
<tantek> https://github.com/w3c/csswg-drafts/issues/1936#issuecomment-346420266
AmeliaBR: Have an explicit requirement on UAs. Another sentence
could be authors should us it on any other element that
behaves as a link and may use it to indicate clickability
florian: There's no UAs must not
AmeliaBR: Exactly. No negative about UAs applying to other elements
florian: Like that better.
astearns: Does reduce confusion.
astearns: Objections to scoping this sentence to just authors?
astearns: Proposal: Authors should use pointer on links and may use
on other interactive elements
astearns: Objections?
<tantek> no objection
RESOLVED: Add sentence "Authors should use pointer on links and may
use on other interactive elements" To UI4.
astearns: Thanks everyone
Received on Thursday, 13 September 2018 00:36:24 UTC