- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 26 Mar 2019 22:28:54 +0300
- 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.
ResizeObserver
--------------
- 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.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/sf-2019
Scribe: emilio
Selectors
=========
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
pseudo-class
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
can.
dbaron: In many cases, the sites themselves have not gathered that
data.
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
news
hober: it's pretty common to visually filter out the things that are
visited
hober: so it'd decrease the usefulness of sites we know are very
popular
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
about
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
fonts
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
it
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
stored.
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
link
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
deep.
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
confusion...
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
cheap?
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
interaction
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
attacks
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.
ResizeObserver
==============
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
wrappers
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
fragment
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 -
https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=6713
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
won't)
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
fragmentation
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
expectation...
<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
propose
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
one
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
spec
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
property
fantasai: so the layout engine would still have the aspect ratio from
the attributes even if the width/height values are
overwritten
fantasai: The advantage of this is that it uses existing HTML
attributes
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
complementary
<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
intrinsciwidth/intrinsicheight
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
attributes
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
(height)"
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
img
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