W3C home > Mailing lists > Public > www-style@w3.org > March 2019

[CSSWG] Minutes San Francisco F2F 2019-02-25 Part V: Selectors, ResizeObserver, CSS Tables spec methodology, Getting images' aspect ratio right from html attributes [css-selectors] [resize-observer] [css-tables]

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 26 Mar 2019 22:28:54 +0300
Message-ID: <CADhPm3tzgXMVe917Up48ukS2BnrmQ4ufGBr4vsaXRGZteAPRPA@mail.gmail.com>
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.

Selectors (continued)

  - The proposal to try and fix :visited to not leak by limiting what
      can be done (Issue #3012) would break some current usage.
  - The group also discussed some possible alternatives, such as
      mitigating timing attacks by doing more unnecessary work or
      reducing styling restrictions in safe environments without
      changing other existing restrictions, however there are many
      perf and complexity problems involved in these approaches.
  - TabAtkins is going to work with Alex Russell and see how bad the
      breakage will be in terms of user friction under the proposal.


  - The earlier breakout session was summarized for those not in
      attendance (See Part III). Some members were concerned about the
      resolution for Issue #3673 (Adding fragmentation support to
      resize observer) authors might not plan for fragmentation and
      there was an urging to ensure there are good clear examples.
  - RESOLVED: Only content and border boxes (Issue #3326: Which boxes
              should an author be able to observe?)

CSS Tables spec methodology

  - The authors will continue to evaluate all implementations to try
      and find where all implementations are the same and specify that
      behavior however they will no longer consider Edge due to the
      announcement that Edge will move to the Chromium engine.
  - If there's behavior difference it will be noted in the spec and
      issues will be filed to figure out the correct approach.

Getting images' aspect ratio right from html attributes

  - Initial proposal from Ojan was adding an intrinsicsize attribute
  - The alternate proposal is to map the existing width / height
      attributes to the aspect-ratio property by adding to the UA
      stylesheet a rule that's the equivalent of 'aspect-ratio: attr
      (width) / attr(height)'.
  - The main debate seems to be whether to re-use width/height or
      add new attributes for holding this info.


Agenda: https://wiki.csswg.org/planning/sf-2019

Scribe: emilio


