[CSSWG] Minutes and Resolutions San Diego F2F 2012-08-29 Noonish: Images Level 4, FPWD Criteria

[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

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

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

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