- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 29 Aug 2012 00:22:46 -0700
- To: "www-style@w3.org" <www-style@w3.org>
[Sorry for the seeming repost; I forgot the second half]
CSS Images Level 4: image-set()
-------------------------------
Discussed image-set(), various issues were raised, including:
- Whether to have x as a synonym for dppx?
Multiple opinions expressed.
- Whether the UA just picks one and fails after trying, or whether
it should fall back to something else in the list if the image
fails to load?
CSSWG .prefers fallback within image-set() to work.
- Whether it should be allowed to nest?
Agreement to disallow nesting.
Raised/reraised and discussed various issues wrt element(), including:
- Whether to allow full selectors, or just IDs?
- Whether pointing to SVG paint servers is a use case,
or is already handled by url() references?
- Can it point to a single page of a paged view?
- How can it handle reflections?
- How can it reference DOM elements not inserted in the document?
- Naming conflict with GCPM element()?
- Is it drawn as a real or pseudo-stacking context?
RESOLVED: Publish FPWD of Images Level 4
FPWD Criteria
-------------
Briefly discussed criteria for deciding on FPWD. Proposed criteria were:
1. Scope is clear.
2. We agree on the approach take to solve the problem.
3. Understandable by 3rd parties.
4. Enough of a priority that we should be doing it now.
RESOLVED: Principles 1-3 for publishing FWPD. No consensus on 4.
====== Full minutes below ======
CSS Images Level 4
------------------
Tab Atkins reviews additions to Images Level 4
Topic: image-set()
regarding responsive images
shows example 10
TabAtkins: describes the example
TabAtkins: 1x, 2x, 600dpi
daniel: why not use media queries?
TabAtkins: defining connection speed, and when you want to download
something is VERY difficult
TabAtkins: even just doing 2 modes low/high is difficult.
Florian: This allows the browser to only download one
TabAtkins: can also result in perverse behavior
TabAtkins: if you have a highspeed connection, downloading big image,
then go into a tunnel, and mq would switch to low-res even
though you already have the highres big image
hober: mqs are about the display
florian: if we're dealing with bandwidth, there's no way to do with mqs
florian: OTOH dealing with bandwidth is so hard, that not convinced
browser may be able to do it anyway
TabAtkins: quality of implementation
TabAtkins: browser can do better
florian: if no one does better then this was pointless
florian: would be nice if browsers did something with bandwidth though
<hober> See also "Why a scale factor and not a full-blown media query" in
http://lists.w3.org/Archives/Public/www-style/2012Feb/1103.html
vincent: src-set?
TabAtkins: this is the css version of src-set
TabAtkins: 3 issues
TabAtkins: 1. inconsistency with src-set
TabAtkins: suggestion: be consistent
hober: agreed
TabAtkins: I do have one bit I'd like to keep
TabAtkins: you can specify a fallback color at end
TabAtkins: useful if browser can't download any image
TabAtkins: or on such a bad connection, browser decides to not download
TabAtkins: and just use color
TabAtkins: but we should drop other fallbacks.
hober: this is nice
vincent: i have a question
vincent: user agent is presented with list of possible things, hints about resolution
vincent: what if i have vector image for fallback
vincent: but doesn't have hinting
vincent: sometimes for icons you want hinting
vincent: in cases like that am I still allowed to make those trade-offs?
vincent: vector is high resolution but has benefit of being tiny
vincent: would that be possible?
TabAtkins: so on a highres device use SVG, on lowres use icon?
florian: and on a low bandwidth use SVG
TabAtkins: I think you can do that
TabAtkins: with 2 diff resolution descriptors
TabAtkins: one very high resolution, and one very low bandwidth
florian: syntax is not ideal, but it is possible
fantasai: vincent's point/scenario above is a good one to note
TabAtkins: don't adjust the resolution if you choose the image
TabAtkins: this is for a high res device, but nothing special has to
be done to it.
ACTION TabAtkins: to address issue of where to put an SVG image for
high resolution and low bandwidth in image-set.
<trackbot> Created ACTION-499
vincent: in the version of image-set and src-set, there was more than
just resolution, e.g. width/height
TabAtkins: the reason is that src-set in HTML also allows width/height
TabAtkins: that doesn't show up in image-set
TabAtkins: because they are just MQs
TabAtkins: you can do those easily in CSS
TabAtkins: but you can't in HTML, that's why they're in src-set
* sylvaing finds srcset unreadable
Florian: the question is whether you can use full MQ syntax in HTML
Florian: some don't want to, hence those features in the HTML version
separate from MQs.
vincent: another issue was co-location of rules in style sheets
vincent: e.g. your image resource in one place
vincent: various conditions under which it would be used
vincent: are you considering that now?
TabAtkins: I remember seeing that suggestion
TabAtkins: this is not the right place to address that
TabAtkins: if we want to address MQs move conditions too far
TabAtkins: away from properties
TabAtkins: then we should address that by allowing nesting MQs
TabAtkins: not just for image functionality.
Peter: I like aligning with src-set, but I see the fallback behavior
as useful.
Hober: purpose of the image function to do the decode fall back thing
Hober: they're composable.
Peter: combining them will get ugly
Hober: combining them is not a common use-case
Peter: what will happen is someone point to one version then a high
resolution
Peter: and print version will get lost / 404
[then nothing prints]
TabAtkins: my use-case for this is being able to send down just one image
TabAtkins: rather than having to download multiple versions
TabAtkins: extra latency can be very harmful to page behavior
Peter: the fallback behavior is, pick the right one, try to download it,
only if that fails, then you try the next one.
TabAtkins: but that causes the bad behavior
florian: you're choosing between slow display and no display
dbaron: the other question is when do authors see that things are broken?
dbaron: e.g. if it goes and downloads a different one, then authors
won't notice first problem.
Peter: then it gets back to philosophy debate of how things should fail
gracefully or not
Peter: whether you should have a fail-early mode for authors to check their pages
Peter: in general browsers tend to do the right thing for users
Florian: how about we keep the fallback behavior and ask src-set to add it
florian: there is no downside for them here that's not here for us
florian: the one case it is actually worse, long list of many image,
you try all of them, they all fail, and you're on a slow
connection
hober: having a combination allows the author to explicitly choose what
they want to do in those scenarios.
fantasai: then you have to repeat. e.g.
fantasai: combinatorial explosion of image sets within image sets
florian: if you put image-set in image then you can't know which part of
the image will fail to load, you can't tell the browser which
one to load, the answer is to next them the other way around.
fantasai: you have to repeat the entire list
TabAtkins: the alternate way is, here is a fallback image if you can't
use the one in the image-set
florian: unless the fallback is the one that failed to load
florian: then you need a fallback for the fallback
peter: the other problem is different fallback behaviors
peter: e.g. if browser picks medium one, and it fails, which one should
it fallback to?
hober: the author should choose
peter: doesn't know what the browser is seeing
florian: add MQs on top of that then
florian: this is going to be a mess
hober: does anyone want to implement the crazy fallback situation in
this case?
fantasai: it's just like having image() but browser gets to pick the order
florian: we can try to align, and then make src-set align, and then if
they refuse we can revisit
florian: it doesn't slow down the main use case
TabAtkins: it doesn't slow down the everything works case, we care about
the recovery behavior
TabAtkins: whether to do more connections automatically
TabAtkins: or have the author make that choice explicitly
TabAtkins: most people on mobile connections don't want to download more
connections
Hober: point is to avoid extra connections
Peter: no, point is to pick the right image
florian: downloading both to figure out which one to use is a waste of time
florian: but once you've picked your first choice and it fails,
either you look like crap or you don't
peter: on a retina display, if high res version fails
peter: then I'm going to fallback with lower res version
peter: going to wind up with smaller data usage
florian: I think we should ask src-set to get the fallback behavior as well
TabAtkins: I'm fine with that
TabAtkins: asking HTML about that
<Bert> q+ to say that SMIL, SVG, HTML and probably others all have solved
or are trying to solve this same pb. Maybe it is time for a
language-independent solution? Or we could just use SVG, which
CSS already imports anyway.
Bert: I'm wondering given all the other things we have to talk about
Bert: should we really be discussing this?
Bert: we can just use SVG
TabAtkins: it has nothing to do with resolution negotiation
Bert: SVG uses SMIL
Bert: switch statement
Florian: does not take bandwidth into account
Bert: lots of work on this
Bert: why are we doing it at all?
florian: HTML is solving it for content, we need it for css
bert: should it be solved independent?
<Bert> (Re bandwidth: the SWITCH element does take bandwidth into
account, via the systemBitrate attribute.)
NEXT ISSUE
2 of 3
TabAtkins: the x unit
TabAtkins: it is a synonym for dppx unit
TabAtkins: should it use resolution unit
TabAtkins: or ...
TabAtkins: (summarizes issue)
Peter: I don't think we should have the 'x' unit
Peter: I don't want a synonym
Hober: x just describes a scale factor
florian: HTML has the x unit
florian: we have the resolution thing already and not care about the x
hober: the resolution units are terrible and we shouldn't propagate them
further
TabAtkins and hober argue about dpi vs dppx
florian: I think using resolution here is fine, I don't think we need 'x'
TabAtkins: dppx is the worst name for a unit
TabAtkins: ddpx is an easy typo to make
TabAtkins: it's done a lot
fantasai: Isn't it too late to change now? we have a CR
fantasai: we have implementations
TabAtkins: dpi or dpcm?
szilles: it's not going to please half of the people
TabAtkins: we are in a worse situation if we leave it to we already
invented a crappy unit, and we don't want a better unit
Vincent: question - one is resolution vs length?
TabAtkins: no, dppx is dots per pixel. not a length.
<dbaron> I actually think x as a synonym for dppx is pretty reasonable.
florian: just use resolution here, in addition if you want 'x' to be a
synonym, let's discuss elsewhere
florian: if we introduce 'x' i want it everywhere
TabAtkins: that's the proposal
NEXT ISSUE
3 of 3
actually "ISSUE 1" in current draft of spec (URL?)
TabAtkins: image-set() inside itself is an issue
explains how nesting them makes no sense at all
TabAtkins: we can either disallow it
<hober> image-set(image-set(foo 1x, bar 2x) 2x, baz 1x)
<hober> (and you choose foo)
Tabatkins: but then you have to search arbitrarily deep
fantasai: I suggest disallowing that example
hober: am ok with disallowing
hober: but still doable
TabAtkins: am fine with disallowing
molly: when we start looking at syntax of this nature, designers
will freak out
molly: I can see it turning into a horrible problem
florian: someone writes a blog post ... gets copy pasted everywhere
Molly: i'm concerned with the syntax
Molly: I just want to advocate always keeping syntax in CSS as human
as possible
Molly: the nesting starts to look confusing
* hober notes "as human as possible" is a great argument against dppx
TabAtkins: agreed in general, nesting functions is usually confusing
<br type="lunch"/>
Scribe: fantasai
<tantek> still in css4-images
<tantek> section 4.4
Tab: Right now syntax is limited to ID selector
Tab: Bit limiting -- means you have to attach an ID to the element
Tab: Some thoughts on how to extend this
Tab: firstly, arbitrary selectors. Represent first such element in
the document
dbaron: Seems potentially expensive for dynamic updates
fantasai: I don't see very strong reasons to have that vs. ID selectors,
there are no implementations, would prefer to defer this to
another level
Tab: ok, I'm ok with that
Tab: Secondary one, should be able to point to SVG paint servers
Tab: Problem is you have to literally embed SVG into the HTML
Tab: If you want to use across style sheets, have to duplicate the SVG
in every document
Tab: would be nice to point at an external SVG document
dbaron: Does that do anything that an SVG rect with fill property
wouldn't do?
Tab: I guess not ...
fantasai: Would that work for all fills, including patterns etc.?
dbaron: Think so
fantasai: So why do we want to point to paint servers if we can just
point to SVG?
fantasai: I think we do want to make sure we can pull SVG gradients/pattersn/etc
out of an SVG document *somehow*
dbaron: Not sure it adds any complexity to what we're doing in any case
<florian> A use case I would like to see addressed is to be able to
select a page as generated by overflow:paged as the source
of element(), so that a visual index of pages can be created
and used to navigate through a interactive paginated document.
Tab: How do we point to something not in the document?
Tab: Use case of creating a canvas element in script, using it in
various other places
Tab: Right now have to put the canvas in the document with display: none
Tab: Ideally can use it via script
Tab: Mozilla can do that currently, not sure it's ideal
Tab: It aliases an ID to point to a particular image element (which may
or may not be in a document)
Tab: In a previous draft I had this take either ident or ID selector
Tab: But that conflicted with wanting an arbitrary selector
Tab: If we don't end up wanting arbitrary selectors...
Florian: Haven't found another way to select arbitrary pages etc.
Tab: If we don't need URLs, we can just use the string for that
dbaron: could also just have two function names
Tab: Seems a little bit messy, but not opposed
fantasai: Also have element() name conflict with gcpm as an issue
Tab: issue on how to make an element not in the document to be available
Tab: FF does a name-mapping
Tab: Another option is to just have a map, hanging off of the document
Tab: document.CSSElementMap() to make a map
Tab: don't know if any real benefit to one or another
<smfr> webkit already has a kind of map for -webkit-canvas
<smfr> document.getCanvasContext() or something
side discussion on selector matching of multiple elements with same ID
fantasai: one of the main use cases for this originally was reflections.
How does this solve reflections?
Tab: You would give the element an ID, and then create a rule for that
element
fantasai: But I can't say "I want these 5 icons to do reflections"
Tab: Yeah, you'd have to handle each one individually
dbaron: There've been lots of interesting demos of this functionality,
but don't remember how reflections were handled
<smfr> maybe you need a special selector for "the element the style is
applied to"
<fantasai> Wouldn't that be :scope? or :context, whatever it's called
* smfr finds http://www.w3.org/TR/selectors4/#scope-pseudo
glazou: Here's an idea is to use an IDREF
glazou: selector:after { content: element(attr(id)); } or somesuch
Molly: I look at syntax like this and I just want us to be aware that
we might be crossing the understandability line.
<smfr> sucks to have to add IDs to everything that needs to be reflected
Molly: The more it looks like programming, the harder it is for visual
designers to follow
fantasai: I think we need to start threads on www-style for all of these
Tab: It appears from mailing list conversation that element is rendered
as a stacking context
fantasai: real or pseudo?
Tab: real
Tab: Do we require that thing is already a stacking context? Draw it as
a real stacking context as we draw element()? Or figure out how to
work around the issues somehow
Tab: Need ppl working on rendering engines to comment
Tab: people like smfr
<sylvaing> smfr, skype w3c-csswg?
ACTION: TabAtkins start threads for each issue and track them all
<TabAtkins> smfr, further problem with glazou's suggestion is that that
kind of reference violates the cycle-detection, and since
it's not a special-case itself, it's hard to special-case
it in the rendering algorithm.
<TabAtkins> smfr, an explicit value like "self" or "parent" or whatever
would let us special-case that, and say that the element
using that image isn't rendered in the production of said
image.
<smfr> oh, right, ick, you'd have to avoid infinite reflections...
<krit> To the referencing of paint servers. The SVG WG is looking into
it as well. And we want to point to paint servers in general,
also external resources
<krit> Therefore element() should support any IRI like SVG does with
fill and stroke already
Criteria for FPWD
-----------------
Tab requests fpwd of css4-images
szilles: Having a trouble figuring out FPWD criteria here
szilles: We're not terribly consistent about that.
fantasai: Think it's that the WG agrees to work on this thing, roughly
in the form it's in although there may be many open issues.
No objections to the conceptual design
szilles: So it has sufficient content that the scope is reasonably clear
Florian: And the draft is understandable to people outside the WG
Florian: 1. Scope needs to be clear.
2. We agree on the approach take to solve the problem.
3. Understandable by 3rd parties.
jdaggett: I would add 4. It's enough of a priority that we should be
doing it now.
jdaggett: Think we should be waiting on things that are lower priority.
<dbaron> (To be clear, this is a discussion about our general requirements
for FPWD.)
RESOLVED: Publish css4-images FPWD
RESOLVED: Principles 1-3 for publishing FWPD. No consensus on 4.
dbaron: People criticize us for not getting things done; yet we spend
time on whatever anyone brings up.
Bert: It's hard to stop people from working on things if that's what
they want to do. Can only stop them from publishing. So I like
#4, but not sure it makes a difference in practice.
glazou: Nobody cares about FWPD vs. ED. If we block FPWD, that doesn't
have any effect, people will implement ED without FPWD.
plinss: If you feel that group is not managing priorities well, that's
a separate discussion.
Received on Wednesday, 29 August 2012 07:23:19 UTC