FXTF F2F Seattle 29 January 2014 minutes

Minutes from the F2F below (html version attached).

   - DRAFT -
FXTF F2F Seattle 2014
29 Jan 2014
Attendees
Present
Regrets
Chair
ed
Scribe
birtles
Contents
Topics
Blending & Compositing CR
Masking LC/CR, remaining issues?
ability to specify gradient midpoints
fill/stroke with background syntax
media query variables (aka css aliases)
CSSOM Value-based API
Custom filters removed?
backgrounds and colors and outlines in SVG
Summary of Action Items



  <sgalineau> call-in instructions in Location section of  
http://wiki.csswg.org/planning/seattle-2014


  <TabAtkins> ScribeNick: TabAtkins
Blending & Compositing CR

  <SimonSapin> (off topic) TabAtkins, I kinda feel display-box should be a  
longhand of display

  Nope, you don't. We had discussions about this, it's a very very bad idea.

  I can epxlain later.

  <smfr> http://dev.w3.org/fxtf/compositing-1/

  <ChrisL> spec link?

cabanier_: We changed the sections from 4 onward to be normative.
  ... There was a 3-week period for comments.
  ... There was a comment from Eric about a stale ref, which I removed.
  ... I've prepared a DoC.
  ... And we've been working on test cases.
  ... People have been contributing quite a few tests.
  ... Working on impl in 3 browsers.
  ... Right now, FF is probably the most stable.

heycam: Did you do all three?

cabanier_: No, separate engineers.
  ... People have begun experimenting quite a bit with it. We've done  
almost no evangelizing, but people get excited anyway.
  ... Some person made a bunch of cool demos:

  <cabanier_> codepen: http://codepen.io/collection/Kgshi/

cabanier_: [shows off some of the demos]
  ... So right now I think we're ready for CR.

TabAtkins: I've been meaning to suggest some editorial rewrites for some  
time, but that shouldn't block CR.

smfr: You've got some theoretical sections - I'd like to see more examples  
showing which CSS properties I can use to get each of the effects you're  
talking about.
  ... Like section 10.

krit: Canvas also uses this stuff.

smfr: Right, but I'd still like to see a simple CSS example.

  ACTION rik to provide more CSS examples in the Compositing spec.

  <trackbot> Error finding 'rik'. You can review and register nicknames at  
<http://www.w3.org/Style/CSS/Tracker/users>.

  ACTION cabanier to provide more CSS examples in the Compositing spec.

  <trackbot> Error finding 'cabanier'. You can review and register  
nicknames at <http://www.w3.org/Style/CSS/Tracker/users>.

  ACTION rcabanier to provide more CSS examples in the Compositing spec.

  <trackbot> Error finding 'rcabanier'. You can review and register  
nicknames at <http://www.w3.org/Style/CSS/Tracker/users>.

  ACTION krit to action Rik to provide more CSS examples in the Compositing  
spec.

  <trackbot> Created ACTION-616 - Action rik to provide more css examples  
in the compositing spec. [on Dirk Schulze - due 2014-02-05].

heycam: What were the LC issues?

cabanier_: Just one from Erik, about a stale ref.

ChrisL: You still have a link to SVG Tiny in your abstract. It should be  
changed to SVG 1.1.

  Action krit to change the Abstract link to SVG 1.1 in Compositing.

  <trackbot> Created ACTION-617 - Change the abstract link to svg 1.1 in  
compositing. [on Dirk Schulze - due 2014-02-05].

heycam: The other changes in your DoC, what are they?

  <ed> it should also use the referencing syntax in the abstract, like  
"...sometext... [SVG11]"

cabanier_: They were from the previous LC.

ChrisL: You'd usually start a new DoC. Helps with patent issues.

  action krit to action rik to reduce the DoC to only the issues from this  
LC.

  <trackbot> Created ACTION-618 - Action rik to reduce the doc to only the  
issues from this lc. [on Dirk Schulze - due 2014-02-05].

ChrisL: [something about the wording of the abstract regarding the  
2dcontext reference]

  <ChrisL> its ambiguous on which spec is the normative definition

plinss: How are we on tests?

  <cabanier_> tests:  
https://github.com/w3c/csswg-test/tree/master/contributors/adobe/submitted/css-compositing