Solve :visited once and for all
  github: https://github.com/w3c/csswg-drafts/issues/3012

  TabAtkins: So we discussed this about 6 month ago with no conclusion
  TabAtkins: :visited is bad and leaks no matter what we do, there's
             always some way to invoke timing channel attacks
  TabAtkins: We should just fix this, only limiting visited to stuff
             JS can already observe, and making it a regular
  TabAtkins: <reads over the issue>
    At minimum, same-origin visitedness is always visible to the page,
      as the server can track its own cross-links, assuming standard
      tracking mechanisms exists (cookies, sufficiently high-entropy
      user identification, etc). So all same-origin links should
      report :visited.
    Cross-origin inbound links are always visible to the page if the
      Referrer header was sent in the request.
    Cross-origin outbound links are always visible to the page if the
      user visited that link from this origin, as there are a
      multitude of ways to track outbound links (JS auditing,
      <a ping>, link shorteners, etc).

  TabAtkins: Solving the three points on the issue solves the use
             cases that I think people care about, and doesn't expose
             more privacy information for most people
  TabAtkins: These three should be safe to expose to :visited
  TabAtkins: Last time Mozilla had some opinions on this

  Scribe: fantasai

  emilio: I think the general position is that we should try this, but
          there were some concerns from other Mozilla ppl like Mats,
          that not keeping the existing restriction would also not be
          GDPR compliant
  dbaron: I think can try to represent Mats's position
  dbaron: Basic idea is that in collecting the data about what sites
          people have visited, browsers are collecting a substantial
          pool of privacy-sensitive data.
  dbaron: They have an obligation to protect that data as much as they
  dbaron: In many cases, the sites themselves have not gathered that
  dbaron: Given that we have a mechanism for protecting that data
          right now
  dbaron: we don't want to expose that pool of data to sites right
          now, even if they could collect it because they haven't.
  TabAtkins: But how much is because we know we can extract this info
             right now?
  TabAtkins: anything new you could get from this, you could get today
             via timing attacks.
  TabAtkins: Defeating timing channel attacks here means running
             everything slower
  TabAtkins: Doing the rendering work for visited all the time even if
             it's not being used on the page, etc.
  TabAtkins: Remember the attack is running 10,000 stacked DOM
             elements with a filter on them if it's visited
  fantasai: :visited is on filter or?
  TabAtkins: :visited below, 10000 filters above it

  Scribe: emilio

  hober: I'm a little concerned about the usage of sites whose primary
         purpose is showing a bunch of links, e.g. reddit or hacker
  hober: it's pretty common to visually filter out the things that are
  hober: so it'd decrease the usefulness of sites we know are very
  TabAtkins: This is the only use case we kill
  TabAtkins: and I don't see a way to keep it
  * astearns often skips over links in my RSS feed because I've
             already visited via twitter

  AmeliaBR: My proposal is adding a safelist for history access, the
            same way browsers expose a setting for third-party cookies
  AmeliaBR: I don't think that possibility would need to be defined on
            the spec though
  TabAtkins: I'm concerned with trying to ask the user to usefully
             decide about whether Reddit should have access to all
             their browser history
  AmeliaBR: Otherwise we get back to the same complications

  heycam: Somebody suggested exposing the visited state in some way
          outside of the page
  heycam: like a little hover status-bar or such
  heycam: so there may be some way to expose this in the UI if there
          was an important necessity of keeping this use-case
  fantasai: I don't think I'd want to carefully hover over all the
            links when I'm searching for something
  TabAtkins: It'd handle search, since most of the links are found via
             search anyway, but it'd break link dumps and such
  florian: Even via search, you might want to find something you've
           visited and you look at the purple link
  TabAtkins: Yeah, but I don't think we can plug this privacy hole
  fantasai: If you turn off Javascript, it can apply in more cases
  fremy: You may execute a timing attack measuring loading time?
         Though network may be not reliable enough generally

  heycam: So this issue seems to have two parts, changing how :visited
          matches, and changing the restriction of the properties that
          apply to it
  TabAtkins: there's no point in keeping the restrictions if we limit
             what's exposed
  florian: Except the other argument about sites not having collected
           the data yet
  heycam: So last time we (Mozilla) discussed this internally, we said
          that we'd be happy to experiment with some restriction like
          that, but not with unrestricting the property
  TabAtkins: I don't see the point
  hober: Compat with existing content, maybe
  AmeliaBR: Do we have some general policy to deal with this "zombie
            CSS case"?
  TabAtkins: Trying it

  fremy: I remember some weirdness with javascript links
  fremy: I think there's a fourth case which is a `javascript:` link I
         think currently the link becomes visited only until you
         refresh the page
  emilio: So same as links and `#hash` links

  TabAtkins: So dbaron mentioned it was feasible to mitigate
             side-channel attacks, how feasible do you think it is?
  dbaron: I think we could reduce the band-width of some of them, but
          never get rid of them entirely.
  dbaron: The amount of effort we could spend on this depends on how
          it competes with extracting the same data via other attacks
          like cache timing attacks

  TabAtkins: I'll try to push internally to do some experimentation in
             this regard
  TabAtkins: I know that Alex Russel is the original author of this
             idea and he'd be really happy
  AmeliaBR: I think it depends on how much users hate to break the
            search results use cases and such, but it'd give way more
            flexibility for authors
  AmeliaBR: If it's going to break sites major sites with user focus
            you can explain it, but I don't know what the reaction of
            the average user is

  hober: Besides cleaning up and simplifying :visited, what's the
         argument for removing the restrictions?
  TabAtkins: It'd make :visited a regular pseudo-class for authors
  hober: It's weird, but do authors actually complain about that?
  AmeliaBR and TabAtkins: Yes
  AmeliaBR: There are use-cases and hacks to show or hide the "unread"
            using the color matching the background of the text
  AmeliaBR: and despite of all the restrictions we're still leaking
            the history
  AmeliaBR: just because CSS is so complex that if somebody changes
            rendering somebody smart can figure out
  florian: So we're annoying people for no good reason

  TabAtkins: ...
  fantasai: No, the current spec just says
            “Since it is possible for style sheet authors to abuse
             the :link and :visited pseudo-classes to determine which
             sites a user has visited without the user’s consent, UAs
             may treat all links as unvisited links or implement other
             measures to preserve the user’s privacy while rendering
             visited and unvisited links differently.”
  TabAtkins: Right, because my patch for this proposal was not
             accepted, because reality is much more complex...

  dbaron: Somebody said for no good reason, I think there's one other
          reason to think about which is a distinction between attacks
          that are clearly detectable and ones that are not.
  dbaron: A site can learn about your visited links via somewhat
          normal code, or via code that is obviously querying your
          history, and I think it's a distinction it's worth thinking
  florian: So there's no technical distinction but maybe legal ones

  florian: I'd add "Javascript is off" to the list of "safe"
           scenarios, because then why not?
  dbaron: Some attacks work without javascript, like loading images or
  florian: Alright, then not...

  Scribe: fantasai

  emilio: One question is, one of the objections from Mats was that
          websites haven't collected this data, and now we're exposing
  emilio: If we change how it works, a lot of existing history....
  emilio: In order to implement this, you need to change how you store
          history. It stops being a giant table of all the links you
  emilio: You need to track from/to lists.
  emilio: That's new data, nobody has collected it yet.
  TabAtkins: Implementation-wise it'll be you start collecting data
             now, but then don't switch over for a few months
  AmeliaBR: That's why Tab split into 3 parts, we can have different
            levels of support
  AmeliaBR: E.g. SHOULD support :visited on same-origin
  AmeliaBR: You can do that with info you currently have
  AmeliaBR: Next steps could be smarter

  Scribe: emilio

  fantasai: So I think one of the discussion points is that something
            that doesn't match any of the categories does not get
            :visited styling at all
  fantasai: Also for same-origin you should be able to use whatever
            styling you want
  fantasai: We don't have to do that right now. We could do something
            more limited for right now while we figure it out
  fremy: That doesn't work because it's observable via timing attacks,
         and you still need to run styling twice to avoid them
  AmeliaBR: So right now we have this visited styles and we ignore the
            properties, and we could check whether it's a same-origin
  fremy: Memory-wise you double the cost of styling, because for any
         property that can be different for :visited vs not we have to
         store two values, for visited + unvisited. Currently that's
         storing two copies of style data only a few properties,
         but if we open it up we'll have to double everything.
  dbaron: Only for link subtrees
  dbaron: It's not all elements that need duplicate data, it's just
          links and their descendants, which typically aren't very

  Scribe: fantasai

  fremy: The other thing wanted to say is that even if you double the
         memory and you store all the properties twice and do
         everything twice.
  fremy: You can have nested links
  fremy: One same-origin and one not
  fremy: Then you have to keep track of whether the difference in
         style is because of the visited styling of the first link or
         the nested one
  emilio: When you have nested link, from the pov of the nested link
          and its descendant, the nested link is the only link that
          could be visited on the page
  fremy: That's the restriction we have now. But going forward

  emilio: Why I think this wouldn't work is you could detect the
          performance of styling a same-origin link inside a visited...
  emilio: Let's say you have a cross-origin, and a same-origin link
          inside it
  emilio: If you don't apply restrictions to that...
  emilio: ... as long as links are treated independently ... I have to
          think harder than this
  <AmeliaBR> Nested links don't really exist. If you create them from
             the DOM, browsers are a mass of incompatibility in all
             sorts of ways. But, you could have a `:visited +
             :visited` selector which could get into a mess of

  fremy: Even if the thing we do now works, we have to have special
         exception so that when you do selector matching, if it's the
         first link that you encounter from the base...
  fremy: Right now this is what browsers do. It's quite messy
  fremy: If you allow some to keep all properties and others not, then
         you have to keep track. I don't think it's a good idea.
  TabAtkins: I see why it would be complex at the minimum
  AmeliaBR: Gets rid of one of the arguments for these changes, which
            is that it would simplify style matching

  myles: Timing attacks, one way to solve them is to have repaints
         more predictable, either more or less often
  myles: Why not pursue that solution?
  myles: Instead of making things more expressive
  TabAtkins: I'm not sure how changing timing of repaints can really
             solve this
  TabAtkins: E.g. on :visited it activates 10,000 filters
  emilio: ...
  emilio: You need to repaint every time the href changes
  emilio: dbaron tried that, was big perf regression
  myles: That was a perf regression, but performing style selection /
         cascade wasn't?
  dbaron: It wasn't the whole tree, just the links. And they usually
          don't have many descendants
  myles: So recomputing style is cheap but recomputing pixels is not
  dbaron: I think the repainting patch that was a perf regression was
          to do more repainting than emilio said
  dbaron: It repainted whenever an async history lookup finished
  dbaron: You start a lookup, you get a result
  dbaron: A lot of timing a attacks could resolve by repainting all
          links instead of just the one that changed.
  dbaron: but that's really expensive
  dbaron: At the time I wrote this, history lookup was sync, async
          landed a week after

  myles: If we're just allowing :visited to become more expressive,
         then we're not breaking any navigation sites
  TabAtkins: The proposal was to allow :visited to do more by
             restricting where it can be used.
  AmeliaBR: Changes the balance
  AmeliaBR: Some cases get easier, others get impossible

  AmeliaBR: Wrt just fixing timing attack level
  AmeliaBR: Every time we introduce a new property, someone comes up
            with a new example
  AmeliaBR: Also not all are timing attacks. Some are abusing user
  AmeliaBR: Taking properties we've got, making some elements
            invisible or visible
  AmeliaBR: Using the fact that there's a rendering change and then
            using people to reveal what they're seeing on the screen
  iank: Nasty one is to have full-page pop-up and position X different.
  fremy: Which X do you see?
  fremy: That's the one you click on

  TabAtkins: So even if we solve timing attacks, don't solve all the
  TabAtkins: That's why I want to do this in the first place
  AmeliaBR: So going back to earlier discussion that, OK, it comes
            down to what are users going to say if we break the one
            use case
  AmeliaBR: Are any browser teams willing to do some experimentation
            with that and try to see how many complaints you get?
  TabAtkins: I think working with Alex Russell we can try something
  Rossen: Do you feel like you have enough, Tab?
  TabAtkins: Yeah.

  Scribe: emilio

