W3C home > Mailing lists > Public > www-style@w3.org > May 2017

[CSSWG] Minutes Tokyo F2F Wed 2017-04-19 Part IV: Box Alignment, display:contents, Containment, Interpreting url()s [css-align][css-contain][css-values][css-masking]

From: fantasai <fantasai.lists@inkedblade.net>
Date: Fri, 26 May 2017 20:45:05 -0400
To: "www-style@w3.org" <www-style@w3.org>
Message-ID: <a9b3d455-853e-ffc7-3b8a-3615d29a98d3@inkedblade.net>
   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
   - 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.]


   - RESOLVED: USVString for href attributes on stylesheet and


Agenda: https://wiki.csswg.org/planning/tokyo-2017#topics

Scribe: myles


   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
   iank: Are there bugs?
   Florian: These browsers support the keywords on flex box but not
   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
   <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?

   RESOLVED: Making <br> and <wbr> not display with display:contents


   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
   TabAtkins: But it's probably fine. I don't have a strong opinion.

   tantek: <button> and <input type="button"> are pretty different
   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
   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

   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
   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
   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


   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
   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
   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> <div><span>Foo</span></div>
              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
   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

   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
   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>

   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
   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
   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
   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]

   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
   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
   Florian: And then when you scroll in it solves.

   plinss: Sounds like a giant hack that should be solved by scroll
   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


   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
   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


   Vlad: TYPO is willing to consider our preferences in terms of
   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:
   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()
   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
   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
   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
   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
   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
   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

   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
   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
   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
             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
   <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
   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:
   <dbaron> The image is here: https://dbaron.org/css/test/2017/
   <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
   <dbaron> so the upper test shows a single circle, and the lower
            four rects


   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
Received on Saturday, 27 May 2017 00:45:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:59 UTC