cabanier_: [brings up the repo with tests]

RESOLUTION: Compositing to CR, pending the edit nits brought up today.
Masking LC/CR, remaining issues?

krit: During the LC period I got a comment and an objection.
  ... clip-mask/etc take a <shape-box> argument.
  ... Which determines what box the coords are resolved against.
  ... Currently we're using the box keywords from B&B, plus margin-box.
  ... SVG objected.
  ... They make sense for CSS/HTML, but how do they apply to SVG?
  ... In SVG we have "bounding box", which is a tight bound around the  
shape.
  ... This doesn't include strokes/etc, just geometry.
  ... So we also have "stroke bounding box" which includes stroke/markers.
  ... Earlier in the week, we also discussed "viewport" in SVG. People  
asked about using the SVG viewport as the reference shape.
  ... Scaling coordinates by the viewport is actually rather common in SVG.
  ... So SVG thought it would be confusing to have "content-box" mean  
"bounding box".
  ... Similarly for stroke-bounding-box, and viewport of the SVG.
  ... I personally don't want to add three more keywords.
  ... I think content-box and bounding box are close enough to be useful to  
just use content-box.
  ... Similarly, I think border-box and stroke bounding box are probably  
close enough.

smfr: What about the bounds of filtered pixels?

krit: People suggested painted bounding box, but that's very expensive.

TabAtkins: Also infinite in some cases, such as blurs.

smfr: Does CSS define the bounds of box-shadow?

dbaron: No. Also, probably impossible.

heycam: I think I'd like to have all of the CSS-related names map to a  
single SVG-related one, like maybe "bounding-box", and also have  
SVG-specific keywords.
  ... I'd like to match the names up with getBBox extensions.
  ... Right now we have getBBox() and getStrokeBBox(), but we should  
probably have it take a dictionary of things to include.

krit: Does that imply we need another keyword for markers?
  ... Does the CSSWG support doing extra SVG-only keywords?

TabAtkins: I'm fine with it.

florian: Me too.

heycam: Does the CSSWG think it's a good idea to do the mapping between  
CSS and SVG?

TabAtkins: I think content=>geometry and border=>stroke kinda make sense,  
but there's no padding analog in SVG, nor marker analog in CSS, so it's a  
bad idea overall.
  ... I suggest for the svg boxes: svg([marker || stroke]?), similar to the  
bbox methods.

krit: I think it's [marker | stroke] - one implies the other.

heycam: Maybe not.

krit: Viewport.

TabAtkins: Don't want it at top-level, because it's a different meaning  
than CSS's viewport.

krit: So svg([[marker || stroke] | viewport])

heycam: I think it's weird to name it svg().

krit: Fallback to the initial value (border-box) if you specify svg() on  
an non-SVG element. Fallback to svg() (object bounding box) for reverse.
  ... So we also need this in mask-origin, mask-clip.
  ... Example: clip-path: circle() svg(marker);
  ... Circle starting in the center of the marker box, radisu equal to  
closest side.

heycam: Does the default-fixing (for putting svg() on an HTML element)  
happen at computed-value time?

TabAtkins: I think so, yeah.

smfr: Yeah, possible.

dbaron: Yeah. Maybe annoying.

krit: We may have the same problem in SVG later.
  ... If we take in CSS Shapes, for example.

ed: Would it be worth having the "fill" keyword there as well?

TabAtkins: Hm, I think so.

  <ed> having svg(fill || stroke || markers) would also match up with the  
paint-order property syntax

heycam: SVG text, the default getbbox() for text actually unions the glyph  
cells (rectangles). Same here?

krit: Yeah.

  <ed> spec link for paint-order, for reference:  
https://svgwg.org/svg2-draft/painting.html#PaintOrder

Bert: I think it's weird to see a function without parameters inside, like  
"svg()".

TabAtkins: You can say "svg(fill)" if you want.

heycam: Or just leave it alone - you'll get that behavior by default.

  <smfr> smfr: should we use up a function called svg() for something that  
retuns a box? Why not svg-box()?

smfr: I think it's a weird namespacing hack to use svg() here.

