- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Fri, 26 May 2017 20:45:05 -0400
- To: "www-style@w3.org" <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.
=========================================
Flexbox & Alignment
-------------------
- Browsers were interested in fixing the partial implementation bugs.
CSS Display
-----------
- RESOLVED: Make <br> and <wbr> not display with display:contents
- RESOLVED: Strip <button> and treat as normal content
- RESOLVED: display:none the <meter> and <progress> elements when
display:contents is specified
- RESOLVED: display:none for <canvas> <applet> <embed> and
<object> when display:contents is specified
- RESOLVED: SVG elements <g>, <use>, nested <svg>, and <tspan> are
eliminated and their contents are hoisted under
display:contents but all other SVG elements are
display:none'ed
- TabAtkins and fantasai will propose wording to solve Issue 1118:
Should anonymous boxes always inherit through the box tree?
CSS Alignment
-------------
- RESOLVED: Change bottom margin edge to bottom border edge
wrt floor on last baseline of scrollable boxes.
CSS Contain
-----------
- RESOLVED: Size replaced elements as if intrinsic size was zero
and no aspect ratio.
- RESOLVED: Layout containment makes you a fixed-position
containing block for abspos children.
- RESOLVED: Level 2 for single-axis layout containment
- RESOLVED: WONTFIX issue 1043 this level, explain why
(Explanation: https://github.com/w3c/csswg-drafts/issues/1043#issuecomment-295276243)
- RESOLVED: 'display: contents' causes 'contain' values to be
ignored except style containment
- RESOLVED: Update WD of css-contain with edits for issues we
resolved today.
CSS Values / CSS Masking
------------------------
- Tentative resolution: mask-image distinguishes element reference
vs image reference via local vs external reference in url();
final resolution pending dbaron's investigation of Gecko code
[See Friday's resolution for final resolution.]
CSSOM
-----
- RESOLVED: USVString for href attributes on stylesheet and
cssimportrule
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/tokyo-2017#topics
Scribe: myles
Flexbox
=======
topic: Partial implementations of space-evenly in grid but not flexbox
github topic: https://github.com/w3c/csswg-drafts/issues/1167
Florian: We need people from blink and WebKit here.
Florian: The "alignment" properties apply to all layout modes.
Florian: The spec describes how to do this, but browsers don't
follow.
iank: Are there bugs?
Florian: These browsers support the keywords on flex box but not
grid.
Florian: You can't use @supports because the browsers do "support"
the value.
Florian: They shouldn't have shipped it.
myles: We will not un-ship it.
TabAtkins: It's easy to fix. We will probably fix it.
myles: We, WebKit, are regretful that we shipped it and want to
fix this.
shane: Are there issues?
Florian: Yes
Florian: You could also just provide a better fallback if you want.
shane: We have an old patch which gets us at least partway there.
We can pick it up.
shane: People are responsive.
CSS Display
===========
<TabAtkins> https://drafts.csswg.org/css-display/#unbox-html
TabAtkins: We all agreed that replaced elements and proper form
controls are display none when you set display:contents
on them.
TabAtkins: There are some more HTML elements where it's not clear
how we should treat them.
TabAtkins: ^^^ list.
TabAtkins: Chrome people have opinions.
<br> and <wbr>
--------------
TabAtkins: Next up: <br> and <wbr>
TabAtkins: They are magical today. They should be display:none.
TabAtkins: Our policy is not to make up things without use cases.
We are trying to come up with the most reasonable
outcome.
<general confusion>
fantasai: They should do their thing and ignore display:contents
fantasai: No strong opinion.
TabAtkins: But display:contents always makes the thing go away.
fantasai: But text doesn't go away.
tantek: But this isn't like text content.
<tantek> +1 on TabAtkins proposal
fantasai: But from a CSS author's point of view, it is.
fantasai: Jen Simmons raised the issue that <br> turns into a grid
item and this is bad.
fantasai: People don't think of <br> as an element.
TabAtkins: It's easy to run into trouble if you put raw text into
a flexbox. So we tell authors to put wrappers around
their text.
tantek: Agreed.
<dbaron> That is, Tab was saying you run into the same problem
with <b>bold text</b> if you haven't used a wrapper.
Florian: From an implementation point of view, do <br>s have magic
which is easy to make go away, or is it difficult to make
it display:none
fantasai: It's easy to implement.
astearns: Any objections to just doing display:none?
<none>
RESOLVED: Making <br> and <wbr> not display with display:contents
<button>
--------
TabAtkins: The <button> element.
TabAtkins: UAs are usually okay with rendering buttons just like
spans, so display:contents can do the normal thing here
TabAtkins: but <button> and <input type="button"> are usually
interchangeable.
TabAtkins: But it's probably fine. I don't have a strong opinion.
tantek: <button> and <input type="button"> are pretty different
though.
tantek: We should strip off the tags
fantasai: But it's confusing to an author!
fantasai: Authors' decisions about which to use is arbitrary.
tantek: You should strip the tag because it's actually less
confusing, not more confusing
tantek: because there is inner elements.
fantasai: We don't do that for <object>.
iank: It's like <canvas>.
tantek: But <button> has different fallback behavior.
TabAtkins: We should just strip the <button> wrapper and treat it
as normal content
<tantek> +1 treat button as a normal element
RESOLVED: Strip <button> and treat as normal content
<meter> and <progress>
----------------------
TabAtkins: <meter> and <progress> elements
TabAtkins: I think they are replaced.
TabAtkins: The contents of <meter> and <contents> are not
fallback. Instead, they are just legacy. So we should
display:none them.
TabAtkins: It's the same as <video> because the contents are not
meant to be displayed.
TabAtkins: It's irrelevant.
iank: Internally we represent these as form controls.
TabAtkins: We should treat like form controls.
fantasai: I'd prefer to show the contents but i won't object.
RESOLVED: display:none the <meter> and <progress> elements when
display:contents is specified
<applet> <canvas> <embed>
-------------------------
TabAtkins: 4! <applet> <canvas> <embed> elements
TabAtkins: When they are showing, they are definitely replaced, so
it's well-defined. But! (Especially for <object> and
<applet>) if the thing you're referencing is invalid,
it's meant it show the stuff inside it.
TabAtkins: Is it really replaced? Should we strip the wrapper away?
Florian: <object> has 2 states: 1) it's replaced, or 2) it shows
its contents
Florian: If it's not display:none, it's dangerous to authors.
iank: Usually for <canvas> you put your fallback inside the tag.
iank: It should be display:none.
astearns: The goal of display:contents isn't to hide contents.
iank: Yeah, it'll take the canvas out of the tree and show the
contents.
Florian: But we already resolved on that, maaaaaaan.
All: <object> is kind of different from the others.
Florian: When the content loads, we've decided that display:none
works. But otherwise, ?
tantek: Yeah the load state shouldn't affect stuff.
tantek and fantasai: but you should show the contents in both
cases (whether it loaded or not).
TabAtkins: We have a blanket policy which we can revisit but it is
a good policy.
Florian: Both states should do the same. And they should show
their contents.
TabAtkins: Yes, they should do the same thing. And the normal
state should be display:none and therefore both should
be.
astearns: Let's not discuss the blanket policy.
astearns: I want to go with display:none. Does anyone object?
RESOLVED: display:none for <canvas> <applet> <embed> and <object>
when display:contents is specified
display:contents on SVG elements
--------------------------------
GitHub Topic: https://github.com/w3c/svgwg/issues/305
TabAtkins: SVG does not have a box model. It's defined in terms of
something custom.
TabAtkins: I'd like to describe SVG in terms of a box model.
TabAtkins: So we have no idea what to do.
TabAtkins: SVG currently special cases display:none to say "stuff
doesn't render"
TabAtkins: Option 1: All SVG treats display:contents as
display:none
TabAtkins: but this isn't great because it is valuable here.
TabAtkins: <g> and <use> and nested <svg> can be stripped
fantasai: <tspan> too.
TabAtkins: Everything else should probably be display:none
TabAtkins: fantasai: This is consistent with how it works.
ChrisL: Will people try to use this to implement fallback?
fantasai: What if you display:contents two nested elements, does
it cascade?
TabAtkins: It does cascade, so the innermost text wouldn't render.
TabAtkins: The root SVG should display:none but inner ones not
necessarily.
TabAtkins: If nobody objects, I'll do this.
astearns: Objections?
RESOLVED: SVG elements <g>, <use>, nested <svg>, and <tspan> are
eliminated and their contents are hoisted under
display:contents but all other SVG elements are
display:none'ed
MathML
------
TabAtkins: Everything in MathML should display:none when
display:contents is specified.
TabAtkins: We may just .... not care about MathML.
astearns: Let's take the spec to CR, please!
fantasai: But we have new issues!!!
fantasai: So we can't go to CR.
fantasai: We can fix them up real quick and we'll come back.
Inheritance through 'display: contents'
---------------------------------------
github topic: https://github.com/w3c/csswg-drafts/issues/1118
fantasai: This is a fun test case
fantasai: There are anonymous boxes in the box tree. We defined an
anonymous box in the box tree has initial values except
for the ones which are inherited (from its parent box in
the box tree). But! When we have display:contents, if
the parent of the anonymous box, then the element's
parent is really its grandparent!
TabAtkins: "parent box" is reasonably well-defined now, but with
display:contents, not so much.
<TabAtkins> (Specifically, "parent box" is simple enough, in a
pre-display:contents world, that we don't have to
worry much about the fact that it's weakly defined.
With display:contents, tho, the full box tree starts
being more relevant, and the weak definition is more
troublesome.)
fantasai: What I expect is that we look at the parent box in the
box tree and we look at the element which generated that
box.
fantasai: However, implementations don't look at the box tree,
they look at the parent element and its properties.
fantasai: Sooooooo this is busted.
fantasai: So are these bugs? Or should we update the spec?
TabAtkins: We should do the latter. Inheritance doesn't pay
attention to the box tree. The fact that this uses the
box tree was hand-wavey.
TabAtkins: <gives example>
<section> <div>Foo</div>
</section>
<section> <div><span>Foo</span></div>
</section>
section { color: red;
}
div { color: green; display: contents;
}
TabAtkins: <explains the example>
dbaron: There are 2 different distinctions to make (but one may
not be observable).
dbaron: Gecko recently changed how anonymous boxes inherit (but
only for nested anonymous boxes). Previously, if you have
2 nested ones, one would inherit from the other. Now, all
nested boxes inherit from the closest real element.
Florian: Is there an observable difference?
dbaron: Not to regular users.
xidorn: What about a writing-mode change on an element with
display:contents and text inside it?
astearns: We need to change the spec to match the implementations.
fantasai: If you have an inline element and its the child of a
block, then it's the child of the root inline of that
block. If you remove that inline element, then the
contents of that inline element (the text) becomes a
child of the block's root inline. There's no intervening
box belonging specifically to the text. Now, if we make
that box go away, there's nothing that is holding the
properties that apply to the text other than the root
inline. The root inline's properties apply to the text
because there's nothing between there.
fantasai: If you put an inline in between the text and the root
inline, give it a property, then pull it away with
display:contents, then it's not in the formatting tree.
How is it contributing a color when it's gone?
TabAtkins: Inheritance always follow the element tree.
TabAtkins: Text doesn't have properties, but it does know things
like color.
fantasai: We have to invent this idea of a text frame, and say
that it has properties, and it's an anonymous object
which you can't get rid of.
TabAtkins: We kind of had to do that with selectors already.
TabAtkins: We say that clicking on raw text correctly triggers,
even when there are intervening shadows & etc.
fantasai: It is already a thing, but it doesn't have properties.
Now we are saying that it has its own properties.
TabAtkins: Yes, to achieve what all implementations do and what
makes sense.
TabAtkins: display:contents shouldn't change inheritance.
fantasai: Background color does go away when you take away the
box.
TabAtkins: In the example in the issue, do you think in the first
bit that text should be red?
TabAtkins: Where red is assigned to <section> and green is
assigned to <div>?
fantasai: <reads really hard>
fantasai: I expected div of to take the color of the section, and
div span foo to take the color of the div.
TabAtkins: I disagree.
TabAtkins: I agree with the originator and what implementations do
TabAtkins: We can work through the implementations to make things
well-defined.
astearns: This will be difficult to specify.
fantasai: It requires inventing a new type of box in the inline
layout model which we don't have yet.
TabAtkins: Putting the span in there changes how inheritance
works, which changes what users see, and this is
unreasonable. The present of an element shouldn't make
the color jump over the div.
Florian: The consequences that a non-styled span changes things is
scary.
astearns: Let's table this.
fantasai: If we make a new box, it belongs in the inline layout
module, not this module.
TabAtkins: Let's put all the boxes in display:*
fantasai: But you can't create it with display:*
fantasai & TabAtkins: <tries to figure out which modules this
should go in>
<last baseline alignment discussion part II moved to Minutes Part II>
Selectors
=========
scribe: TabAtkins
Propagation of the :focus pseudo
--------------------------------
github topic: https://github.com/w3c/csswg-drafts/issues/1240
Florian: This was raised by fantasai a while ago.
Florian: Topical now because Mozilla and Blink are both
implementing :focus-within, which depends on :focus, so
we should make sure we get :focus right.
Florian: We have wording attempting to say that "whatever magic
HTML says to make :active propagate (to labeled controls,
etc), it should apply to :focus too".
Florian: fantasai says this is either useless or contradicting
HTML.
Florian: I think you were saying that the way we phrased it
doesn't make it clear whether we were placing a
requirement on the HTML authors to fix this, or
overriding them and defining it propagates differently.
Florian: Because in HTML :focus and :active do propagate
differently.
Florian: So it's unfortunate if we disagree. Do we yield, or shout
at them?
Florian: I think we wrote it this way because there was a parallel
discussion about whether :focus and :active should
propagate from a form control to its label *and* vice
versa; we at least agree that they should both act the
same.
Florian: And we just filed an issue on HTML to figure out if it
should be bidirectional or not.
Florian: It was bidirectional in IE (not Edge).
Florian: Given that :focus-within is meant to do the same as
:focus, and there's no compat baggage, we should put a
stick in the ground and decide.
[need more time to think about this, we're dropping the topic for now]
css-contain
===========
Scribe: fantasai
Florian: Have a FPWD of css-contain that is well overdue, thus
close to CR.
Florian: Have some issues, let's close them.
contain:size on replaced elements
---------------------------------
github topic: https://github.com/w3c/csswg-drafts/issues/382
Florian: If you 'contain: size' on a replaced element, what should
that mean?
dbaron: You get whatever size specified, otherwise zero.
RESOLVED: Size as if intrinsic size was zero and no aspect ratio.
contain:layout wrt abspos/fixedpos containing blocks
----------------------------------------------------
github topic: https://github.com/w3c/csswg-drafts/issues/404
TabAtkins: Need to check with Ojan, inclined to accept proposal.
Florian: Can we resolve and check later?
TabAtkins: Proposal is that layout containment makes you a fixed
position containing block for abspos children
RESOLVED: Layout containment makes you a fixed position containing
block for abspos children.
ACTION TabAtkins ping Ojan about this issue
<trackbot> Created ACTION-847
single-dimension layout containment
-----------------------------------
github topic: https://github.com/w3c/csswg-drafts/issues/1031
Florian: Next one from dbaron...
dbaron: This one is a big issue.
dbaron: One of the things that a bunch of web devs really want is
what they call "container queries"
dbaron: which basically addresses the sub case of teams that
develop widgets or modules that are part of a bigger page.
dbaron: They're developing some markup and script and whatever
that gets included within a bigger page, and it will have
some size.
dbaron: The bigger page might use media queries to e.g. switch
from 3 columns to 2 columns, and widgets gets bigger
though viewport got smaller.
dbaron: If you're implementing the widget, you want to respond to
the size that the widget is, not the size of the viewport.
dbaron: Bunch of ppl want container queries that actually work,
rather than do what ppl do right now which is do layout,
flush, and set styles based on that.
dbaron: Seems to me it should have some relation to containment-
dbaron: that is, ability to do container queries should depend on
some kind of containment so that your insides don't depend
on your outsides which depend on your insides.
dbaron: The next point is that sometimes people want to do
container query on their width, but have an auto height.
dbaron: So, was thinking we want to have layout containment in
only one dimension.
dbaron: Beyond that haven't thought about it, so this is a "please
design me a feature" issue.
dbaron: This seems like a relatively high priority feature because
ppl do this a lot, and do it by doing flush-restyle loops.
Florian: If they're willing to go that far, using 2D size
containment is good, set it and then reset your height
after you do layout.
dbaron: Get ppl doing it for multiple parts of the page, so cycles
multiple times.
fantasai: Why not just have -x -y keywords?
TabAtkins: Hard to define what that means.
eae: Maybe sets wrong expectations, that you wouldn't get same
performance benefits.
TabAtkins: True, but you do get the benefit that when you're using
resize observer you get predictable behavior and not
loops.
Florian: Seems like level 2, esp. we don't have proposal yet.
TabAtkins: This plus resize observer plus custom at-rules, I'm
hoping will allow solving this use case.
TabAtkins: Been my plan for like 2 years.
RESOLVED: Level 2
Freezing/unfreezing size containment
------------------------------------
github topic: https://github.com/w3c/csswg-drafts/issues/1043
Florian: Probably better in 1D context, but still applies to 2D.
Florian: Imagine you have long FB page, infinite scroller, 37
screens down.
Florian: Because everything is dynamic, ppl will update stories
above where you are, which will change your size, which
will make you scroll.
Florian: Things that are off-screen should have their size frozen,
and when they enter the screen you should unfreeze them.
Florian: So want a variant of size containment that only applies
offscreen.
Florian: And then when you scroll in it solves.
plinss: Sounds like a giant hack that should be solved by scroll
anchoring.
iank: FB can also use intersection observer to do this.
Florian: That ends up being just slow enough that they do resizing
on-screen (rather than just off-screen).
Florian: My take is that once we get scroll anchoring a large part
will be solved, combine with fact that you can do manual
freezing if you want.
Florian: But I think this is not something to solve with magic
freezing and unfreezing.
fantasai: I agree with the last statement.
flackr: If you were to drag the scrollbar, we will probably put up
a frame before we run any script in response to the scroll
position, so you will see un-resized content.
Florian: Which is why I'd suggest there was some UI indication
(like graying out) that indicates out-of-date-ness.
Florian: Not as good as magic, but dunno how to make that happen.
Florian: So proposed wontfix.
astearns: Objections?
iank: We should also say that we'll keep use case in mind for
future stuff.
TabAtkins: But right now solution is use JS intersection observer.
Florian: And various upcoming features will make it better (though
not perfect) soon.
astearns: Can someone add a comment summarizing these conclusions?
RESOLVED: WONTFIX this level, explain why
Publication
-----------
Florian: That takes us to zero open issues on css-contain.
Florian: Modulo DoC, go to CR?
ChrisL: Changes section?
Florian: No, should I do that first?
ChrisL: If you can do it in a reasonable time. Just want to avoid
"CR pending edits" which takes 9 months.
tantek: Could update a WD now, and the resolve on CR once you have
DoC.
Florian: Question about DoC...
Florian: Not much happened between FPWD and now, do we need a DoC
covering comments from earlier.
ChrisL: Assumption in the Process is that FPWD is actually the
first *public* working draft.
Florian: Okay, I'll do DoC over old issues.
tantek: Is that needed?
Florian: Need to demonstrate wide review.
ChrisL: We also need to show usual sec/a11y/i18n reviews.
Florian: Will show non-trivial DoC, not necessarily comprehensive
to first ED.
RESOLVED: Update WD of css-contain with edits for issues we
resolved today.
[ Note: This section moved over from Thursday ]
Florian: Issue on combining 'display: contents' and 'contain'.
Florian: My suggestion is no effect for everything except for
style containment.
dbaron: The other way to do it is that containment sometimes
changes display, e.g. can blockify it.
dbaron: Could say that contain property wins
dbaron: and makes your display go away.
fantasai: Making 'display: contents' “goes away” is problematic,
what does it then become?
SimonSapin: What’s the blockification of display:contents?
dbaron: Block?
dbaron: I'm okay with what Florian said.
dbaron: Though I think some ppl might have intuition that
containment should win.
Florian: Seems like an error to me. Do the simple thing.
RESOLVED: 'display: contents' causes 'contain' values to be
ignored except style containment
Scheduling
==========
Vlad: TYPO is willing to consider our preferences in terms of
dates.
Rossen: Latest is that there is a possibility that next TPAC will
be ...
ChrisL: End of October in Lyon is under consideration.
astearns: Given TPAC is late October, should we aim for early
April for spring meeting?
Ambiguities in handling url()
=============================
Github topic: https://github.com/w3c/csswg-drafts/issues/383
<leaverou> relevant TPAC minutes where this was discussed:
https://lists.w3.org/Archives/Public/www-style/2016Nov/0070.html
TabAtkins: Everybody remembers issue from awhile ago -- it's
ambiguous whether an URL with a fragment ID is referencing
an element in the SVG or a pant server /mask whatever
TabAtkins: Everything is bad, and it's been bad since 2012 when
issue was first raised by roc.
TabAtkins: Going forward we wanted to rely on element() vs image()
functions to make it clear
TabAtkins: But still need to figure out what to do with url()
legacy.
TabAtkins: Unclear whether that should be property-specific,
language-specific, something else.
TabAtkins: Looking at TPAC minutes.
TabAtkins: Some proposals:
TabAtkins: 1. Treat ambiguous cases as url reference into an SVG
document, not treat as image and apply :target
TabAtkins: 2. Treat ambiguous cases as url, if it has a fragID
treat as a reference, otherwise treat as an image
TabAtkins: 3. Treat ambiguous cases, load it twice -- first see if
there's an appropriate reference, otherwise go back
and reload as an image
fantasai: 4. Do something different per property
* fantasai agrees with TabAtkins's summary that this is all bad.
plinss: #3 follows Web architectural principles better. Shouldn't
judge URL by its syntax like in #2.
Florian: #1 and #4 also don't violate principle.
plinss: Could be a PNG at the end of a URL. You don't know.
leaverou: Why would an author use a fragID on a PNG?
plinss: To crop a section of the PNG.
plinss: We made image() function to make this unambiguous.
TabAtkins: On the other hand, implementations really don't want to
load things twice.
TabAtkins: Chrome and FF seem to decide on reference vs image
based on whether it's local fragment vs external
reference.
TabAtkins: Could probably just switch on that, and then later
introduce element() vs image() functions.
TabAtkins: Might need more info from birtles.
fantasai: I'm okay with distinguishing based on local vs external
reference.
TabAtkins: No browser currently allows external SVG references.
dbaron: Gecko does in some cases, maybe not in CSS.
leaverou: Should not assume they never allow external SVG
references.
TabAtkins: Yeah, just don't need to consider it wrt web-compat.
jet: We do for clip-path.
dbaron: Most ambiguous case is mask.
dbaron: But I thought we did for clip-path, filter, and mask.
TabAtkins: Mask is the only one that's troublesome atm.
TabAtkins: Everyone else can define per property.
TabAtkins: If a property only takes images, or only takes clip
paths, not ambiguous.
TabAtkins: Didn't want to do per-property decision for ambiguous
cases.
fantasai: Some of these properties that are currently unambiguous,
maybe become ambiguous in the future.
fantasai: So in the future, would be per-property disambiguation.
fantasai: I think fill/stroke has (or will have) ambiguous cases.
fantasai: Fill currently takes a paint server reference, but we're
adding image references, so it will become ambiguous.
TabAtkins: So when you said you handle external mask references,
is that just for mask property that only accepts
external references?
dbaron: We parse the mask property into longhands, so we would do
it on mask-image, because that's where it lives.
TabAtkins: How do you split mask-image into the two different
cases?
TabAtkins: afaict, you did it based on whether local or not.
...
TabAtkins: Right now element() and image() have other features,
which is why were kicked out to L4
leaverou: Element() somewhat impl in Firefox.
TabAtkins: We could, though, define them as subset of the
functionality, i.e. same as url() except without
ambiguity.
leaverou: Option 3 is off the table?
TabAtkins: Yeah, because cost-prohibitive
leaverou: #2 is only a problem cuz web architecture?
plinss: Blatant violation of web architecture
fantasai: What about local ref vs external reff?
plinss: Not so bad.
astearns: Sounds to me that 1 is only viable option
Florian: Well, 1 and 4?
Florian: We will have to define property by property going forward
Florian: We do #1 on currently-ambiguous cases, but will have to
define property by property going forward.
TabAtkins: E.g. fill/stroke previously unambiguous, becoming
ambiguous with new fill-stroke spec.
astearns: So in cases where it could be interpreted as either, it
will be ?
TabAtkins: Alternately could make it local vs external, like
mask-image.
fantasai: For mask-image, what are the possible things we could
actually do?
TabAtkins: Depends on what FF is doing and if compat-required.
TabAtkins: I think local vs external is def how Webkit/Blink does
it, and it's how Gecko used to work.
birtles: Still does.
fantasai: So sounds like we *have* to do mask-image that way.
fantasai: Should we resolve on local vs non-local?
leaverou: Makes sense now because external reference aren't
possible.
fantasai: But we will have unambiguous syntax for that.
leaverou: But by adding a fragID, author made their intent clear.
TabAtkins: No, they didn't, because e.g. might be using svg stacks
where fragID is triggering :target
plinss: Can use a media frag to pull a frame out of an MP4.
leaverou: ok.
<birtles> fwiw the Firefox code I'm looking at is
http://searchfox.org/mozilla-central/rev/214345204f1e7d97abb571b7992b6deedb5ff98f/layout/style/nsCSSDataBlock.cpp#64
which at least indicates we don't trigger an image load
if it's a local reference
<dbaron and birtles investigate Gecko code>
<dbaron> The point where we actually branch between the SVG vs.
image-tiling case is in the function PaintMaskSurface in
nsSVGIntegrationUtils.cpp...
<dbaron> And as far as I can tell that's just a function of
whether a pointer is null, which is null as a function of
whether we managed to find an SVG Mask Element...
<dbaron> the thing that it's testing for null was set up in the
constructor nsSVGMaskProperty::nsSVGMaskProperty()
astearns: First proposed resolution is distinguish these cases on
mask-image via local vs external reference
astearns: which matches implementations, as far as we can tell.
astearns: Any objections?
dbaron: I'm not sure if that's actually happening. Things are
fancy here.
dbaron: Not sure if it matters.
RESOLVED: mask-image distinguishes element reference vs image
reference via local vs external reference in url()
TabAtkins: I'm betting we could apply local vs external globally,
on account of local hash bg images are broken right now
anyway, unless your HTML is also a PNG.
leaverou: What about hashes on data URL? If SVG was in a data URL,
and has a hash?
TabAtkins: That's still an external URL as far as loading pipeline
is concerned.
leaverou: I suspect that's something I've used...
astearns: For second instance?
fantasai: Second instance is now, fill-stroke.
astearns: Maybe wait until we have more info?
astearns: e.g. dbaron figuring out gecko code.
xidorn: Person who implemented mask-image says we do check if
target element is mask element after we load the file.
fantasai: Question is, after you check it and it fails the check,
what do you do?
dbaron: I suspect we do two loads.
plinss: Don't want to require impls to all do hardest least
performant thing, but don't want to preclude doing it
correctly.
astearns: Seems we have to leave this one for now.
dbaron: Anyone have a technique for making a file that's both a
valid SVG and a valid PNG?
Florian: I don't but I know who would.
dbaron: Might be able to test SVG as SVG.
Florian: If you need, try p01 on twitter, he makes crazy demos
dbaron: I think we just need an SVG that's a circle and a mask
that's a square.
[comments from after the meeting on this topic]
<dbaron> Here's a test showing that Gecko's distinction is based
on whether it can find the mask element:
https://dbaron.org/css/test/2017/mask-url
<dbaron> The image is here: https://dbaron.org/css/test/2017/
mask-url-image
<dbaron> the test links to a mask element that exists, and a
fragment that doesn't exist.
<dbaron> The former users the mask in the mask element and ignores
the mask-size, mask-repeat, etc.; the latter uses the
toplevel SVG as a mask and honors mask-repeat and
mask-size
<dbaron> so the upper test shows a single circle, and the lower
four rects
CSSOM
=====
SimonSapin: We have href attribute on stylesheet and cssimportrule.
SimonSapin: We should be using USVString, because they are URLs
SimonSapin: Can we resolve to do that?
RESOLVED: USVString for href attributes on stylesheet and
cssimportrule
Received on Saturday, 27 May 2017 00:45:54 UTC