<sgalineau> call-in instructions in Location section of http://wiki.csswg.org/planning/seattle-2014
<TabAtkins> ScribeNick: TabAtkins
<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.
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
<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)
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,
<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
<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.
<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.
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]