krit: My pref is to just use the keywords directly, and only allow one.  
Define them to be hierarchical - fill is inside stroke is inside marker is  
inside viewport.

TabAtkins: Still don't like "viewport" as raw keyword.

krit: viewbox?

heycam: I think it's maybe useful which ones to include. Maybe we can  
defer.

  <ChrisL> we have (geometric) bbox and decorated-bbox which includes  
stroke width, markers etc

heycam: I'd probably be okay with just keywords for now, and do union  
stuff later.
  ... Maybe use the words boudning-box, stroke-boudning-box,  
decorated-bounding-box, and...?

krit: viewbox?

heycam: Too wordy. fill/stroke
  ... Leave off marker for now, since I want it to actually mean the  
markers, not marker+stroke+fill.

TabAtkins: But you're okay with stroke meaning fill+stroke?

heycam: It does automatically - stroke bounding box is a superset of fill  
bounding box.

krit: Anyway, resolve on these and figure out details in the SVGWG meeting?

RESOLUTION: Use the keywords fill/stroke/viewbox for  
clip-path/mask-origin/mask-clip.

ed: The viewbox keyword, is that the viewport or the viewbox?

krit: They're the same geometric area.

TabAtkins: Only difference is the coord system established in each. And  
the shape functions so far don't use user-space units, so you can't detect  
that.

heycam: And if we did allow, viewbox is what you'd want.

krit: Last issue we discussed on Monday.
  ... about usou and obb.

TabAtkins: Just do what roc said.

krit: [explains the issue again for SVGWG people]

RESOLUTION: Use roc's definition of obb/usou in HTML content - same  
geometry, coord space is 1 user-space unit wide/tall in obb, user-space  
unit = CSS px in usou.

krit: I'd like to publish a new WD.

RESOLUTION: New WD for Masking.

  <birtles> ScribeNick: birtles
ability to specify gradient midpoints

  <scribe> Scribe: birtles

cabanier_: I wanted to show why there is a need for an explicit midpoint  
for gradients

TabAtkins: this is already in CSS Images 4
  ... if you just omit the color

cabanier_: but some people were confused by that... it doesn't really work
  ... I created this little application

  <cabanier_> sample application: http://codepen.io/adobe/full/fhnBJ

cabanier_: by clicking on the gradient line you can add color stuff
  ... and by dragging it to the left, you can see this effect as you  
approach the edge
  ... a line starts to appear
  ... your eyes play tricks on you
  ... if you copy this and enlarge in photoshop you'll see this line is  
actually not there
  ... it's just your eyes
  ... but to get rid of that you can add a midpoint
  ... and drag it along

  <cabanier_> example of the formula:  
http://codepen.io/adobe/pen/ced9e76d276a1d6613b529e8524e4cad

cabanier_: you fill it in with this formula
  ... by doing it this way you avoid the line
  ... you create a curve that avoids the appearance of sharp changes

TabAtkins: is there a theoretical justification for this formula?

ChrisL: yes, it's based on a power distribution
  ... it gives you curves but it doesn't give you continuity at where the  
curves join
  ... it's an improvement but it doesn't accomplish everything
  ... people think you can fix this by adding more color stops but apart  
 from enlarging your code

smfr: if we're using CoreGraphics which doesn't have this can we support  
this by adding color stops in the UA?

cabanier_: yes

florian: getting back to Chris' point, you will still have parts that  
aren't smooth
  ... should we try to solve that in one go?

cabanier_: not really, maybe in the future

TabAtkins: what would happen if you added multiple midpoints?

ChrisL: one describes a curve, two or more--the behavior is not defined  
and is not used in practice

TabAtkins: so more than one would be a syntax error

ChrisL: yes

leif: I saw a similar effect when dragging the stop and midpoint to the  
right

cabanier_: that's due to the response curve since your device is not linear
  ... that requires a different solution

heycam: we already have that in SVG, you can specify interpolation in  
linear or sRGB

cabanier_: yes

ChrisL: we don't yet have a way to ask for a smooth curve through points  
in a color space with C1 continuity
  ... although we do have that for paths now
  ... with Catmull-Rom curves in SVG2

RESOLUTION: change CSS Images 4's specification of colorless color stops  
to use Rik's proposal (i.e. use power curves)
fill/stroke with background syntax