Breakout Session Recap

  <xfq> https://wiki.csswg.org/planning/sf-2019#resize-observer-breakout
  Rossen: The first one (#3550) is an issue that plinss filed to make
          sure that RO took fragmentation into account
  Rossen: So there's a proposal for an API that exposed the size of
          the boxes that you observe, and the question is whether we
          should expose the position
  Rossen: gregwhitworth ran a bunch of polls in twitter, and the
          conclusion is that this was not necessary
  Rossen: so we don't need to read the whole thing, but the resolution
          is that we don't want to include the offsets
  Rossen: and they're easily obtainable if you wanted

  Rossen: Next one is the shape of the API (#3329)
  Rossen: It basically boiled down to two different ways of creating
          the shape of the entries
  Rossen: First option was to expose for each entry the target element
          and the content rect (for v1 back compat) and in the first
          case you only have the `inline` and `block` size for the
          observed rect
  Rossen: Option B is you have both of them all the time, and you only
          notify if the one you're observing gets triggered
  Rossen: There was a later addition for the scrollbox, but we
          detoured a bit
  Rossen: because the use case was easily addressed by scroll-snap
  Rossen: According to gregwhitworth option B was way more popular
  Rossen: so we resolved with that

  Rossen: The final issue (#3673) was the fragmentation one. As
          expected this took a bunch of time
  Rossen: The solution we came up with here addresses the initial
          issue which is summarized in plinss' comment in the issue
  Rossen: After discussing a bunch of different examples and
          whiteboarding essentially we're going to add for the entry
          object instead of having one size we'd have an array of sizes
  Rossen: So for no-fragmentation you always have an array of size one
          and if you're fragmented you get one per fragment
  Rossen: We'd always notify if any of those rects change or if the
          number of fragments changed
  Rossen: The competing proposal was to keep inlineSize and blockSize
          and an array of fragments
  Rossen: Two issues with this one, which is that in the 99.99%
          use-case you have the same info twice
  Rossen: which is a bit odd
  Rossen: There are some upsides, because you may not know what
          fragments are
  Rossen: and you may be curious
  Rossen: We quickly debated on what the inlineSize and blockSize
          should be if you actually fragment into multiple fragments
          with different sizes
  Rossen: like with different columns and such
  Rossen: It's supposed to be some sort of union, but union of what?
          In the box direction? visual view? It'd have to be an open
          question, and we didn't want to solve it right now
  Rossen: If we'd have taken that we'd define it to whatever the CSSOM
          APIs would return, which is not defined
  Rossen: So we voted and decided on the first

  emilio: My question is, with this API, the number of fragments can
          also go to zero
  Rossen: No, you always have an element
  emilio: If you're observing an element and it becomes display: none,
          would you notify?
  emilio: You'd notify when number of fragments change, right?
  Rossen: You get that notification if anything inside that changes
  Rossen: This means that now, the content box would be gone
  Rossen: You can't see anything inside it
  emilio: There should be a test for that
  Rossen: You should write it :-)

  fantasai: I think this makes a lot of sense, my concern is what
            happens when you're a developer and assume that things
            will never fragment
  Rossen: If you assume you never have fragments, you always have to
          use the first fragment
  fantasai: Then people will do that and there'd be more fragments and
            they would never look at them
  fantasai: and then code will be confused because their 100px box
            will be fragmented
  florian: We discussed that and the conclusion is that they'd need to
           handle it, because there may want the sum, or the largest
           of the fragment dimensions...
  fantasai: Would it make sense to add a few convenience methods for
            common stuff?
  Rossen: I don't think that should be up to us to expose these easy

  myles: What would these wrappers do if you're laid out horizontally?
         There's no answer
  Rossen: If you want to handle your own layout like houdini,
          ResizeObserver is not that

  fantasai: So when you're fragmenting there's the direction you're
            fragmenting (for pagination is the block axis, for inlines
            it's inline direction)
  Rossen: btw, RO doesn't work on inlines, so it's always block axis
  fantasai: So the interesting questions is, what is the size of the
            individual fragments
  Rossen: And the can do that
  fantasai: My concern is that they'd just index the first because
            it's not easy to sum them
  Rossen: This gets down to the question of what getClientRects is
          supposed to return here, either the sum of the sizes, or the
          union of the boxes
  fantasai: That may be be another nice thing to do
  florian: Browsers do different things, so we just give them the data
           and let them compute
  fantasai: I'm concerned that they're just not going to bother
            computing it and they're going to just go to the first
  fremy: And that's fine, 99% of the cases you're going to just have
         one fragment
  fantasai: It's not fine because printing is a user action, not an
            author action
  fremy: But you don't need RO when printing
  florian: Pagination and printing are not the same thing
  fantasai: So florian's point that there are mediums where you're
            paginated but dynamic, like e-books
  Rossen: I agree, it's our belief that having the collection always
          in their face is a lot more abstracted and something to make
          them think about the fragments than having two pieces of
          data and let them choose always the first
  Rossen: If you care about fragmentation you can easily write a few
          lines of code to deal with it, but I don't think we can help
          people avoid assumptions about fragmentation not happening
          by exposing more helpers
  <iank> the issues with clientWidth / clientHeight -
  fantasai: You can help issues to not be lazy by telling them which
            numbers you may want to use
  fremy: But you're assuming they're going to care, and in the no
         fragmentation case they'll be confused because all the
         answers with one fragment is going to be the same, I don't
         think using `reduce` on an array is really hard, and if you
         give them 10 functions that they don't know and they always
         are the same they're going to peek whatever
  fantasai: We should definitely have examples on how to use them
  fantasai: That show handling fragments correctly with copy-pasteable
            code that they can use instead of indexing the 0th fragment

  AmeliaBR: On that record, we could rename the field to `contentBox`
            to `contentBoxes` to emphasize that they can be multiple.
  Rossen: But there's a content box, the list are the fragments
  myles: If my understanding is correct, the purpose of adding in one
         direction and maxing in the other is creating a union of the
         fragments, the author needs to know which direction is maxed
  florian: It depends on what the author wants to do, if you want to
           emulate container queries summing in one dir and maxing on
           the other it may be reasonable, if they want to position
           something on top that's not going to work
  Rossen: This is another reason why we didn't want the first option
  fantasai: The arrangement of fragmentainers is a different question
            from the direction you fragment in
  Rossen: So that's the summary

  emilio: BTW, getClientRects() is from the CSSOM specs?
  Rossen: Idk, but when you find out, file an issue

  AmeliaBR: What was the general reason for creating these sizes that
            tell you inline sizes / block size instead of just the DOM
            rect that tells you both the size and position on screen?
  iank: So the motivation to not give you the position is that authors
        may expect for it to fire when position changes (which it
  AmeliaBR: So you can do that querying it yourself right?
  iank: Yes
  fremy: Main use-case for this is to add "..." depending on the size
         and such, something that cares about the size
  emilio: Another reason why the client APIs might not be great is --
          and this is something we should maybe solve -- the
          positioning ones don't quite work since they're relative to
          the CB
  emilio: So that means nearest scroll frame or whatever
  emilio: WK/Blink/Gecko should follow soon, they've agreed to
  emilio: in the presence of Shadow DOM it changes
  Rossen: This is off topic

  Rossen: So we should write some examples that take into account
  fantasai: So what I want is teach authors to write their code to be
            resilient when their website is loaded in paginated mode
  Rossen: So this is a quick summary
  Rossen: We have some other RO issues tomorrow
  Rossen: Maybe good to take them because we're warmed up
  <dbaron> I'm not sure what fantasai wants is a realistic
  <fantasai> No, I want examples *in the spec* which handle this
             *correctly* for all the use cases they care to illustrate
             when such pages are rendered in a paginated reader
  <fantasai> Rather than either a) no examples in the spec or b)
             examples in the spec that only work in scrollable media
             because they index the first fragment or otherwise assume
             there's only one
  <florian> I think an abstract example of what you do in general
            isn't helpful, but a concrete example doing something
            concrete should be written to handle fragmentation

Which boxes should an author be able to observe?
  github: https://github.com/w3c/csswg-drafts/issues/3326

  gregwhitworth: What this comes down to is: We want to observe more
                 boxes, v1 has only content box, and then webdevs were
                 confused about that, so we wanted to add the
                 capability to declare which box you're able to observe
  gregwhitworth: We had the scrollBox, but we don't have any great
                 use-case, so we'd say contentBox and borderBox
  Rossen: At some point there was padding / margin / scroll
  gregwhitworth: Content and border are the only two I'd like to
  Rossen: Comments / objections?

  RESOLVED: Only content and border boxes

device-pixel-border-box removal from spec
  github: https://github.com/w3c/csswg-drafts/issues/3554

  gregwhitworth: So, effectively what this comes down to is that this
                 was a size you could watch, for canvas scenarios
                 this'd be useful because CSS pixels get rounded in
                 some way
  gregwhitworth: Proposal is that for <canvas> only you'd provide the
                 device pixel size of the same dimensions
  Rossen: That's super weird
  gregwhitworth: I agree, that's why aleks was going to propose this
  iank: I can do an argument
  gregwhitworth: The use case is there, the question is whether it
                 makes sense to put the information there instead of
                 in the canvas interface
  <dbaron> +1 to thinking maybe it belongs on canvas, although
           interested in hearing the pro argument tomorrow
  gregwhitworth: We can wait for aleks
  everyone: Let's move this until tomorrow

CSS Tables spec methodology

  fremy: Disclaimer: I don't work at MS anymore, so I'm not biased and
         these are my own interests
  fremy: Main goal when we wrote css-tables was getting more interop
         and sanity
  fremy: One decision we made was that if there is multiple behaviors
         and a majority of browsers have a sane behavior we'd just go
         for that
  fremy: So we have a couple issues where each engine was doing
         something different and thus we did not decide on something
  fremy: but given MS decision of discontinuing Edge there's no tie
         anymore, so according to the rule we should go ahead and put
         some of the WebKit / Blink behavior in the spec
  fremy: So it's mostly a question for Moz folks

  Rossen: I just want to add a few things, first we're sad you're not
          at MS anymore
  Rossen: Motivation behind the spec was developer pain, and having to
          figure out how should a developer fix a bug since there's no
  Rossen: So I had a few devs working a few months just working on
          table interop bugs
  Rossen: and the reasoning was bringing all together and get interop
          into something that is no longer rapidly developed
  Rossen: The other one was to be flexible and allow as little effort
          as possible for implementors
  Rossen: I don't think this needs to change since since most of the
          bugs are not that outrageous, but the fact that Edge is
          going to change the underlying platform I don't think it
          changes the landscape that much
  fremy: The meaning of the effort has changed a bit
  Rossen: I think minimizing the differences in tables is the right
          thing to do, I'm still committed to fixing bugs in Chromium
          if there are clear Chromium bugs

  dbaron: I want to suggest that there's a third option, which is
          putting a thing in the spec with an issue in there with
          multiple options
  dbaron: That gives others an opportunity to review these things
  dbaron: There are probably a bunch of places where FF will have to
          switch to what chrome does
  dbaron: There are a couple things which I may convince Chromium
          folks to do, like assignment of widths not depending on
          ordering of the rows
  dbaron: Otherwise in the cases where both Chromium and WebKit agree
          we're probably going to have to switch
  dbaron: but in the cases where you're not sure whether to hold off
          or put them in the spec, so we can discuss
  fremy: sgtm, I may spend less time reverse engineering Gecko
  fremy: I think it'd be better to just put something sane on the spec
         rather than reverse-engineering two browsers
  dbaron: I think that's fine
  florian: When all browsers agree, webcompat is a constraint, but
           when it disagrees, my feeling is that print formatters have
           smarter tables, so ruling them out without thinking is a
           bit unfortunate
  florian: and we may bring some of it
  fremy: I'm just trying to reduce some of the investigation

  fantasai: So conclusion is if there's behavior difference, note it
            in the spec and file issues to eventually figure out
  fremy: At this point I suspect the tables spec will never be
         completed, is mostly a documentation effort if somebody would
         want to start from scratch it has help to know in which
         direction to fix bugs
  <dbaron> (and actually, Chrome might be better on this row-ordering
           thing than I remembered...)

Declaring Intrinsic Aspect Ratios

  fantasai: Last year we discussed an aspect-ratio property
  fantasai: It's a desired feature in grid and a bunch of other places
  fantasai: so we added one to css-sizing-4

  fantasai: Also, as we've been creating these more flexible / fluid
            layouts, in many designs until we load the image we don't
            know how to lay it out, so when the image loads the layout
            shifts around
  fantasai: ojan has been working on a proposal to get intrinsic ratio
            info into html attributes, via the intrinsicsize attribute
  fantasai: however jensimmons and I think it'd make much more sense
            if we used existing width / height attributes
  fantasai: Right now they're overridden and that information is lost
            if you specify width/height properties in a style rule
  fantasai: However, we could map them them also into the aspect-ratio
  fantasai: so the layout engine would still have the aspect ratio from
            the attributes even if the width/height values are
  fantasai: The advantage of this is that it uses existing HTML
  fantasai: and authors don't have to duplicate.
  fantasai: They're shorter and straight-forward
  fantasai: Only possible compat concern is that we could have a
            behavior difference if you set a width / height attributes
            to an aspect ratio different from the real aspect ratio of
            the image *and* you override them with css to auto values
  <AmeliaBR> `aspect-ratio: calc(attr(width) / attr(height))`
  <AmeliaBR> `<img width="300" height="200" style="width: 100%;
             height: auto"/>`, aspect ratio would remain 3:2
  emilio: _and_ if there's no alt text
  fantasai: Even if the image does load, actually.
  AmeliaBR: And you also have object-fit

  jensimmons: Since responsive design is a thing, most images have
              `width: 100%`
  jensimmons: Before, CMSs would carefully crop the image
  jensimmons: So example is image with `width: 100%; height: auto`,
              and the concern is that it's slower because when it
              loads browser has to relayout
  jensimmons: and fantasai and I think that we can solve it with data
              that's already there

  dbaron: One of the things that surprises me is that these proposals
          are seen as alternatives to each other, I saw them as
  <fantasai> I think aspect-ratio property and intrinsicwidth/
             intrinsicheight attributes can be complementary. We just
             think that by using aspect-ratio in attribute mapping, we
             can re-use width/height attributes instead of adding
  dbaron: One of the things that makes ojan's proposal safe is that it
          allows CMSs to be safe without being able to thrash layout
  dbaron: If you can fix a CMS you can fix a bunch of stuff, but
          that's not safe to do with `width` and `height`
  AmeliaBR: That's only if you don't have `height: auto`
  AmeliaBR: Only if somebody starts doing intrinsic aspect ratios,
            needs to change some CSS instead of adding a new attribute

  florian: <summarizes>: fantasai's proposal doesn't break existing
           content, but if a CMS starts outputting width and height

  Scribe: heycam

  ojan: The reason we went with new attributes is concern with cases
        like <width=300 height=200 style="width: 100%; height: auto
  fantasai: Either it matches the aspect ratio and you're shrinking/
            growing, or you're skewing the image
  fantasai: in which case it probably looks a bit weird
  gregwhitworth: Could be a pattern
  fantasai: When you put width:100%;height:auto;, you want to use the
            actual aspect ratio of the image
  ojan: What dbaron was saying matched my mental model. The CMS thing
        is a huge thing -- if they can safely do this without breaking
        the page
  ojan: Someone from cloudflare is interested in doing this
  ojan: and is concerned with the current way of mapping aspect-ratio
  ojan: So that constraint seems important

  ojan: Other thing is whether to add a new attribute or not, correct?
  ojan: It is not at odds with the aspect-ratio property in CSS
  ojan: In both case you want it in CSS, and if you base it on width/
        height attributes [...]
  fantasai: We're suggesting the UA default style sheet has a rule
            that is equivalent to "aspect-ratio: attr(width) / attr
  fantasai: at the attribute mapping code level, it gets injected into
            the cascade below author styles
  fantasai: that's in addition to mapping width="" attr to width
            property, height to height.
  ojan: Really all we're talking about is whether it should it be
        called intrinsicsize or ...
  dbaron: But he's seeing there are other reasons to add new attributes

  jensimmons: The original purpose of aspect-ratio is for things that
              don't have intrinsic aspect ratios like on a div
  jensimmons: In the course of defining it we realized it could also
              be used by browser makers to solve this problem -- how
              do we improve perf of image loading / layout
  jensimmons: Seems like a great idea
  jensimmons: We realized we can avoid having to add a new set of
              attrs by mapping into the aspect-ratio property for this
              performance enhancement
  jensimmons: Maybe there are use cases where this prop isn't enough,
              and we do need to add new attrs
  jensimmons: from where we're standing it doesn't seem that way
  jensimmons: If we don't need them, seems like a good idea not to add

  florian: There is one case where that approach breaks
  florian: but the hypothesis is that case doesn't matter
  florian: Once <img width=300 height=200 style="width: 100%; height:
           auto"> loads, the width/height attributes are ignored
  florian: In the new proposal they would start applying, they would
           have an effect
  florian: but right now it uses intrinsics

  dbaron: Another case breaking CMS -- say you have an image that is
          100x200, and you have it in <img width="300">
  dbaron: so you're scaling the image up x3
  dbaron: The CMS could add intrinsicwidth=100 instinsicheight=200 and
          it would still get scaled up, no CSS involved
  dbaron: If you want the CMS to add an attr that exists today, it now
          needs to figure out what to do with the attribute already
          there it wanted to replace
  florian: That's a different case of compat
  florian: We were only talking about compat with existing content
  dbaron: But I think it's an important part of ojan's proposal, which
          I think is why it's valid to want both things
  fantasai: But that's not hard for the CMS to solve
  fantasai: It looks, it's supposed to be 300, calculate the aspect
            ratio, output it
  dbaron: The CMS would have to figure out if CSS style applies to the
  fantasai: Alternatively, the CMS could see that there is a width
            attr and no height attr, skip this image?
  dbaron: Now the fix isn't as effective
  fantasai: How many images only have one dimension specified? In a
            CMS that will be upgraded to have these attributes?
  fantasai: And is making that situation easier worth making everyone
            else use a new set of attributes?

[Meeting closed]
Received on Tuesday, 26 March 2019 19:29:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:53:13 UTC