- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 18 Feb 2020 19:20:23 -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.
=========================================
Constructable Stylesheets
-------------------------
- RESOLVED: CSS() is merged into CSSOM1 (either emilio or rakina
doing so)
- ACTION: hober, TabAtkins, and heycam to ask their TC39 reps to
advocate Arraylike
- RESOLVED: Make adopted stylesheets a CSSStyleSheetList and add the
appropriate add/remove methods to the document or
shadowRoot interface (WICG Constructable Stylesheets
Issue #45: CSS() and FrozenArray)
- RESOLVED: Remove title and alternate from constructor (WICG
Constructable Stylesheets Issue #105: CSSStyleSheetInit
dictionary may have unintended usage)
- RESOLVED: Add base URL constructor argument for sole purpose of
resolving relative URLs in stylesheet, and location of
the stylesheet remains that of the document (WICG
Constructable Stylesheets Issue #95: Defined location/
href of Constructed Stylesheets)
- RESOLVED: Constructed style sheets to always go after (WICG
Constructable Stylesheets Issue #93: Should
adoptedStyleSheets be ordered before other style sheets
in the tree, instead of after?)
Triage All the Specs
--------------------
- RESOLVED: Publish first public working draft of color-5
- RESOLVED: Publish FPWD of transforms-2
- RESOLVED: Publish media-queries-5
- RESOLVED: Publish FPWD of resize-observer
- RESOLVED: Publish FPWD of css-conditional-4
- RESOLVED: Stub out events API, then publish FPWD of
css-highlights-1
- RESOLVED: FPWD of scroll-anchoring level 1
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/galicia-2020
Scribe: TabAtkins
Constructable Stylesheets
=========================
Where does constructable stylesheets live?
------------------------------------------
heycam: Spec is currently in wicg
emilio: Resolution to put it in cssom
emilio: Discussion about whether to put it in level 2, or a diff
spec, or same document. I'd prefer it same document.
TabAtkins: We can ask Rakina if she wants to do the work or let you
do it. I agree putting it in CSSOM1 is best.
RossenF2F: Any objections?
RESOLVED: CSS() is merged into CSSOM1 (either emilio or rakina
doing so)
CSS() and FrozenArray
---------------------
github: https://github.com/WICG/construct-stylesheets/issues/45
heycam: Context of me raising this is that we'd like to ship soon.
there's a bunch of issues, but these four seem most worth
discussing.
heycam: Last time this was discussed, there was a hope that tc39
would define some new mechanism for array-like things.
<tantek> heycam, could you comment in
https://github.com/WICG/construct-stylesheets/issues/45
accordingly? I didn't see any reference to TC39 there
heycam: Last comment in the issue was that some small aspect would
be introduced, but not the whole use-case.
heycam: I'm not happy with FrozenArray either, and hopefully we can
move to a better compat model in the future.
heycam: But I'd like to see if we're definitely not going to move to
an explicit .add()/.remove() methods
hober: Speaking for Ryosuke...
hober: He's very opposed to FrozenArray, and wants to move back to
add/remove methods
<hober> https://github.com/w3c/webcomponents/issues/759#issuecomment-521053064
hober: He says FrozenArray encourages racy code.
hober: (example above)
TabAtkins: Now that Domenic has left TC39, we don't have anyone
really pushing for it anymore.
<tantek> TabAtkins, since you attend both CSSWG TC39, and I did
once, should one of us pick up liaisoning?
<tantek> I just want to make sure that if we (CSSWG) want something
from TC39, that we capture that in our issue, and that one
of us commit to filing a respective issue in a TC39 repo (I
can help with this, but also happy to defer to TabAtkins)
heycam: I'd be happy to change away from FrozenArray, but I want to
make sure that, since Chrome is shipping right now, they'd
be okay with changing.
TabAtkins: I think we're fine with changing since it's an early
change, but FrozenArray is what IDL is recommending right
now, and there's advice to explicitly not add new listish
collections.
emilio: I don't think we need a new collection; we can add functions
to document.shadowRoot, like .insertAdoptedStylesheet() and
.removeAdoptedStylesheet(), and maybe just
.appendAdoptedStylesheet().
TabAtkins: Not to get too in the weeds, but how would the adopted
sheets be exposed?
hober: Just a CSSStylesheetList, still hanging off of
.adoptedStylesheets
TabAtkins: I think that's OK, sure
Scribe: fantasai
hober: I wanted to follow up on what emilio said seems fine
hober: Problem here, we all agree, CSSOM is not great
hober: What I like about the resolution isn't that it continues
CSSOM parts we don't like
hober: It's a feature addition to CSSOM that's compatible with
CSSOM, but does not prevent us from coming back and fixing
all of CSSOM
hober: Let's make all the same mistakes we've always made
hober: even though it's not a design we're not crazy about
hober: and come back and fix it all later
TabAtkins: Are we sure that CSSStyleSheetList can be upgraded to an
Arraylike?
hober: idk
bkardell: CSSOM.next context?
TabAtkins: Yes. I think we can
TabAtkins: Would be nice to know for sure
heycam: Depends on particular solution
heycam: Emilio's suggestion is to add the mutating methods on the
shadow root and not on the style sheet list object, right?
heycam: A little weird and different that the object that exposes
the list of items is not the same object on which you have
the mutating methods
emilio: How different from CSSGroupingRule having .insertRule() or
CSSStyleSheetRule having .insertRule()?
heycam: You're right, it's already weird!
Proposed: Make adopted stylesheets a CSSStyleSheetList and add the
appropriate add/remove methods to the document or
shadowRoot interface
heycam: Compared to CSSStyleSheetRule, there's no append method?
emilio: But I mentioned append because I suspect that's what more
people would do
<tantek> Is there any outstanding request for TC39? Or did that get
dropped?
<fantasai> tantek, we believe we can still upgrade the
CSSStyleSheetList into an ArrayLike in the future.
hober: Tantek raises question, should we communicate our continued
interest in this problem to TC39? And how?
TabAtkins: We need a champion, interest isn't enough.
TabAtkins: I'm overloaded, so I can't do it
TabAtkins: for Arraylikes
hober: We can ask our reps on the group to mention it
<tantek> Can we capture in an issue at least? Even without a
champion?
<tantek> Thanks hober
ACTION hober, TabAtkins, heycam : Ask TC39 reps to advocate Arraylike
RESOLVED: Make adopted stylesheets a CSSStyleSheetList and add the
appropriate add/remove methods to the document or
shadowRoot interface
<br type=lunch>
CSSStyleSheetInit dictionary may have unintended usage
------------------------------------------------------
Scribe: stantonm
github: https://github.com/WICG/construct-stylesheets/issues/105
heycam: CSS stylesheet interface has constructor, allows to set
various things on the stylesheet
heycam: Seems like allows combinations of things that are not valid
heycam: specifically creating stylesheet with empty title
emilio: Only use for title and alternate is compute disabled bit
emilio: Don't see anything useful
TabAtkins: So you're saying we should just remove it?
emilio: Yes
chris: Don't need it not necessary
emilio: Title attribute sets preferred stylesheet list, why it
doesn't apply in shadow dom
emilio: Don't know what it means for ransom constructible stylesheet
emilio: Just use .disabled attribute
heycam: Remove constructor, and force .disabled?
emilio: Title doesn't work in shadow dom
emilio: Reason title is useful is because browsers provide UI for
switching
emilio: .disable is still fine
chris: Used to be more visible for, but some functionality moved away
RESOLVED: Remove title and alternate from constructor
Defined location/href of Constructed Stylesheets
------------------------------------------------
github: https://github.com/WICG/construct-stylesheets/issues/95
heycam: Regular non-constructable style sheets have URL to resolve
other stylesheets
heycam: With constructable, no facility to provide URL
heycam: Regular URLs are resolved against document
heycam: You might want to be able to specify
TabAtkins: Web component wants css to also be relative to some 3rd
party url?
TabAtkins: Can't hardcode deployment URL, how do you use to it to
get relative URL
TabAtkins: When user says background.png, want it to use 3rd party
load path - currently uses first party
heycam: Read issue as today there's not a good way to do this
TabAtkins: Splitting parts of URL, base part still might be hard to
obtain
TabAtkins: URL is hardcoded somewhere...just elsewhere than your
stylesheet pipeline
hober: Probably fine to set base and location as specified
heycam: Not specifying URL of sheet itself
hober: Yes, sheet URL is same as document URL
RESOLVED: Add base URL constructor argument for sole purpose of
resolving relative URLs in stylesheet, and location of the
stylesheet remains that of the document
TabAtkins: And do we need to note the security concerns that bz
raised, like with file:// etc?
hober: Those are addressed by instead doing this as just a
relative-url resolver, and keeping the stylesheet location
the same.
TabAtkins: Cool.
Should adoptedStyleSheets be ordered before other style sheets?
---------------------------------------------------------------
github: https://github.com/WICG/construct-stylesheets/issues/93
heycam: Spec says ordering of stylesheets should be after, but
actually should it be other way around?
<heycam> https://github.com/WICG/construct-stylesheets/issues/93#issuecomment-487772869
TabAtkins: My comment says make sense to put after
emilio: Don't think there's a strong reason for one or other
hober: Agree, but is there consistency arguments?
TabAtkins: Maybe related to @font-face, which is after
bkardell: Talking about shadow root and document styles, strangely
related - some things bleed through, some blocked
bkardell: Not sure I get what ordering means
bkardell: would like them to come before
bkardell: Different use cases, adopt styles from outside
TabAtkins: All sheets that come from markup come before adopted
style sheets
bkardell: We want to use these for UA equivalent, seems like not the
right move
TabAtkins: Adopted style sheets help when people put things directly
in shadow dom
TabAtkins: Component usage will move to adopted style sheets, gives
full control
TabAtkins: if you use style inline, it's baked into the template
TabAtkins: Similar to link style sheet in head, where you override
with adopted
TabAtkins: both ordering can make sense, no strong argument
bkardell: We don't know which is correct
hober: If we don't know, ask the author
hober: Implies two sets of adopted style sheets, seems complex
hober: not sure if additional complexity is worth it
TabAtkins: Don't need two sets, just move from shadow root to adopted
bkardell: Can you do adopted style sheets outside shadow dom
TabAtkins: Yes
hober: summarizing = after, if they want before have to specify
RESOLVED: Constructed style sheets to always go after
astearns: And if we realize that authors do have common need to put
the adopted ones first, we're free to add a knob for that.
TRIAGE ALL THE SPECS
====================
chris: color-5 is ready, it's a delta spec with color modification
<florian> +1
RESOLVED: Publish first public working draft of color-5
hober: FPWD of transforms-2
RESOLVED: publish FPWD of transforms-2
dbaron: No objections, maybe it makes sense to publish transforms-1
at same time
fantasai: transforms-1 is in good shape, it's in CR
fantasai: media-queries-5
RESOLVED: Resolved to publish media-queries-5
dbaron: Does publishing delta spec break tools?
TabAtkins: bikeshed will remove things
TabAtkins: There's no quick fix
chris: color-5 is entirely new feature, it's useful to have delta
TabAtkins: Un-delta for publishing
fantasai: That's hard, we need to have goal to publish more specs
dbaron: Add a thing that both versions maintained in single doc
TabAtkins: No quick solution
fantasai: Can we publish resize-observer
<rego> https://drafts.csswg.org/resize-observer/
dbaron: Any concerns with it being in WICG
florian: Double IPR for contributions
fantasai: In practice doesn't matter if they're also in CSSWG
TabAtkins: Same boat, we're good
astearns: Only asking to publish resize-observer yourself
chris: Have to file issue saying to publish FPWD
RESOLVED: publish FPWD of resize-observer
fantasai: css-conditional level 4
RESOLVED: publish FPWD of css-conditional-4
fantasai: css-highlight-1
hober: Some disagreement
hober: With FPWD we want to make sure we have good idea of what were
doing
hober: event API is missing
hober: In current would rather not publish, we should at least stub
it out before publishing
florian: Gives different signals to lawyers if it's incomplete
hober: I can commit to stub it out
RESOLVED: Stub out events API, then publish FPWD of css-highlights-1
fantasai: Any other drafts?
<tantek> I'll be ready to republish CSS Scrollbars soon
<tantek> Just one issue/edit remaining
<tantek> (thanks to fantasai nudging me last week)
florian: text-decoration-4
fantasai: need to check through issues first
fantasai: Any other working drafts we should publish?
astearns: Do we need to request before?
fantasai: Depends on time frame, not normally
heycam: Maybe scroll anchoring
TabAtkins: I can own, and publish
RESOLVED: FPWD of scroll-anchoring level 1
florian: scroll bars?
fantasai: tantek just said he has some more issues to fix
<tantek> other than that issue 3315, draft and changes section is up
to date but still regenerating (re-bikeshedding?)
https://drafts.csswg.org/css-scrollbars-1/#changes
Received on Wednesday, 19 February 2020 00:21:06 UTC