krit: we decided we want to have fill/stroke properties on text in  
general, not just SVG shapes
  ... however, lately we realised we don't just want SVG paint servers but  
also images
  ... so you can use regular CSS images etc.
  ... the difficulty comes from referencing images that have fixed size
  ... if the area you are painting differs from the size of the image
  ... what do you do

ChrisL: that problem has already been solved for backgrounds

krit: yes that is the proposal
  ... but roc suggested we don't support attachment

smfr: what is the property?

TabAtkins: you can use 'fill' etc. on text

smfr: what is the bounding box

TabAtkins: I think we were going to use the box of the text?

smfr: use the background bounding box

heycam: with the box decoration break, it's not too much trouble to paint  
the text over and over again?

krit: without attachment you can't simulate some behaviors of  
-webkit-background-clip: text

smfr: the geometry of the image filling is exactly the same the geometry  
backgrounds will use

krit: the question here is not so much about painting CSS text but first  
how to use fill/stroke in SVG
  ... what do we do in SVG for multiple fill layers?
  ... I would like to use the same syntax as for background but without  
introducing extra properties
  ... we can do that later

  <dbaron> -webkit-background-clip: text -> background-clip: -webkit-text;

krit: for now just have the one property specifying the multiple layers

heycam: what are the different parts of background?
  ... if we are going to do some, we should do all?
  ... often you want multiple backgrounds so you can layer them all at once  
without doing different sizes
  ... do we need that complexity in SVG?

krit: it just falls out

heycam: as long as you can re-use your existing background stuff, then  
it's ok

TabAtkins: do you want to do the same thing for stroke?

krit: yes

smfr: so would you repeat the image like we do for backgrounds?

krit: yes, with the same syntax

TabAtkins: for SVG we'll ignore the <box> part of the production for  
<bg-layer>?

krit: not necessarily
  ... you might want to repeat the image

TabAtkins: that's <bg-size>
  ... the values for <box> don't make any sense for SVG
  ... do we want to add the SVG ones there?
  ... ('fill', 'stroke') etc.?

smfr: does fill/stroke just control what gets painted?

TabAtkins: yes

smfr: it seems a bit odd, different to what we have in CSS
  ... we can't do layered borders

krit: attachment doesn't make sense for SVG for now so it will just be  
ignored
  ... we might want to leave it out of the syntax

heycam: perhaps later we can talk about different stroke widths for each  
item in the list

smfr: it's interesting that you can do something in SVG that you can't do  
in CSS, namely repeating an image around the border

krit: I wanted to bring it up today because it's a CSS property and  
because we will use these properties for text in the future

ChrisL: it is nice for HTML to be able to color text with something other  
than a solid fill

TabAtkins: we can add attachment later and add it later if we decide it is  
sufficiently useful

RESOLUTION: Import the background shorthand syntax for multi-fill and  
multi-stroke into SVG minus the attachment part of the syntax

  <smfr> topic options: media queries, variables, CSS OM,
media query variables (aka css aliases)

  <dbaron> http://tabatkins.github.io/specs/css-aliases/

TabAtkins: CSS variables work really well for a lot of use cases but for  
some CSS preprocessors are still better
  ... for example, if you have an extended media queries, you are out of  
luck
  ... this is a proposal to define aliases
  ... it includes a declarative form that is equivalent to what  
preprocessors can do today plus a script-based form that extends it further
  ... this is my current proposal for declaring a custom media query
  ... this is a restriction that the custom name must contain and underscore
  ... there is a similar restriction in HTML where you want to define  
custom elements without clashing
  ... in that case they got around this by using dashes
  ... you have to include a dash in a custom element name
  ... in the same way, this requires underscores
  ... <idents> can use underscores but we've never used them

heycam: will you remove underscores from <ident>

TabAtkins: no, <ident> still includes them but we the language never use it

glazou: it seems like you're defining a media type

  <dbaron> (glazou doesn't like the parentheses)

TabAtkins: it's actually defining a media feature
  ... you need to use parentheses in @media since it's not a media feature
  ... but authors will soon stumble across that and work it out
  ... it should also be possible to set up a media feature via javascript
  ... you should then also be able to test for that feature using CSS  
markup including : and <
  ... the javascript can define a boolean, number or string
  ... this allows the style to react to something in its environment that  
can be controlled from script
  ... so modernizr could use this rather than defining styles on the body

dbaron: is there a use case for being able to set lengths

TabAtkins: probably but I'd like to defer that until I talk about OM
  ... I think it depends on what we decide on OM
  ... so I'd like to add that later

smfr: can you unset values?

TabAtkins: this is just a map so you can just unset as usual

SimonSapin: would the map already include the ones defined in markup

TabAtkins: yes, and I'd have to define the order

  <dbaron> dbaron: Can you put @custom-media instide other conditional  
rules (esp. @supports)?

TabAtkins: I assume no, the definitions are probably global but I can  
change this depending on what is reasonable for implementation

  <dbaron> dbaron: I'm fine with no.

TabAtkins: I haven't specified it here, but for example, if defined twice  
the last one wins, javascript wins over markup etc.
  ... standard precedence stuff

  <dbaron> TabAtkins: Also, no need for custom @supports stuff because you  
can use CSS.customMedia.set() with results of supports queries

heycam: I don't think we should have MapClass anymore
  ... no-one much likes it

TabAtkins: I want real maps but I don't care how to markup it up in WebIDL

heycam: I think we can come up with something else and then I'll let you  
know

TabAtkins: the selectors rule works the same way for custom selectors
  ... this is always going to be a pseudo-class
  ... (presents an example of a heading pseudo-class from the draft)

smfr: why is it :_heading?

TabAtkins: the _ is from the restriction I mentioned before, : is because  
otherwise it would be an element name

krit: that's not in the production

TabAtkins: yes, that should be there

  <dbaron> ?: Why have the : in the @custom-selector, rule?

  <dbaron> TabAtkins: Clearer that way.

heycam: what if you put an <ident> directly before the custom selector?

  <AdobeSeattle> p:_foo === p:matches(...)

heycam: e.g. p:_heading

TabAtkins: it just works because it expands to : matches

glazou: there are restrictions to what are allowed in a colon matches
  ... you should duplicate that explicitly here so it's a syntax error  
where the @ rule is defined

TabAtkins: sounds reasonable

  <dbaron> glazou: @custom-selector should be a syntactically-invalid  
@-rule if it doesn't meet the syntax requirements for what goes inside  
:matches()

  <dbaron> TabAtkins: I should special-case top-level :not() so that it  
expands into :not() instead of :matches() in that case.

glazou: I recommend we expand the :_heading example to include an  
expansion without the custom selector so that people don't think it's not  
just a macro

  <AdobeSeattle> No using custom pseudo-classes to define other custom  
pseudo-classes, because it hits the "no :matches() inside :matches()" rule.

  <dbaron> TabAtkins: ... not sure what I think of that

SimonSapin: why do we have that restriction: no :matches inside :matches
  ... this feature would be a lot more interesting without this limitation
  ... what is the scope of this rule?

TabAtkins: document scope

florian: you need to define that if a selector is not matched it is not  
invalid but simply not matched because it may be defined later

SimonSapin: does it update dynamically?

TabAtkins: yes

  <florian> you need to define that if a selector is not defined yet it is  
not invalid but simply not matched because it may be defined later

TabAtkins: that means you can actually define fallback

smfr: I think this needs more syntactical sugar so it's easy to remember
  ... they look like C preprocessor defines but they don't behave like that
  ... it would be easy to forget the colon when you use it

  <dbaron> smfr: in @custom-selector :_foo the : looks a it like a property  
declaration

  <dbaron> ... so the space couldend up on the wrong side

smfr: I like the feature but not the syntax

TabAtkins: happy to change the syntax

florian: this syntax proposed for media queries is fine, I think, but I  
can see the concern for selectors

  <dbaron> smfr: Also concerned about the extra parentheses in media queries

  <dbaron> dbaron: agree with florian... though I wouldn't mind seeing ()  
rules change

glazou: how does this relate to CSS hierarchies?

TabAtkins: it doesn't

glazou: does it impact it? is having both too much?

  <glazou> ScribeNick: glazou

Tab: nesting is very close if not identical to what we get from preproc
  ... I also have a proposal for script-based custom selectors

  … you define a name

  … a function and when it's evaluated

  … and a base selector that has to be fulfilled first

  … (tab reads spec)

  … based on mutation observers

  … whenever a mutation comes in we try to reevaluate the function

  heycam, re you afraid of style flashes because of events order and stuff?

  Tab, no

  Tab, was waiting for an infinite loop question

  florian, might be brilliant but :-)

  TabAtkins, very close to an existing lib by bkardell

  smfr, don't thjink WebKit will ever want to run JS in the middle here

  heycam, if you want to implement it yourself, you can set a classname  
 from a mutation observer

  smfr, I don't like it either

  florian, a way to retrigger evaluation of this?

  TabAtkins, there is something in the issue

  TabAtkins explains extra bits of the proposal

  SimonSapin, worth separating the API into two

  SimonSapin, first part substitutions

  SimonSapin, that part is less controversial

  TabAtkins, the script api of custom MQ is super powerful

  TabAtkins, I really want the MQ part

  TabAtkins, having to repeat MQ everywhere in your page is terrible

  TabAtkins, another option for script based selectors is assign a name and  
list of elements

  heycam, this is a simpler model

  <SimonSapin> glazou: Earlier we said we want to deprecate media types in  
favor of media features

  <smfr> ScribeNick: SimonSapin

glazou: that implies that web authors are gonna write @media (screen)  
instead of @media screen

  <dbaron> Tab^: being able to fill in a map walking over the document  
doesn't have much advantage over walking over the document setting a class

TabAtkins: If authors want to do that they can, still better than media  
types

glazou: it’s another argument against the () around custom media, or for  
allowing the current media types in ()

TabAtkins: disagree, media types a bad in general. Carry more that you want
  ... if you want to disable animations, you should target 'updates', not  
'print'

glazou: we will have to have a section mapping media types to lists of  
media features

florian: I think that’s a bad idea, they will just copy-paste that list
  ... It’d be better if they’d queried for just one feature

glazou: will follow up on email

  <glazou> TabAtkins, requesting a new ED

  <glazou> florian, find another name please

  <glazou> ChrisL, antialiasing ?

  <glazou> glazou, any objection ?

  <glazou> TabAtkins, preferred is to put the MQ part in MQ 4, ...

  <glazou> SimonSapin, er we wanted Selectors to be independent from CSS

  <glazou> SimonSapin, what about selectors API ?

  <glazou> TabAtkins, yes!

  <glazou> TabAtkins, MQ in MQ4 and Sel in Selectors ?

  <glazou> dbaron, API part not ready yet

  <dbaron> (script selectors)

  <dbaron> dbaron: but happy to see it go in drafts

  <glazou> TabAtkins, right

  <glazou> glazou, I don't want to see an at-rule inside the Selectors spec

  <glazou> TabAtkins, then Custom Selectors spec

  <glazou> glazou, fine by me

  <glazou> SimonSapin trolls Tab on spec dependencies

  <dbaron> SimonSapin: Aren't MQ also independent of CSS?

  <glazou> RESOLVED: MQ part of TabAtkins's proposal to be added to MQ4,  
new ED for Custom Selectors granted

  <dbaron> #now { coffee-break-after: always }

  <Bert> ScribeNick: Bert
CSSOM Value-based API

  <smfr> TabAtkins shows http://www.xanthir.com/b4UD0

TabAtkins: After long time thinking, I'm ready to propose one. Got  
approval from colleagues who would implement it.
  ... We implemented DOM2 and are trying to remove it now.
  ... Because it is terrible for many reasons.
  ... Exposing specialized forms for a property is probabbaly useful.
  ... But it is not a direct tranlation of the property.
  ... At base level I refuse that.
  ... Might be future level.
  ... DOM2 could not return value of a shorthand.

  <Rossen_f2f> LOL

TabAtkins: We should also make it look more like JS.
  ... And efficient.
  ... Looking at what we changed in propertie sover the years.
  ... Simple propoerties can later become complex, from one value to a list  
of values.
  ... Calling it "el.css" (rather than el.style), but it's just a name.
  ... el.css.backgroundImage (CamelCase)
  ... JS can now do things like .float, even if float is a keyword, because  
of the preceding "."
  ... E.g., width will be an array of length|keyword]
  ... If you assign a single value, it'll be equiv to an array with one  
value.
  ... The values are immutable values.
  ... Every "10px" object is the same single object.
  ... Poeple pushing for 64-bit ints.
  ... So next year we'll have fully immutable objects.

  You could write ".width= 5px" which looks exactly like CSS.

scribe: The "5px" is an immutable object.
  ... You can ask for the .px of 5px and get 5.
  ... When yu ask for getcomputedstyle, you'll get the em as well.

glazou: Can you ask fro something like ".%"? Syntax issue?

TabAtkins: 5px is CSS.px(5)

  <glazou> you cannot write el.css.width = 10% because % is an operator you  
have to use CSS.percent(10)\

TabAtkins: Constructor.
  ... After el.css.width = 5px you can get el.computedCSS.width.vw (and .em  
and .px and .percent) and it will be computed.
  ... Other accessors as needed.

krit: Is .css the element style

astearns: THis is inline style? Might want to call it InlineCSS.

TabAtkins: Yes, this is inline style.

SimonSapin: Percent is null?

TabAtkins: Yes, .percent cannot be computed, needs layout.

florian: Is there a typo in the example?

TabAtkins: Yes, sorry. Needs [0]
  ... List needs to have same value at given index all the time [?]
  ... Precise data structure, order of values.

glazou: If you query .width, I'd like to qurey waht the unit was, i.e.,  
get "px" back.

TabAtkins: Not in proposal right now, but planning to.
  ... If you pull a computed value, the unit may not be available anymore.
  ... It'll say "px" in that case, arbitrarily.

florian: So if a property accepts repeated foo and bar, an in next level  
it accepts repeated foo, bar and baz?

TabAtkins: In a list, you get first value in a list. It is an array of  
arrays in reality.
  ... After el.style.bgAttachment="scroll, fixed"
  ... you get: el.css.bgAttachment => [CSSVal("scroll")]
  ... and: el.css.bgAttachment.1 => [[CSSVal("scroll")],[CSSVal("fixed")]]

heycam: Thimgs that aren't lists, say a pair, how is that handled?

TabAtkins: Say you have <length> <length now and later we'll have <length>  
<ident> <length>
  ... First you would get el.css.foo => [1px,20px]
  ... Later you would get [1px,20px,...]

plinss: maybe don't return arrays and only return maps

szilles: You would have to cycl through array.

TabAtkins: Not super happy about my arrays, we can dcide for objects later.

astearns: Go with map idea and let Tab name everything. :-)

heycam: Shorthands also give an array back?

  <astearns> resolve to accept Tab's names for everything before he even  
starts

heycam: Say font, which has a slash?

TabAtkins: The slash is not returned, it is just part of the punctuation  
for ambiguous values.

plinss: personal preference, I hate single-letter names

TabAtkins: Named values must not collide with [?]

florian: Custom properties?

TabAtkins: Probably a list of tokens.

florian: At rules?
  ... selectors, etc.?

TabAtkins: Haven't thought through those yet.
  ... Properties most important for me.
  ... Is first step.

florian: At least think through it if it is compatible, without actually  
writing the spec.

heycam: Can you define operator overloading between customn types and  
stadard types?

TabAtkins: Yes, you can.
  ... Yes, overlaod can be parametried by type.
  ... So "5px + 10px" can be valid.

florian: And "10px + 10%"?

TabAtkins: Yes, that would return a calc() object.

  <heycam> |el.css.width + el.css.width| wouldn't work since they're both  
Array objects

TabAtkins: You cannot overlaod plain objects.
  ... Also have a proposal that I call CSS.convert()
  ... Converts as much as possible.
  ... var x = 32px;
  ... Now x.em is null.
  ... After el.css.fontSize = 16px, CSS.convert(x, el).em returns 2
  ... This is current;y a big braindump.
  ... Not asking for anything in particular right now.
  ... If it is terrible, tell me.

krit: Agenda request: filter effects and custom filters.
Custom filters removed?

  <krit> http://dev.w3.org/fxtf/filters/

krit: We had to limit tham already because of security.
  ... And they don't have the expected power.
  ... Current impls have problems with them.
  ... Especisally with combined customg and standard filters.
  ... (Not all impls.)
  ... We still believe in filter effects, but custom filters isn't the  
right solution.

Simon: We removed them in webkit, so supported.

krit: New feature would not use shaders.

ChrisL: Seems slightly sad since Microsoft added webGL support.
  ... But if two impls removed them already...

krit: No impls currently remaining.

Rossen_f2f: What was this again?

krit: Pixel manip with WebGL

heycam: Plan for replacment?

krit: Looking for more use cases, providing hit testing effects.
  ... hit testing was a pb with current solution.

heycam: So no future for generic shader-like thing?

krit: Many users were relying on pixel shaders, but they were security  
threat, so we had to limit them already.
  ... Couldn't actually llok at color value.
  ... We want to come up with a proposal, nd want feedback.
  ... More fous on use case of CSS.

heycam: A bit afraid to geta 100 different canned effects...

florian: What is th proposal?

krit: Not is presentable shape yet.

Rossen_f2f: Can we remove after seeing the new proposal?

sgalineau: But it is holding up the spec.

ChrisL: Are you asking to defer removal a bit?

sgalineau: The feature will go away, so what do we get by keepin git in a  
bit longer?

krit: I'm more focussing on SVG filters at th moment, and bringing that to  
LC.

  <sgalineau> the feature would end up at risk so not sure what the value  
of keeping it around

plinss: So take out? move to future level?

krit: Otherimpls might take it up again.

Rossen_f2f: Like to defer by a week.

krit: OK with me.

sgalineau: What do we get in a week?

RESOLUTION: take custom shaders out in a week, unless somebody objects  
before that.
backgrounds and colors and outlines in SVG

shepazu: Sometimes want to use outlines and colors, e.g., on hover.
  ... SVG doens't have on-hover effetc on it sown.
  ... Have to find the bounding box yourself.
  ... These effectsdo no affect flow.

krit: :hover is supported.

ChrisL: What spec?

krit: it is automatic.

shepazu: Is this a terrible idea?
  ... Would we allow whole background thing, or just color?
  ... Fill area would be bounding box of element.
  ... Use case is hover.

krit: Why not add an element behind it?

shepazu: Kind of a pain. I've done it.
  ... Keep track of transforms, etc, yourself.
  ... It is not perfect, but it is a start.
  ... Could add stroke effetcs to the outline also, vector effects.
  ... But simple thing now, and rest for futire.

heycam: [showing something]
  ... Approaches in the past included filters, and filling boundign box  
with color. Bit of a hack.

shepazu: I prefer "on hover, background = white"

krit: Sceptical about background. Don't see use case.
  ... Dont think thi is what you really want to have.
  ... Consider a complex shape, rectangle behnd iit is not what you want.

simonf: repeated images with fill?

krit: Yes, just decided today :-)

shepazu: I suggested things that don't change reflow.

  [discussion of what it shuld look like for differnet shapes]

shepazu: SVG often used for icons.

krit: Icons dfon't have hover.

simonf: Often element behind the icon has the hover.

krit: Outline for accessibility.

shepazu: I'd like to find out the concerns of the CSS WG with this.

  [CSS WG has no opinion]

ChrisL: More concensus on outline than on bg

florian: CSS doesn't have def of where outline goes, does it?

dbaron: Correct. I have thought about it, but not finihed.

florian: I remember something about 3d transforms making outline harder.

krit: Outline gets smaller when object is smaller because of clip path,  
but we decided recently that outline shoulf actually be clipped.

  <ed> svg tiny 1.2 has viewport-fill and viewport-fill-opacity properties  
that are similar to what shepazu is asking for with bg, though more  
limited in which elements they apply to

heycam: Does CSS define outline is outside the box?

dbaron: We have or had an outline-offset.

florian: I tink we have neither a def nor interop.

leif: Significant latitude for impls.

ChrisL: That was certainly so with the orig def.

leif: Not even defined if it is on top of everyhting, or only on top of  
the elt.
  ... But outline-offset is not problemeatic, but don't know about interop.

  [End of meeting]
Summary of Action Items
  [End of minutes]
  Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
  $Date: 2013-04-25 13:59:11 $