<gregwhitworth> scribenick: gregwhitworth

astearns: when I originally brought up font metrics, I was thinking more text measurement
... there are font metrics that we get from the fonts themselves and style attributes
... then there are the typographic layout
... maybe typographic layout may just get added to the layout api
... the font metrics may be desired by someone for custom position of the glyphs

florian: if you have a nested text you may need stretching of the glyphs to wrap around the text
... for example math specific fonts have info for this

shane: that sounds like we need two different font apis

florian: the author of mathJax really has a desire for this capability

astearns: there are two topics and they are very, very seperate
... does anyone else have other topics

florian: let's throw use cases as well
... for example you would need the this info for first letter

astearns: it really depends. But if you try to do things only with text measurements, you end up doing layout to get the measurements and do layout again to achieve what you want
... I think you always need the measurements, but you may not need the glyphs

dbaron: do we want to expose different phases of the font process, such as shaping

astearns: we want to expose as little as possible and the smallest subset that solves an important use case
... and keep adding to it, rather than exposing a large API

dbaron: You may want a measurement where you pass it a string of text
... You may also want a measurement of the text with certain styles

astearns: that's a little different than I was thinking of
... there's also, just layout results

shane: something to keep in mind, is that the layout is expensive

eae: you could use measureText API form canvas, you can get the baseline or baselines in some cases

astearns: you can, but it gets drawn into the canvas by different browsers

eae: yes, it's very limited, but it's better than nothing

shane: it's like 50x faster

astearns: I want to avoid putting in divs just to find out layout information
... I have two blocks that are laid out, and I want to align the second box with the first one's baseline, you're simply adjusting the info

shane: I think you should do spec layout into containment regions

eae: right, you can give it an offscreen area and run this stuff

florian: I think it's cool and important to be able to trigger the api without triggering the rest of the pipeline if you don't care about it

astearns: I have done an API before, the current layout API shows just a baseline, there can be a glyph, a run, and each has a baseline and they can differ
... But it has been carefully defined what you're talking about
... the most popular one is the dominant baseline of the first character of the first run, and it was tremendously useful
... making it available at each step of the tree makes it so that you don't care about the glyph
... saying that a block has a dominant baseline glosses over a lot of complexity

florian: yes it's wrong, but it's useful

shane: well it's not wrong

florian: is it useful

stevez: is that enough to do line-grid

astearns: no

stevez: that's what I thought

eae: you can also imagine segmenting on the different baselines

florian: you still need to know all of the baselines
... The line grid itself needs to have them all so that you can align to it

stevez: we could avoid needing to document to where we ask the interface for specific ones and if it doesn't know it will say it doesn't

astearns: Once you get the content rendered, the browser has determined the dominant baseline

stevez: one area where you need a baseline and top line are in international languages for top cap

shane: these lines are in the font?

florian: no
... some

stevez: you're lucky to get the alphabetic if anything

shane: I'm just curious if we'll ever be able to lift this up to JS, it may just need to be in the font engine

florian: that's my issue with this discussion, while I don't want to lift this to JS, but when I look at the use cases we need this information

shane: I think it's ok that if something isn't there in the font, it's ok for us to say we don't have the information

stevez: when Elika, Dave Cramer, and I discussed for css inline the best to generate values that are missing from the font information

florian: tying it to your point *points at shane*
... it should be up to the UAs to be able to put their hands up

shane: I think you should be talking to the font engines

iank: my only perspective is that if this doesn't force layout into a corner I'm ok with it

shane: we should have an API that provides a null response if we don't know, but when you want a response we provide the dominant baseline

astearns: there could be a fallback

Bert: Let's say you want to know the cap height, does it say something?

florian: no, you're forcing the browser to lie

stevez: what if the browser is using the cap height?

florian: then the browser should tell us that

stevez: some of the Adobe products, create font information for cross plat interop

gregwhitworth says something about font fallback

astearns: and that's a different need where we need to know about which fonts are used on a given range

stevez: could we live with just getting a fixed number of things in a baseline table (alphabetic, ideagraphic, etc)

astearns: but those are things that the browser DOES synthesize

florian: do you envision asking the element foo for it's baseline and it gives you if it knows it

stevez: different, if you implement L1, you get the basic ones

shane: your adobe tool, does it run in real time or does it cache it

stevez: I don't know really, I think it may be both

astearns: unfortunately there are a lot of typographic engines in adobe products

<eae> in summary, my point was that if the browser needs to be able synthesize a baseline for other reasons that synthesized baseline should be provided as a part of the API.

shane: we should possibly try and standardize the heuristics that Adobe uses in these tools if possible
... maybe we provide devs with the opportunity to choose which path they want, cross plat or matching the system

eae: but you have to provide all of the paths to correctly match

stevez: this will be very hard on Apple as they don't always provide the correct info

astearns: I think we can simplifiy even further for V1, we just provide that first dominant baseline and provide the table in future versions

stevez: I wanted to start off with the table so that people start thinking in that direction rather than coming in with a new interface

astearns: yeah, ok

eae: *shakes head up and down* I think that's a really good idea

astearns: you would be able to determine which baseline is the dominant one?

florian: yes I think you should

stevez: ideographic characters are positioned in one of two ways, either at the bottom of the em box or at the center
... those are both used, so if you give the em box pos in the table then that would be sufficient as well

florian: then with math finding the center if you have the top and bottom it would be easy

koji: vertical is always center, horizontal is either bottom or center

stevez: you're going to miss cap height on any font that isn't western

astearns: you'll have ascent and descent but they aren't helpful

florain: and they'll all be buggy I suppose

astearns: yes

stevez: cap height is not reliably available

astearns: right now the text measurements are hanging off the fragments, I suggest rolling this up to the element and it will be the first inflow fragment

SteveZ: but the element may not have gone through layout

<liam> [ cap height ascender/descender height and x-height where available are incredibly useful]

shane: yes we have hit issues with conflating the left of the line and we should ensure that this doesn't happen

astearns: yes we need to determine if we should allow custom layout stuff to potentially allow layout to be invoked since ergonomically it's what devs are used to

shane: there are strong opinions within the Chrome team against doing that
... I think going down that path is bad for the web

stevez: so then we agree it's on the right of the line (of Rossen's process model design)

when he says the first inflow run, the drop cap will be wrong since it's out of flow

stevez: if the baseline is taken from the first inflow glyph, then floats and drop caps are not inflow

shane: so it needs to be in text, not inflow

stevez: what's text?

eae: it's special

stevez: we're changing the interface to have alphabetic, top, bottom and param for which is dominant

florian: can it happen that the dominant baseline is not one of these, it should be yes

stevez: for practical purposes, is no
... good point
... you could define ideographic center

eae: or we could just provide the position of the dominant baseline rather than the name

stevez: that allows us to add additional baselines without changing the interface

heycam: are we talking about glyph data?

astearns: the input of the metrics or the result of layout?

heycam: the actual font glyph info

<Florian> Scribenick: Florian

shane: do the type of raw metrics diverge between font types?

all: yes

dbaron: font by font even

SteveZ: the tools people use sometimes plug in values without justification, and you may be better off when the tools remained slient

dbaron: all fonts form a foundry may have the same data, regadless of the font

Bert: can I find out where the ink is?

SteveZ, astearns: there is bounding box data, it sometimes is wrong.

Florian: how comes anything works if all font info is wrong?

dbaron: hard coded font specific heuristics

astearns: several libraries do manage to extra useful information and do things with them, so we are not wasting our time.
... we should expose the raw font data, knowing it has issues, and let js deal with it
... but we have to expose the actual font being used

<liam> [when the information gets used, over time, some of the errors get corrected, people fix their fonts]

shane: there are 3 categories of things we can do
... 1) what font is used (on what? first inflow glyph?)

eae: what if you use multiple fonts for a single glyph
... we have APIs exposing the list of fonts used in a list

heycam: how do you expose this?

astearns: some object that you can use to get metrics from

dbaron: an object that represents a face

gregwhitworth: how do you untangle things when all fonts are used together?

shane: don't dive into the details to quickly

2) infomration that browsers use to align text on the page should be exposed, including the baselines

3) a low level API for raw (often wrong) font metrics

4) font geometry detection / font metrics synthesis

shane: we should identify a leader per area

SteveZ: we need to get something written down at the level just described

SteveZ + astearns will do base line table

eae + dbaron will look into exposing why font is used

Florian: do we need to work on raw font metrics in level 1?

shane: while exposing which font is used, we should also include a way to get the raw font file, so that people who want to parse it themselves can get to the data easily

<liam> ["get the data easily" easier said than done e.g. for a graphite font!]

astearns: there is a risk of fingerprinting, but the cat is out of the box already

dbaron: the only way to close this is for browsers to ship their own fonts and not use OS fonts.
... shouldn't expose raw font files for local fonts, only for webfonts.

shane: for inferred geometric data, we should defer

all: agree

eae: there's a 5th area: line break opportunities?

florian: useful, but seperate topic?

dbaron, astearns: I agree, it's a separate topic.

shane: And I'll write the high level explainer

<leviw> I think Rossen just challenged ojan to a duel.

<bradk> good morning

<bradk> rise and shine

<astearns> 1/2 hour before meeting start, will wrangle the schedule further at that point and set up WebEx

<glazou> hi guys

<astearns> heya

<astearns> still waiting on a couple of stragglers. will start soon

<glazou> cool thanks

<astearns> may need to use a google hangout this morning - still haven't seen Bert

<tantek> good morning

<smfr> https://wiki.csswg.org/planning/sydney-2016

<liam> track 1 and 2 are to be in parallel?

<tantek> one track

<glazou> tantek: thnks for adding your topic to agenda, good to discuss

<tantek> glazou: big source of frustration

<glazou> I understand 100%

<tantek> I'll try to be polite about it :)

<Florian_> astearns: did you find some solution to the dual track part?

<glazou> tantek: maybe you should also discuss -webkit aliases in gecko :-p

<tantek> glazou: that's the unfortunate consequence of the issues I raised :(

<glazou> very unfortunate

<tantek> in servo too

<glazou> sigh

<glazou> all what we have been trying to avoid for 15 years

<tantek> ironically, not Microsoft's fault ;)

<tantek> (despite fears of 15 years ago)

<glazou> Bert: email? I don't see any about it

<fantasai> ScribeNick: fantasai

<Florian_> SimonSapin: we're doing web compat now-ish

<astearns> just getting the phone set up

<tantek> trackbot, start meeting

<astearns> getting the phone set up

<astearns> hmm

<Rossen> heycam, thanks!

<dbaron> (waiting for the meeting room to get dialed in to webex)

<astearns> (various voice tree sounds)

<bradk> has webbex started?

<astearns> bradk: yes

Introductions

fantasai aka Elika Etemad

<jet> Jet Villegas from Mozilla

<smfr> Simon Fraser, Apple

<dbaron> Bert Bos, W3C

<hober> Edward O'Connor, Apple

<andrey-r> andrey from Bloomberg

<Florian> Florian

<dino> Dean Jackson, Apple (dino)

<rbyers> Rick Byers, Google

<tantek> Tantek Çelik, Mozilla

<eae> Emil A Eklund, Google

<Florian> Florian Rivoal (Vivliostyle)

<leviw> Levi Weintraub, Google

<zcorpan> Simon Pieters, Opera

<iank> Ian Kilpatrick, Google

<dbaron> L. David Baron, Mozilla

<skk> Hiroshi Sakakibara, BPS

<esprehn> Elliott Sprehn, Google

<astearns> Alan Stearns, Adobe

<baba> Takao Baba, BPS

<gregwhitworth> Greg Whitworth, Microsoft

<philipwalton> Philip Walton, Google

<plinss> Peter Linss, HPI

<BogdanBrinza> Bogdan Brinza, Microsoft

<Rossen> Rossen Atanassov, Microsoft

<hyojin> Hyojin Song, LG Electronics

<birtles> Brian Birtles, Mozilla Japan

<xidorn> Xidorn Quan, Mozilla

<heycam> Cameron McCormack, Mozilla

<hyojin> Jihye Hong, LG Electronics

<glazou> Daniel Glazman, Disruptive Innovations

<dauwhe> Dave Cramer, Hachette Livre (via telephone)

<joone_hur> Joone Hur, Intel

<SteveZ> Steve Zilles, Adobe Systems

<franremy> Francois Remy, Microsoft

<shane> Shane Stephens, Google

Web Compat Challenges

<dbaron> Brad Kemper (via telephone)

<esprehn> leviw is Levi Weintraub, Google

<leviw> ohai

<glazou> LARSEN

tantek: I've gathered together a set of web compat challenges that we're dealing with

<glazou> better

tantek: First Web compat challenge we have, specific example to illuminate problem

<dbaron> the wearable mic's have feedback; hand mic's seem to work

tantek: And hopefully come up with ways to address in general, rather than one-off case-by-case

<Florian> https://bugzilla.mozilla.org/show_bug.cgi?id=1234357

<Florian> https://code.google.com/p/chromium/issues/detail?id=569703

tantek: Specific problem we ran into was 0 vs 0deg in CSS gradients
... All other browser engines allow zero, even though invalid per spec
... They treat it as 0deg
... At this point content on the Web that depends on this
... nothing to do with prefixes
... When situation like this, how do we decide? Fix browsers, fix spec?

<zcorpan> httparchive research i just did for this - https://code.google.com/p/chromium/issues/detail?id=569703#c10

tantek: Wanted to see others reaction on this

<dbaron> fantasai: I think what we do depends on severity of problem and insanity of bug. In some cases might be reasonable and tolerable, in some cases might be a good idea, in some cases might be insane and nobody wants it.

glazou: We have some history about length and zero values
... With 0 vs 0px
... I think real question is, is this usedin the wild?
... How many web authors relying on it? Is it harmless to allow in the spec?
... These are right questions to ask

dino spits out some numbers

zcorpan: http archive has 260 stylesheets from 247 pages

?: 47000 pages in the archive

?: so .50%

<hober> 0.05%

zcorpan: Seems slightly too much for this particular case

<rbyers> http://www.chromium.org/blink#new-features

rbyers: On Blink, we have a process that we try to use
... Try to make a change that's good for web, vs compatibility risk
... We can say how bad it is, using data here.
... This is pretty bad
... But then ask here about how important it is
... If it's important, sometimes weigh to breaking the web

Florian: Looking at gradient compat stories, what I found is that breaking a gradient can make a site completely unusable
... when background is given with no fallback color, can't read the text

zcorpan: Point about flexibility in grammars

<Rossen> q/

(earlier rbyers pointed out that Tab said parsing 0 as 0deg limits grammar flexibility)

zcorpan: We can only have this workaround for specific features where its needed, .e.g. linear gradient. In that case wouldn't affect grammars in general

glazou: 2 things
... 1st one, is 0.05% is pretty insignificant. I don't thikn it's to worry about
... Other thing is religious choice

<rbyers> httparchive hits: https://docs.google.com/spreadsheets/d/170E-EyADapdzl1dap92PDmZ9Vpm3VfxkwvZJRadDpcg/edit#gid=0

glazou: We don't delete with Fahrenheit
... From author's perspective, 0 is 0 and you don't need a unit
... Did consider in the past
... Same argument for 0 vs 0px
... Should we make the same choice today?
... Isn't 0 the same as 0dg
... Whatever are the technical discussions and choices behind it
... Whatever choice we make today, are authors going to fall into unitless trap again?
... Will browsers be forced to implement unitless 0 again?

tantek: I think a lot of cases looking at stats for compat is important
... Also once in awhile run into cases like this, where authors do something that feel natural
... This can be an opportunity to improve the spec to be more author-friendly

<glazou> +1 to what tantek just said

tantek: if so, this may be worth fixing
... Let's limit author frustration if we can.

<Florian> +1

tantek: I'm a bit more sympathetic in this particular case towards treating 0 as 0deg

rbyers: Wanted to respond to .05% page loads being insignificant...
... Gone back and forth on .03 as limit
... We've had businesses come to us and say "you just ruined my business"
... .05% is 50,000 page loads a day. It's still a lot

<glazou> rbyers,with that argument, we kept prefixed properties forever

plinss: I'm hearing a lot of arguments in favor of making 0 0deg
... Nothing I disagree with
... I remember we did this for a reason. I don't remember what it was.
... Let's not make this change without understanding the reason for making this reason.

<dbaron> fantasai: This is not a change; it was built in to the CSS2 spec, it's how angles were defined. We kept those parsing rules. This is before Tab's time.

<bradk> Tab said: This was never supposed to be valid. >_< We should limit the spread of this incorrect pollution, because CSS isn't going to change to make this valid in general - it makes it harder to write unambiguous grammars if any old dimension can be dropped when the value is zero.

<tantek> that's a quote from https://code.google.com/p/chromium/issues/detail?id=569703#c4

<dbaron> fantasai: Main reason was parsing ambiguity. Right now lengths are only units you can drop units. You can't write 0% as just 0. Angles are a different type of unit.

<dbaron> fantasai: Then ambiguity of whether 0 is a length or an angle. If you also make it so you can drop 'deg', you can't convert between 0deg and 0 lengths; if you can tell from context you can guess, but we'll no longer be able to tell difference between angles and lengths.

<tantek> fantasai: we don't have any properties where this is an issue now

smfr: In Webkit code, subtlety
... We're not parsing 0 as 0deg
... We're failing to parse the 0, and defaulting to initial value of zero

dbaron: For us the 0 makes us drop the whole gradient

smfr: I'm confused about this and why our code doesn't do this, too

fantasai^: Doesn't matter what unit, every length unit at zero is equivalent. So doesn' tmatter the unit. But 0deg vs 0 length are two very different hings

scribe:

dbaron: Animation and Transition shorthands are a bit problematic
... wrt times
... Developers often run into problem of some implementations parsing 0 as 0sec
... Those shorthands are a *huge* mess if unitless zeros can be times or angles
... The animation shorthand has 2 time and a number and ...

dino: naming being ambiguous with timing function

dbaron: That's a separate ambiguity
... We may well end up having to change those too for compat, unless other implementations are willing to fix.

Florian: If we move in general for unitless zero, then it constrains our grammars
... It is natural for authors to use unitless zero
... So they're confused

jet: We'd been talking wrt unitless zero
... But we also have a problem with other unitless numbers. e.g. behave different for 45

smfr: That should cause us to drop the gradient

jet shows smfr a testcase

philipwalton: People said that web devs use unitless zeros
... Sometimes it's not the web developer's fault. Sometimes it's the minifier

<Zakim> tantek, you wanted to ask is anyone seriously proposing unitless zero *everywhere*?

tantek: Is anyone seriously propsing using unitless zero *everywhere*?

glazou: One thing, from author's perspective I think that allowing unitless zeroes almost everywhere makes sense
... and it would be our task to define how any ambiguity makes declaration unparseable
... If there's any ambiguity, then you drop the whole thing
... that would be more reasonable to do

zcorpan: Another thing to consider here is quirks more, where unitless zero can be color or length
... the grammar ambiguity gets worse in quirks mode

<glazou> goog point

<tantek> like background

<glazou> good

<zcorpan> https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk

<tantek> fantasai: hard to remember order of values in shorthands

<tantek> fantasai: we already require %s to have a % at the end

<tantek> fantasai: e.g. if you say height 0% it will turn to auto

<tantek> fantasai: behavior differences already between 0 and 0%

<tantek> fantasai: suffix on the 0 matters

tantek: Sounds like we don't have consensus on allowing zero anywhere

<zcorpan> (actually the color quirk is only for a few longhands so it seems it's not actually an issue)

tantek: There are several cases where that breaks things or makes them worse for the authors
... So perhaps for purpose of this discussion, limit for gradient issue

tantek proposes straw poll

zcorpan: I think 0 was needed for rotate/transform/skew

dbaron: Transform functions take as an argument "0 || <angle>" explicitly

tantek: Anywhere we accept angles, should we accept 0 as 0deg?

zcorpan: Do we have a list of properties

Florian: I think from what we're hearing in the room, we can resolve for gradients
... But not for everything
... dbaron said we already agreed to zero in a specific context

dbaron: It's not for degrees, it's for the arugment to transform funciton

Florian: Apparently we can also agree in gradients accept 0 or an angle
... I haven't heard anybody opposing this

<bradk> transform: polar(0deg, 10px)

Florian: For broader discussion
... I'm not sure that discussion is easily wrapped up
... Anyone oppose zero in gradients?

<franremy> q

tantek: Okay, so we could either do gradients as "0||<angle>"

<dbaron> Gecko accepts angles in CSS for transform functions, image-orientation, linear-gradient, radial gradient, hue-rotate() filter

tantek: It leaves question to authors where some angles can be 0 and others cannot
... I'd like to rereaise that question, where else are there angles where putting 0 would cause problems

<SimonSapin> "0 | <angle>" in gradients seems harmless, as far as I can tell

dbaron: [lists properties that take angles]

<Rossen> ?

franremy: Just wanted to mention that SVG transforms actually take all degrees without a unit
... You can put rotate: 45 and it will just work
... Same property on HTML elements requires degree, whereas SVG sides doesn't require

franremy, can you clarify if that is CSS syntax or attributes

<franremy> https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/transform

heycam: I don't think we should take what SVG accepts in its attributes as precedent for CSS syntax

<franremy> transform="translate(30) rotate(45 50 50)"

smfr: We have a difference in behavior in quirks vs standard

Rossen: Same thing in Edge

<tantek> smfr: we always allow unitless 0 for angles lengths and times

smfr: It seems we always allow unitless zero forlengths, angles, and times

<tantek> (wow)

smfr: in gradients we sometimes parse 0 as color in quirks mode
... make sure testing standards mode

zcorpan: I think we should strive for interop in quirks mode
... So if you can drop that quirk in WebKit, that would be nice

rbyers: Just wanted to point out looks like transforms spec doesn't technically allow the zero, but has examples where 0 is used

Rossen: In other words we are encouraging authors to use that by example

Florian: arguent for "it's natural thing to do"

tantek: dbaron, what would be impact of adding 0 to other properties

dbaron: I don't think it would be a big deal
... Unless something ambiguious in gradient syntax

Florian: If some properties no browser accept zero in some cases, then we might have opposite problem of authors expecting it to not work

<dino> WebKit bug https://bugs.webkit.org/show_bug.cgi?id=153730

<baba> Is '0.0' used as zero-length in current spec?

smfr clarifies that this magic is only for gradient parsing

<zcorpan> 0.0 is the same here

fantasai: 3 options here

<Rossen> glazou, get a hold of your cat

1. Don't change gradients. Keep aangle-parsing quirk to transforms

2. Allow 0||<angle> for gradients, but not in properties in general

<baba> Thank you zcorpan!

3. Allow 0 to parse as <<angle>> everywhere (including not in functional notations)

fantasai: Unless someone has something to add, suggest straw polling on that

plinss: Clarify on option 3, does that preclude cases where it is ambiguities in shorthands?

<glazou> +1

plinss: Either need a rule to clarify in shorthand, or say shorthand must require unit

tantek: Shorthand must resolve how to assign values

shane: We have rules for this

dbaron: Those are pretty awful, though, and we accepted because we had to

<zcorpan> (unitless color ambiguity is apparently a problem in webkit still)

Rossen: Forced on implementers, not by choice

<SimonSapin> list-style: none none

Florian: Write everything that you agree with, star your favorite

[argument over voting methods]

<franremy> fantasai: should we add ==> 4. Accept unitless angles (for any value) <== ?

franremy, that's #3

1, 2

<Florian> 3* 2

<SteveZ> abstain

<glazou> 3

<dbaron> 3 2

<franremy> 3,1

<tantek> 3,2

<shane> 3*

<zcorpan> 3,2

<Bert> 1, 2, 3*

<rbyers> 3, 2

<SimonSapin> franremy, that’s and I think should stay a SVG-specific quirk

<astearns> 3, 2, distant 1

<andrey-r> abstain

<bradk> 3,2

<bkardell_> abstain

<smfr> 3, 2

<esprehn> 3, 2

<plinss> 3 2

<gregwhitworth> 3

<SimonSapin> abstain

<philipwalton> abstain

SimonSapin, franremy, ohyeah, I misread. Agree with SimonSapin

<dino> 3*, 2

<hober> three two

<hober> sorry, three start two

<Rossen> #3, #2

<hober> *star

<Florian> 三 二

<SimonSapin> what does * mean?

<vollick> 3, 2

SimonSapin, favorite

<Florian> SimonSapin: * means preferered

<BogdanBrinza> 3, 2

<smfr> *3, 2

<franremy> fantasai: simonsapin: then, I prefer 1 over 3

<dino> 3️⃣⭐️,2️⃣

<shane> 1: 3 + a "distant", 2: 16, 3: 19? I think?

<iank> III, II

<chad> you're all voting wrong!

<zcorpan> are we done?

<birtles> abstain

<Florian> 3deg

<glazou> ROFL

Rossen: Seems like 3 is most popular

tantek: fantasai, can you live with 3?

<bradk> 7deg of Kevin Bacon

fantasai: Yeah

tantek: No objections to 3?

<glazou> tantek: present specs or future ?-)

RESOLUTION: Angles can drop unit when value is 0

<zcorpan> 0 || 3 || <angle>

tantek: Impacts lots of specs

<SimonSapin> doesn’t it only impact Values & Units?

fantasai: No, only values and units

<SimonSapin> directly

<scribe> ACTION: fantasai to update V&U to accept unitless angles [recorded in http://www.w3.org/2016/01/31-css-minutes.html#action01]

<trackbot> Created ACTION-746 - Update v&u to accept unitless angles [on Elika Etemad - due 2016-02-07].

tantek: Increasing order of difficulty!

Florian: easy quesitons always take longer

tantek: Because we discuovered this problem b/c Mozilla was one exception.
... Hadn't heard about it from anyone else
... Clearly other browsers eithe rship like this by default, whether accident or not
... Or get this behavior because they forked from such a brower
... *or* they implemented because they fixed due to web compat **and didn't bother to inform anyone else in the WG**
... You guys clearly implemented this to work with web conten tout there
... But didn't report it to the WG
... What happened there?
... If you had to violate the spec due to web compat, you're supposed to let the WG know

BogdanBrinza: For MSFT it was a problem with scale

???: In last year or so we fixed over 5000 interop issues

BogdanBrinza: Quirks to match other browsers
... In most cases we try to work with other browsers
... But have many teams. But not everyone has bandwidth
... Agree with you that should discuss

<SimonSapin> even a raw dump of details on these 5000 issues would be nice

Rossen: In most of the cases, we actually, our internal procedure is to reach out ot the list and other implementers and figure out what is going on
... speciailly for harder ones
... One actual reason we have next topic, Tables, on agenda, is exactly because of interop
... We want to chase alignment among implementations
... Want to reinforce what BogdanBrinza said
... Scale problem when in a fix sprint
... Have to go approve many issues
... And that's obviously not something that happens that often
... For us it was abrupt switch between IE/Trident and Edge
... Very different goals in Edge
... We had bigger freedom to chagne things
... Took opportunity tosprint rantehrt ahn walk i nthe park
... So yes, what you're aying resonates with us, and it's the right way to do it
... We us mailing list to discuss most

fantasai: Most? 5000 issues, only < 10 reported?
... You violating the spec in 5000 cases and only reported < 10?

Rossen: Browsers violate spec in many cases, only know if there's a testcase or content ...

dbaron: I think what Rossen was saying that most of those issues were just bugs where they fixed the bugs

Rossen: Match what others are implementing, whether or not it matches the spec

<dbaron> fantasai: If you're fixing a bug and haven't bothered to check what the spec behavior is, that's a problem. If you're violating the spec intentionally for web compat and can't bother to send an email to www-style, that's a problem in your process.

<dbaron> fantasai: If that's not in your process that's a problem for us and we can't fix the spec.

zcorpan: A more pragmatic way to let the world know what you're doing is to release your internal tests
... Poeple can run those tests against other browsers and find the differences
... And can convert tests to web platform tests so everone can run them

Florian: I will issue same challenge to Mozilla, wrt Servo
... Servo does implement once in awhile
... But given it's a from-scratch implementation, pretty sure it's running into weird things often and not reporting them
... So as fantasai said, same idea of actually reading the spec and reporting to www-style

tantek: So I think to be clear, the request is not saying that you need to run a discussion. But send a heads-up
... Everyone has different business constraints
... But it seems reasonable to at least request an "FYI, we found this web compat problem, we're shipping this change" that kind of notice
... The flip side of that is that we as a WG need to be receptive to that kind of feedback
... I think we have enough experience to know that this is a real problem for every implementer
... I'd rather hear the data and not have a discussion, than not hear the data at all

gregwhitworth: I'd say that we definitely try to... the majority of them I actually pulled back on documenting as many as I could
... We'd discuss, end up in this one wormhole
... That quickly wastes time even though

<SimonSapin> (Re Servo, I think several of us on the team insist we do report issue when decide to diverge from specs. But we haven’t done a lot of interop work yet, so we haven’t found a lot of these issues yet.)

dbaron: how are we going to conclude this discussion?

tantek: In the past, we've had a much stronger climate for yelling at implementers for violating spec, but try to be more receptive for filing bugs against specs
... At least in this room, can say we talked about in person, but shouldn't turn into permathread
... Saying, "fyi, ship this thing beyond what spec things", take that as input rather than upset at breaking the spec
... Should make that cultural change.

<Florian> +1 tantek

smfr: I looked at test suite repository, and there are 9 tests for all of CSS Images
... We've all done a bad job of providing test cases

<zcorpan> we all suck

dbaron: There are a bunch of tests in the mozilla import directory

<dbaron> also tests in vendor-imports/mozilla/mozilla-central-reftests/images3 although they're all for object-fit/position

tantek: If there's anything MS would like to see from WG to be more supported in sending this information to the WG

BogdanBrinza: I might've send wrong tone here. I don't think we deliberately not reporitng spec violation we identified
... Might've fixed things that were spec violations and didn't identify it
... Not a problem with WG. Conversations with WG have been helpful.
... But checking bugs, fixed 4000 bugs for web compat
... History for specs/w3c/CSSWG/ things like that, very small number of bugs correlate with what we reached out to
... Others mostly edge issues
... Not sure why we talk about this anymore

tantek: I'd like to ask chairs that we take a break then, before next discussion

<glazou> Rossen: can we start again? I'm falling asleep

Rossen: *gavelgavel*

<glazou> yes

<Rossen> glazou, voila

Rossen: Continuing topic...

[technical problems]

How do we get member sites to stop depending on CSS vendor prefixes?

<tantek> (and other bugs)

<tantek> https://twitter.com/tabatkins/status/674620970523430914

<astearns> Tel: +1 617 324 0000

<astearns> Meeting code: 641 743 771

tantek: In the third topic on web compat this morning
... Question is, how doe we get Member sites, in particular, to stop depending on vendor prefixes and other browser-sepcific bugs

<bradk> I can hear

tantek: The specific bug, since we picked on MSFT last time, is Google -- bugs in Gmail
... Depending on either prefix properties, and not using standard versions
... Or relying on bugs in their browser
... Here we have Edge copying a bug from Blink, because they didn't really have a choice

<rbyers> bradk: just https://twitter.com/simevidas/status/674089451866443777?ref_src=twsrc%5Etfw

tantek: Members have sites on the Web. Gmail is one example.
... How can we fix these problems, at least on Member sites?

<zcorpan> time to pick on google

rbyers: Question has a fundamental misunderstanding, we don't have much access to the Gmail people
... Sometimes web developers just don't want to fix the bug, because it's not worth it to them.
... We can't change that
... We can do outreach
... And we can make decisions in the browser
... In some cases we have a stupid bug in Chrome, and we have Google properties and others depending on
... Talk to them, and then risk seems good, we just break them
... That's our only fallback
... There's no side channel, due to member of CSSWG

<tantek> ack fantasai

<tantek> fantasai: google's motto is don't be evil, designing your websites to only work in your browser is evil

<tantek> fantasai: the people at the top of google should care

<tantek> fantasai: if there was a way to say here are all the places in your web code that you're doing evil things

<tantek> fantasai: and then get that list to some VP higher up

<tantek> fantasai: because right not individual gmail properties are doing their own thing

<tantek> fantasai: but if you for example focus on perf, why can't you do that for compat

<esprehn> w+

rbyers: when I dig into these cases, often boils down to not some dev being ignorant, but our failure as a standards group to not properly spec things and our failure as browser vendors to make things interoperable
... We need to invest in interop, testing, etc.
... When you look at some really rich sites, they didn't have an alternative

<zcorpan> fantasai: in this case there was a reasonable alternative though, there is an easy standard way to fix it but they're not doing it

Florian: So the "don't be evil" is one way of framing it
... But when framing as "just like other website", it's nto true
... Google isn't just another website
... It's pretty major, and also it has its own Chrome browser, which building for itself is kindof an antitrust problem

<tantek> Florian channels Håkon

glazou: I think we're making a confusion here about the role of the CSSWG
... Our role is not to be evangelizing the whole world including themembers
... The browser vendors have evangelists for that, and the motto that is used for politics "...all press is good press"
... I suggest as an answer to evangelists to do their job, and they can use the press when needed
... bad press will be enough to trigger a change
... Wrt Gmail, I think Google's business is based on collecting data from everywhone

<dino> I was just going to say that I agree with rbyers

glazou: And everyone means everyone in every platform everywhere, so if one of their major properties is broken in other browsers, it's a big problem for them and they're going to fix it

esprehn: This is starting to become a legal matter... gotta stop
... Microsoft and Google have many tens of thousands of employees
... The members here have no power

tantek: That's why brought it to WG, looking for suggestions on how to improve the situation
... I agree legal stuff is not something to discuss here
... But I think your analogy to Windows is ncorrect
... If yu said Outlook.com, might agree
... I think fantasai's point, that you have a chain of command that you can walk up
... that's a difference that you can effect change in your onw company in a different way to someone from outside
... Another problem is that your bug databases are internal, so we can't applky any outside pressure
... Another ossibility is that when we find these kinds of bugs
... we file them at W3C
... Have it be something we can openly track, as something that is causing problmes for the Open Web

<dino> i think rbyers original point was not "Sometimes web developers just don't want to fix the bug, because it's not worth it to them.". They *do* want to fix the bugs, they just don't have time. Like all developers.

tantek: Making that bug list more open, makes it easier for us to apply more pressure.

rbyers: I think argument applies in other direction as well
... Chrome exists to make the Open Web great
... Google being a collection of small independent teams means that Chrome does things in the interest of the Web that are not in the itnerest of Gmail

<gregwhitworth> I no longer need to be on the queue, not sure how to remove myself though

rbyers: I think there's a risk of compat ...
... Just because bug on our site, doesn't mean it's elsewhere

<gregwhitworth> thanks glazou

fantasai: Google's properties are often the tipping point for bugwards fixes

tantek: This problem is specific to us. There is a class of problems where it's a member site that we're having to make fixes in teh browser for

rbyers: We should have a higher tolerance for breaking a single site

<glazou> WOW

tantek: So you're saying that Chrome would break Gmail?

rbyers: Yes

tantek: I thikn that's a really strong show of good will

<glazou> extremely

tantek: So let's acknowledge that.
... Let's turn the question back around
... How can we help you make those kinds of breaking changes?
... When we run into this kind of problem, having to introduce hacks inot our browsers to fix Google bugs, what can we give you to make that breaking change?

rbyers: Show us why we should fix the bug, instead of keeping it and ignoring your spec
... Why is the spec better?

glazou: Reminds me of arguments I heard 20 yrs ago
... I'm not sure I'm that sympathetic to this kind of argument.
... Breaking the web to introduce things you think are good for the Web, I thought this is the task of the W3C, not of Google.
... If you want to break the web, do it with us, don't do it yourself, don't do it alone
... If you do that, you are breaking itneroperability for awhile
... This affets users of other browsers

<rbyers> To clarify exactly what I said: we strive to balance what's best for the health of the open web and what's best for our users. What company owns the specific sites that are broken by a change is irrelevant. But that doesn't mean we'd cause undue user pain for the sake of making spec authors / WGs happy.

<Rossen> break the web forward

glazou: If we don't break it together, this place the CSSWG and other WGs and othe committies, are for evolution but also ?
... W3C doesn't write standards, Members wirte standards
... Let's do that all together, please.

<tantek> The specific example https://code.google.com/p/chromium/issues/detail?id=559258#c14 is about requiring -webkit-border-image (and not including unprefixed border-image)

tantek: Wrt "show us why we should fix the bug, instead of ignoring the spec"
... Specific instance is both Gmail and Gcal require a prefixed version of border-image.
... The questio nhere is, do you think it's okay to force other browsers to implement -webkit- prefixes?

rbyers: So first of all, nobody is forcing to do anything. Eveyrone makes their own choices
... Do I think other browsers should implement -webkit-? sure. We implemented IE6 hacks
... I think Edge has done a great job of doing this, balancing fixes with maintaining architectural integrity

<zcorpan> XMLHttpRequest!

rbyers: pushing back on Chrome to fix their problems.

tantek: Okay, let's record that you would prefer that rather than fixing Gmail, other browsers should implement -webkit- prefixes.

rbyers: If it's a case that -webkit-border-image and border-image are the same, and the benefit is not having an alias, then let's just add the alias

fantasai: there's a behavior diference as well
... It's fairly easy to fix, but ehre is one.

Florian: This isn't new.
... Last time we discussed adding -webkit- prefixes Google was completely sympathetic, because couldn't remove it

<tantek> fantasai: it's about the effect of the border-image affecting layout

<tantek> fantasai: in the prefixed version, it affects layout

<tantek> fantasai: if you hadn't loaded the image yet, or link broken, the layout would remain stable

<tantek> fantasai: now you could fix the way that behaves by changing the border declaration that you have

<tantek> fantasai: so that the border-image and width would match

rbyers: Bug in this case, I can look for it.
... Maybe we can fix things gradually by, e.g. turning -webkit-border-image into an alias to border-image without the differences.

tantek: ....

rbyers: We have examples wher ethis worked well

<tantek> tantek: if it's just an alias, that's more palatable

rbyers: At last BlinkOn, we discussed making compat better for the Web
... Came up with pragmatic solutions

<tantek> fantasai: if the prefixed version requires more implementation, reverse engineering etc., then we will likely pushback

<tantek> rbyers: Sometimes have simple APIs to add to give a better transition path

rbyers: How to make very easy to for devs to migrate
... Chrome use of webkit prefix is also a lie, we inhertied from WebKit

Rossen: Sounds like we're done

tantek: Hopefully should minimize necessity of replicating bugs
... We can try moving forward with that with case by case basis

rbyers: Chrome has open process for this stuff, Intent to ship/deprecate/remove
... Happens on blink-dev
... Look for "intent" in subject line
... There's nothing that happens as part of theat process that isn't accessible to you

<tantek> fantasai: the main problem here isn't chrome, it's other teams at google and trying to get them to pay attention

tables

gregwhitworth walks to the podium, about to dive into the most dangerous jungles of CSS: specifying Table layout

gregwhitworth: Hi!
... We're going to talk about TableS!
... One Spec to Rule Them All
... I want to take all of these specs that define "something" about tables, and marry them all together
... Break this cycle of fixing bugs to fix some sites that break other sites...

<tantek> CSS 2.1 vs. Microsoft vs. David Baron's

gregwhitworth: We do not want to add new features to Tables.
... We don't care. We're not adding anything new.
... Goal is Interop Interop Interop Interop
... Also, to explain Reality.
... fremy did a great job in the opening, to tell people that This Is Not Our Fault
... So many things just don't make sense about how table swork
... But last year we were fixing tons of tables bugs
... Developer reached out to us about a bug and said "this doesn't make sense"
... Tride to bring to wg, and wg said... Ummm not defined.
... Goal is to find all sections that are undefined
... Also, find all interop issues
... spec says "this should happen" and it doesn't
... Find all interop issues, and decide on something that is something someone is shipping. Unless there's a really strong argument to not do that.
... Goal is to by 2017, have our developers be able to kick out 50% of those bugs
... point to spec language saying "We're doing it right"
... Allow other browser vendors to rev their table layout to match the spec
... That's the goal of the spec
... On purpose, this is a ton of red

gregwhitworth++

gregwhitworth: A myriad of stuff from previous attempts at a spec
... From dbaron, Bert, Microsoft, CSS2.1

<tantek> "one table spec to rule them all"

<gregwhitworth> http://gregwhitworth.github.io/css-table-3/

gregwhitworth: All I'm lookng for there is a current CSS3 Table spec in the repo
... This is a huge goal for us at Microsoft. Was asking for ED

fantasai: YES

gregwhitworth: Still a bit work to do before discussing specific issues.
... Just don't want to rathole on random discussions
... Here's a list of bugs we're tracking
... Browser vendors can look at them; our bug database isn't public, so copyied them out here
... Goal is to resolve 50% of them in 2016

<tantek> gregwhitworth - great methodology

dbaron: One thing I was going ot say is that I would be very happy to see this in the WG repository
... Even if you're not comfortable going to FPWD yet, should be ED asap

<SimonSapin> +1 for in wg repo

dbaron: My intuition is that the least interop parts of tables have to do with height calculations
... I think weidth is substatially more interoperable than height

<tantek> +1 for put new draft in wg repo

dbaron: Wasn't able to skim issue slist when you went by
... But if yo'ure short of height issues, ask me for some

gregwhitworth: We ran into lots of issues.
... e.g. resolving px vs percentages in height ocmpletely different han width
... gonna be a ton of issues

dbaron: Height distribution in IE6 was saner, and a lot more similar to width distribution.
... Don't say that very often :)

RESOLUTION: Add greg and fremy as editors of CSS Tables and copy into CSSWG ED repo

<tantek> amazing

zcorpan: I wanted to discuss something else...
... I really like that there's this spec, and I'm happy to contribut to it
... It also covers mapping from HTML to CSS, and that's something that's already in the HTML spec
... I haven't checked it's the same

gregwhitworth: IIRC there are holes
... We've only done this for 3-4 weeks
... I think okay with later on ripping stuff out, I just truly would like to keep everything in one place or now

zcorpan: Should fix HTML once we know the right behavior
... Do you care about quirks mode here? Because I have some quirks documented

gregwhitworth: Not right now. Want to get standards mode interoperable first.
... I think that's a V2 state

Florian: When Quirks mode are different from standards mode, yes.
... But I think if everyone is different, it might be worth checking out the quirks mode and aligning to that if it's more sane, instead of aligning to one of the standards behaviors.

gregwhitworth: That makes sense, but also have to consider that since most pages are standards, that might break things more since nobody does it.

astearns: You talked aobut interop without calling anyone evil or naively characterizing their business model
... so thank you

Table Header/Footer repetition

table header and footer repetition: https://lists.w3.org/Archives/Public/www-style/2016Jan/0135.html

Florian: CSS2.1 is undefined about this
... When you fragment across fragmentainers, do you repeat headers/footers or not?
... Browsers disagree

<dbaron> which browsers do what?

Florian: Think we should do that. And possibly have a switch for it
... Everyone who uses tables for print wants this.
... If you're using tables for layout, wouldn't have tables/footers anyway, so not a problem there.
... I would like to go away from undefined and make it a MUST
... I'm okay if people say "only if we can turn it off", but not necessary.

dbaron: Which browsers do what?

Florian: Firefox and Edge repeat the headers and footers repeat across pages. Not on columns for some reason
... Webkit/Blink don't
... Printing implementations all do it

dbaron: In Firefoxes case, the "not on columns" bit is because the code to do this does not support dynamic changes.

Florian: Would you consider it a bug to fix eventually?

dbaron: Do you consider heat death of the universe eventually?

Florian: Yes.

dbaron: Not going to a priority

Florian: That's fine.

gregwhitworth: I think this is a good idea of what ot file against the spec
... For the column case, what are use case of splitting tables for multiple columns
... What makes the most sense?
... Say this is what we agree on , what's the use cases, etc.
... Use case may be so rare that not worht it

Florian: Use case is pretty simple
... Think of a scientific document. LaTex 2-columns, includs data table
... Table is broken across pages or column as necessary

gregwhitworth: What happens if you have very small veiwport?

Florian: I think we agree we need to have error-handling code for not enough room
... I would suggest drop footer if not enough room, if still not enough drop header.
... I can take it back to the list if you want

gregwhitworth: I think we should spec printing, discuss for other thing.

Florian: I'm not sure I want to distinguish here
... Don't want to distinguish between pritn/non-print UAs

fantasai: I think the spec should recommend repeating. If we can't say MUST due to implementations not being able to implement soon, then that's fine, we call it "SHOULD" and not "MUST".

<dbaron> We actually don't split tables at all when they're inside of multicols when printing.

<dbaron> (from https://bugzilla.mozilla.org/show_bug.cgi?id=678447 )

gregwhitworth: Prefer to goin with MUSTs than SHOULDs in the spec

Applying 'contain' property to tables

Florian: There was a side-discussion wrt applying 'contain' to internal table elements
... Not sure I a see a good reason for not applying to table cells. For table rows, I care less
... But I think it makes pefect sens to apply to table cells.
... I wanted to get a sense of consensus of implementers, when you implement 'contain' can you also apply to table cells?

dbaron: Table cells aren't the only type I'm worried about. E.g. what does it mean for 'display: inline'?
... I think 'contain' needs to be doing blockification
... Most display types don't workwith 'contain'

ojan: I thought it forces a block?

??: It's not in the spec.

leviw: Agree it doesn't make sense in the inline flow case

table-cells: I think it should just say...

dbaron: I see this in the spec
... It's well-hidden.
... "Layout containment forces a formatting context ....."
... It's not actually defined. "The element MUST be, no deinition of making it"

ojan: I'm sure that was the intention, need to give feedback to Tab

franremy: table cells are very similar to block
... No reason to believe we can't use 'contain' on a table cell.

Florian: ...

RESOLUTION: 'contain' applies to table cells

Rossen: Okay, lunch is scheduled for ~1pm

Colors

<dino> https://lists.w3.org/Archives/Public/www-style/2016Jan/0301.html

dino: Had a conversation in Sapporo
... Sent a follow-up mail
... First suggestion is, CSS3 Color spec already says RGB color section that it allows values outside of 0-1
... If you're on a device that supports that gamut, you should show the colors, otherwise clip
... Nobody has implemented that yet
... Few things to discuss
... Doesn't say what those colors mean
... sRGB doesn't say what to do
... There's a spec from MSFT scRGB, which specifies what to do outside of 01-
... Maybe we should updat ethe spec to explicitly link to that

<astearns> https://en.wikipedia.org/wiki/ScRGB

dino: Also, we're not so sure what tools would allow devs to specify this
... Maybe a question for Adobe, what would you do in Photoshop to pick a color on your fancy monitor that's outside sRGB
... And have that convert to e.g. -10%

astearns: I'm not quite sure that I'm prepared to answer that question directly

SteveZ: But my memory is Photoshop uses its own color space most of the time

astearns: it's an Adobe color space

dino: Say you have an image with a very bright red, outsid esRGB
... Tagged with color profile
... And now you want to have you rweb page background match
... You only have the ability atm to specify that using the background: rgb() syntax
... How is a dev going to figure out what values to put in rgb() syntax?

SteveZ: I can ask the ICC guys

dino: This would be useful feedback.
... We're trying to specify how to read the value and spec on screen, but doesn't help anyon eif they can't actually figure out what numbers to use

Florian: Chris is working on spec to be able to specify colors in different color spaces
... Once we have that, do we need this hack around rgb()?
... Couldn't we just use the proper color syntax with that?
... Or do we need this fix

dino: Answer might be yes, don't need ot do this
... But then we should go back to clamp the values outside 0-

1

smfr: So, I think we're trying to solicit feedback on Adobe on what the authoring story is.
... How can you author things to work correclty in the deep color world?
... And want to make sure what Chris is writing works with that too
... let's say you have a very deep red, and want to match color in CSS
... If they both edn up on a regular display
... Need to make sure the colors still match

Florian: Chris is dealing with that

dino: 2nd thing we sortof agreed on
... a new ay to specify colors, along with color profile
... I figured a funciton named color() makes a lot of sense...
... How do you specify which color profile ?
... We had an @color-profile, but I was going to suggest some keywords for common profiles

Florian: I believe what e discussed last time was a funciton which starts with the name of the color space and an arbitrary set of parameters, not even necessarily numbers
... some predefined, e.g. sRGB
... And others name and link to ICC color pofile
... Not necessarily numbers, because might want to ue spot colors, e.g. Pantone
... I'm not sure it's happened so far

<bradk> PMS = Pantone Matching System

dino: We might write up a proposal
... I suggested that possibly an alternative to this is that we come up with another function that is defined to be colors space bt2020

<bradk> Pantone Matching System is trademarked or something

dino: Much bigger than sRGB. many monitors, HDTV, are aiming at that
... Hardware sometimes say it support,s but doesn't really
... Might say rgb2020...

Florian: This isn't a quick solution, because the problem isn't the synta,x it's color conversion
... Switching color spaces, syntax is trivial once you have the conversion math
... But need to have basic model in place

zcorpan: Whatever we come up with, should be consisten twith what we do in HTML for <canvas>
... Some idea floating around, abutou being able to point to an actual image and use the image's profile
... That seems could be useful

dino: The basic reason you'd wnat ot do that is authors don't know how to specify a profile, but do have plenty of images

zcorpan: So can pick a point on the image, and this is the color I want to match

Florian: I think that's sometihng we can do in the syntax we were discussing. Could point to an ICC profile, but could also point to an image and work within that image

dino: How do authors detect whether they're in a system that supports deeper colors
... Could use an MQ
... Does the output device have neough range to support all the colors in this color?
... Not necessarily useful thing to ask
... Could aks, is this the kind of like we have today, or better, or super-awesome?

<zcorpan> @supports (color: color('bt2020', ...)) { ... }

<zcorpan> ?

color: normal | good | awesome ? :)

<dbaron> dino: or if I support a color in this syntax, will it be clamped?

fantasai: @supports is for do you support the feature in the browser
... Media Queries is about querying the capabilities of the output device

Florian: For qualitative MQ...
... The difference between regular and fancy I can see, but in terms of actual authoring usage, what do you differently in terms of styling if you have a more-awesomer screen?

smfr: You might want to support different image assets

Florian: Even though you don't know how much "better" it is?

smfr: We'd specify better as ?? and even better as bt2020

<dbaron> smfr: ... which roughly equates to 10-bit color and 12-bit color

Florian: Bit depth of a color is not directly linked to the gamut of it, but broader color spaces tend to be associated with hgiher bits, because otherwise don't have enough precision

dino: awesome vs awesomer... mos tdevices in the consumer market say that they're awesomer, but they're only actually awesome

Florian: Most of them barely reach normal.
... Most screens don't cover sRGB color space, nevermind broader one

zcorpan: I wanted to discuss a bit about feature discussion
... If the syntax we come up with this is a color function
... And we allow profile
... And we say color profiles that are not supported are invalid
... then @supports is the right solution

Florian: old-fashioned @supports wouldn't work here
... The behavior we expect from a browser isn't to drop the declarations if not support the profile, but to convert the colors
... You support all colors, you just might not display them equally nightly

smfr: @supports is explicitly about asking about what features the engine supports. Swapping monitors doesn't change the results of @supports
... This is a question for media queries

Florian: Goal of discussion?

dino: Think there's reaosnable consensus. Might make direct suggestions rather than wiating for stuff to happen

Florian: That's the only sane want to do this

smfr: Would like to get an action on authoring tool vendors to give us feedback

SteveZ: I have no idea what the feedback will do, but certainly willing to take the action to try

<scribe> ACTION: SteveZ ask authoring tool people how authors can specify colors outside sRGB [recorded in http://www.w3.org/2016/01/31-css-minutes.html#action02]

<trackbot> Created ACTION-747 - Ask authoring tool people how authors can specify colors outside srgb [on Steve Zilles - due 2016-02-08].

dino: Feedback on how authoring tool vendors expect ppl to work with wide gamut colors. how do they choose colorsemits

astearns: How can they choose colors in a way that

's compatible with how the tool outputs colors

smfr: It's not just chooseing colors in the UI, it's managing deep colro assets through the whole content management chain
... Final comment to make...
... I would love to see Firefox and Chrome start treating CSS colors as sRGB on wide gamut displays
... Specifically on new imacs,
... not getting color matched
... Colors get too bright, give you a headache
... Would like to see other UAs do color matching, hopefully that will also encourage them to give feedback

Rossen: Is this going into Color 4?

Florian: I think that was the plan

Rossen: That takes us to the end of the morning agenda

heycam: jdaggett said he'd send mail on Font OM
... so waiting on that

Transforms

smfr: Didn't have time to get all issues together
... No change to status since last time we discussed
... Waiting mainly on feedback from implementers, especially wrt preserve-3d behavior
... Spec was revised 18 months ago with new description of preserve-3d behavior and 3D context bhavior
... Got some feedback from roc, liked description but some issues wrt intersection
... Still have very poor interop among implementations wrt preserve-3d beavior. Particularly want feedback
... Fairly hard problems with getting a solid description of this
... Particularly with transform-style: flat
... and creating a stackign context
... Other side of it is, being wary of the compat risk of changing behavior
... So if we do change the spec, would UAs be willing to chang ebehavior
... Comapt risks are possibly high for WebKit, though may be willing to change behavior for non-prefixed (vs. prefixed)
... So might get a behavior split there.
... That's the basic status
... Also have a call for help with someone who knows more matrix math
... To help define things like backface-visibility
... If anyone has people who know transform math better, would be helpful
... Need also help editing

dbaron: I'm also very concerned about preserve-3d, esp interop for 3d in general
... One of my concerns has been that we hit an interop issue, and it's hard to look at the spec and determine who's right accoridng to the spec according to what's there
... Which is worrying
... It's been awhile since I looked at any of these
... I think we're interested in trying to improve interop
... Hard to commit to doing that at a particular time
... Probably for the next 2-3 months we do not want ot make substantive changes
... Because we made an architectural chagne, and we need to fix all the regressions first
... I think after that, would like to prioritize
... Don't have any particular concrete suggestions

<zcorpan> fantasai: most recent WD is from 2013?

smfr: That's out of date. I think dirk has requested public WD...

<zcorpan> fantasai: do we want to republish?

RESOLUTION: republish Transforms

IanV: Haven't implemented also because of an overhaul, will have to get back to you

smfr: Edge?

Rossen: Not a current priority for us
... Implementation we did a few months ago
... Implementing most interoperable version, which is older version
... I can get you an update

okay, tha'ts it on transforms

RESOLUTION: increase temperature of the room

<rbyers> Here are slides and video for the interop discussion I mentioned: https://docs.google.com/presentation/d/1pOZ8ppcxEsJ6N8KfnfrI0EXwPEvHwg3BHyxzXXw8lRE/edit

<Bert> franremy, you want us to call in to WebEx again?

<franremy> if not a too huge burden, yes

Writing Modes

koji: Some Japanese companies have been funding gtalbot and some test engineers for a bit more than a year
... Have 900 testcases for Writing Modes
... The team also ran the tests for most browsers, not every, but all the tests were mostly were run by test team
... We now know which tests doesn't have two or more interoperable implementations
... I want to share the status of that
... and figure out plans for moving Writing Modes to PR/REC
... One reason I'd like this spec ot move to REC
... is that other organizations, e.g. IDPF EPUB are relying on this spec
... but is not REC in CSSWG
... So if it's possible to move majro part of the feature to REC, that's helpful
... for those other orgnaizations

Florian: Different people in different organizations are differently sensitive to status of the spe.c
... people who care about Writing Modes care about the status and stability of the spec

koji: Wiki page there's a link to the status document I wrote up

http://kojiishi.github.io/generate-w3c-implementation-report/css-writing-modes-3/status-2016-01.html

<heycam> http://kojiishi.github.io/generate-w3c-implementation-report/css-writing-modes-3/status-2016-01.html

koji: Yellow row means that test doesn't have 2+ implementations
... Goign to go over the yellow rows

<franremy> Bert: works, thank you

koji: For section 1, all failures are for sideways-lr or sideways-rl
... These two values are added at TPAC, are at-risk
... These values are not interoperable
... Nxt section is 2: Inline Direction and Bidirectionality
... Almost 10 tests, all for new values for unicode-bidi property
... These do not have 2 implementations today
... Most of the layout tests are done by adding prefixes, btw.
... We run parsing tests without prefixes, but most layout
... unicode-bidi values currently only Blink is unprefixed.
... So these values don't have 2 implementations as of today
... Next one is 2.1: Specifying Directionality: the direction property
... As you can see from filenames
... failures are for sideways-*
... Then there is some failures for rtl+upright
... more unicode-bidi ... only blink unprefixed these values
... This test is controversial, tests bidi reordering algorithm
... CSS spec defines how to map CSS properties to bidi control characters. And unicode spec defines how toreorder characters based on bidi controls
... These tests are testign rendering results
... So it's not really testable for CSS only, can only test combination of CSS and Unicode
... For blink, these tests are Unicode failures

Florian: So you want the spec to progress, not block, on unicode failures

koji: We have a failure for row-reverse
... Don't know CSSWG strategy for combination of two specs

<zcorpan> fantasai: we don't have a policy, but maybe we could have a policy if you have a test that tests the interaction of 3 specs, should we be able to move all of the specs but the last one to rec

<zcorpan> astearns: if there are interactions where some specs are already in REC, ...?

Florian: Makes sense in general, but it's tricky if some browsers implement one spec and some implement the other

<zcorpan> Florian: if different browsers are working on different specs, unclear which specs are hold up

Florian: But in this case, see no problem

<astearns> s/…?/that could hold a spec back/

koji: Next is table progression
... We have a bunch of failures for atomic inline baselines for vertical-lr and multiple lines in inline-block/table
... Complex case, only in Mongolian
... vertical-rl passes
... So vertical-lr is less interoperable today
... There are a bunch of tests for text-orientation that fail
... orientaiton of unicode codepoints
... Uses JavaScript to render all codepoints
... Unfortunately that JS doesn't work for vertical flow
... in Gecko, it's failing
... But the reftests, Gecko passes
... So although these tests don't pass, I consider the property itself passes
... failure is in CSSOM View

fantasai: So Gecko would pass an equivalent reftest. I agree with that

koji: Next section we have some abspos failures
... No excuses, they are failures
... I want to note that abspos has lots of ocmbinations. Have 250 tests
... about 25% of test suite is about abspos
... Those 270 are combination of [lots of things]
... All the failure are about orthogonal flows
... When author sets abspos, that abspos box has different writing mode from its parent
... My take is that the basic cases of abspos are interoperable, but orthogonal cases are not really handled
... 9.1 text-combine-upright
... Most failures in parsing.
... Quite well implemented in Edge/Trident/Blink/Webkit
... But only Blink has unprefixed support
... For other layout tests, these implentations pass
... last section is 9.1.3.1: Full-width Characters
... Says that for text-combine, when author puts full width characters, shoud convert it to ascii characters
... Nobody implements that.
... Need to either make it... or remove it

fantasai: I think we can put it as a MAY, so won't block moving forward

Florian: Is this something to address with text-transform?

fantasai: No.

koji: After list of test failures, have list of non-interoperable items
... Questions?

Florian: Other than thing we just talked about, have you found thorugh these tests, areas where the browsers disagree with the spec but agree with each other in a way that suggests changing the spec

?

koji: Abspos is a little...
... It's likely unintentional, but as a result this browser test feals this combination, that one fails that combination
... That's what you call disagree?

Florian: These are clearly bug
... If we're trying ot rush to REC, might be tempted to change spec, so not something to do here.
... Is there a case where brwosers agree with each other, spec disagrees, and spec makes less sesne and should be changed?

koji: Full-width is the only one.

fantasai: Thank you Koji for this report, it's really excellent.
... I think from what we have here, we should encourage browsers to unprefix their implementations.
... That's a relatively simple fix to move a lot forward.
... Should also fix the full-width issue by changing to MAY in the spec
... Other than that, looks like some bugs we just have to wait to fix.

heycam: Looks like a lot of failures for sidways-*, maybe should drop

Florian: I don't think it's a big issue
... This syntax was introduced very recently, so not surprising people haven't caught up yet
... If everything else was green, would consider what to do with that.
... When you support the rest, supporting this is actually easy
... Nothing fundamentally new for these two values
... By the time we have the rest, I expect these can be fixed as well
... If not, then can drop
... But relatively easy compared to the rest of things.

koji: Depends who you ask
... But from viewpoint of relationship with EPUB
... text-combine is the only thing they refere to
... There is a possibility that if we can get text-combine, then we can move the all the rest to Level 4 and move all the rest to REC
... That make EPU people very happy

Florian: We still have to fix the other bugs

koji: Make undefined in L3, move to L4

<zcorpan> fantasai: i think we can probably make the epub happy by moving the snapshot stability

<zcorpan> fantasai: wrt sideways stuff, i think mozilla implements that correctly

<zcorpan> fantasai: the question is if other browsers will implement that

<zcorpan> fantasai: if it's just abspos issues that shouldn't be too hard to fix

<zcorpan> fantasai: if nobody is going to update to do sideways that that can be a problem

<zcorpan> fantasai: this report does a good job on what we should focus on

<zcorpan> fantasai: i'd prefer to not drop sideways because it's important for non-CJK use cases

<zcorpan> fantasai: this is new syntax from 3 months ago so we should give more time before we move to PR

<zcorpan> fantasai: there's a minimum time before we can move forward anyway

koji: REC doesn't indicate importance, but whether W3C saying these are interoperably implemented
... From that POV, if sideways are not implemented at somepoint moveing to level 4 is natural to me

Florian: I agree, just don't think we're at that point.
... I think if we revisit at next TPAC, likely there's a lot more green
... If by then sideways are the only thing holding us from PR, dropping makes reasonable
... I'm optimisitic that sideways values can be implemented as these other bugs rae fixed

SteveZ: Amazing job at getting so many tests together

astearns: Is work still ongoing?

<zcorpan> fantasai: another 5 months at least

Florian: Do the people who have worked on this test suite consider the test suite complete, or should there be more tests written?

koji: Hard question
... test suite is never really complete...
... I think it's a good level to move on, imho
... For me, if generally it's reasonable to say we could target PR for next TPAC
... One really blocking factor from my perspective is text-combine and upright
... It would be really if Edge can unprefix, or Gecko can implement

Rossen: If it's only about unprefixing, shoudl be possible

koji: Blink has unprefixed, WebKit is prefixed but good, Edge needs to unprefix
... If we count webkit separately from blink, we have two

Rossen: Let's not have that discussion now

heycam: I think xidorn was going to ask about all vs 2-3

xidorn: Is it just the value 'all' or also the digits values?

koji: Edge/Trident are the only implementations of 'digits'
... digits are at-risk
... And EPUB doesn't use digits today

Rossen: And yet they were the ones that were asking for it the most
... Because they didn't wnat to preprocess their content
... Representatives from Japanese publishing companies were asking the most for 'digits' to be implemented

Florian: Wanted to discuss earlier comment about bidi support comments
... How do others feel about those bugs?

koji: There is actually a Unicode test suite for UAX9
... Since the test is not really uni testable, Blink has a separate test harness to run it
... We have about 20-25,000 failures there
... Over 1 million testcases
... So its 2-2.5%
... I also converted that testcase to HTML and ran across browsers
... All browsers fail somewhere betwen 20-30000 tests
... So my current view on those failures is not to make those failures to zero
... But if users file bugs, then we try to fix it
... It's nto really hard to make failing testcases

Florian: Is it psosible to write the testcases to check the mapping is correct
... Even if underlying unicode is being wrong?
... Shoudl this hold up spec going to CR or not?

fantasai: I don't know. I'd ahve to look at the specific tests

SteveZ: Are these failures on simple testcases or complex combinations

?

SteveZ: How likely will real people come across the kind sof things that are failing?

koji: I don't speak bidi languages
... Looking at spec logic, so can't tell
... If bugs are filed in our database, we'll look into it and try to fix. Those failures not filed yet
... One more thing, not sure familiar with bidi-isolate
... In Unicode 6.3, 3 years ago, they came up with new kind of embedding, affects algorithm itself
... Everyone tells me isolate is the way to go in the long run
... We're moving twoards it
... Talked about it last TPAC with Apple and ?
... We're working on it
... Among those failures, many are for old embed style
... if you limit test to isolate mode, we have less failures
... Depends on timing, not sure how much want to fix those embed failures
... If everyone has moved to isolate mode, people might not be using embed
... But still testing this, so test might fail

<zcorpan> fantasai: if embed is what's failing that's stuck in CSS 2.1 and we can move on

<zcorpan> fantasai: need to make sure the mapping is correct and we're trying to do the right thing wrt nesting etc. can say edge cases is unicode's problem

<zcorpan> fantasai: if you load a plain text with all the code points instead of CSS and it has the same failures then it's not our bug

koji: So next step is ask fantasai to look at test failures and get some feeling

<scribe> ACTION: fantasai to Look over Writing modes test failures [recorded in http://www.w3.org/2016/01/31-css-minutes.html#action03]

<trackbot> Created ACTION-748 - Look over writing modes test failures [on Elika Etemad - due 2016-02-08].

<scribe> ACTION: gregwhitworth to Look into unprefixing text-combine-upright [recorded in http://www.w3.org/2016/01/31-css-minutes.html#action04]

<trackbot> Created ACTION-749 - Look into unprefixing text-combine-upright [on Greg Whitworth - due 2016-02-08].

<scribe> ACTION: hober to Look into unprefixing writing modes features in WebKit [recorded in http://www.w3.org/2016/01/31-css-minutes.html#action05]

<trackbot> Created ACTION-750 - Look into unprefixing writing modes features in webkit [on Edward O'Connor - due 2016-02-08].

<zcorpan> fantasai: in the spec we should change full-width transform to may?

<zcorpan> fantasai: any combination of 1 to 2 digits should be upright

<zcorpan> fantasai: and you have a sequence of 2 digits, the spec says first try ot squeeze these ...?

RESOLUTION: Make TCY fullwidth->proportional transform optional (text-combine-upright)

<zcorpan> Rossen: let's focus on L3 first

<zcorpan> fantasai: i'd encourage blink and MS teams to look into sideways values

<zcorpan> Rossen: we'll "look" into it

<zcorpan> fantasai: sidways-rl at least should be easy because it's mostly the same as text-orientation: sideways + writing-mode: vertical-rl

Line Grid

koji: The line grid, this is a proposal

<astearns> https://github.com/kojiishi/snap-height

koji: The basic idea si tha tline grid spe chas been around for 3-4 years without enough itnerest from implementers
... I just wonder if it can be more itneresting if the spec is simplified
... This is a proposal to try to simplify further
... I want to see if this increases implementer interest, and also if it will still be interesting for solving use cases
... One thing is world is chnagin in 2-4 years
... Last time we discusse,d I googled about vertical rhythm or line gird
... All I hit was professional typography papers
... But this onth when I go searching, everyone is talkinga bout CSS, how to do it in Web browsers
... People are doing lots of complex calcuations useing SASS and SASS macros
... To provide that kind of cpaabilities
... I think this demand is coming to browsers, an dpeople are hacking around
... But hacks do not when page is zoomed
... Or are not responsive
... So doesn't work for mobile browsers or desktop browsers
... People are trying to sovle, but there is no really good solution yet
... So even with minimum level of line grid
... I'm seeing it solves, helps a lot of web developers today
... Overview section of proposla
... Speaks how I tried to simplifi
... Zbasically 2 point sof siplifying
... One is instead of snapping to grid, this propsal tries to control heights
... So that eveyr line and box is multiple of grid
... As result of stacking, produces a grid effect
... Send point is instead of defining grid for elements or named grids
... We can now rely on CSS custom properties to define a value across documents
... So no longer need to define grids, just accepts values
... Assume sthat CSS can custom properties can fill in the gaps
... Propsoal follows
... wrt naming, talking to peole, since only height,s not really a grid
... But pls disregard naming for now
... FIrst item is snap-height
... Very similar to line-grid
... Takes none or length
... What it does it just increase the height of line
... to be multiple of specified line length
... There is an example below
... With help from css custom-property
... You can make all line heights as multipel of specified value
... Ther ewas some discussion of margins being multiple of grid unit
... With custom properties, this is easy to achieve
... Just use calc and custom properties combination
... 2nd feature is snapping to Baseline, primarily for Latin
... This has a little tricky expression
... The basic idea is that author specifies in teh grid, where you want to draw a virtual baseline
... Control spacing os that the baseline matches to the specified ratio in the grid
... Does that make sense?

astearns: This doesn't work
... If you have 2 lines snapping to different multiples
... One to one multiple of a lenght, and one that is 2 multiple of the length, then ration is not going to get the baselines to align

koji: Ratio is for one grid, ifyour line is higher than one grid, you skip one grid, matches to same ratio of next grid

Florian: ...

SteveZ: If you've got a big descender, might creep into next box

koji: basica idea is to round up line-height ot multiple of grid
... Then shift so that baseline matches to specified ratio

SteveZ: So I've got a "q" that's 3x larger than the other font
... I move the descender to match the 3rd baseline down, and then that descender is going to go well below the line box

koji: But baseline matches...

astearns: I think the idea of snapping heights and widths to multiples of values is probably a useful thing
... I don't think it does enough to give you a vertical rhythm features
... I think you should just drop the baseline ratio thing, and just get the multiple widht/sheights thing you're looking for
... How this proposla matches up to giving the Web a vertical rhythm feature
... My main concern with this, like with existing solutions, have to control everything on the page in order to get it to stack up right
... If anything is not participating in this multiple-height scheme, it throws off the rhythm
... in ordre to have a vertical-rhythm, really need to have a grid that everything is working towards
... That means you define a grid that things can participate in
... You don't try to give every itme on the page a particular height to make it ocnform to a grid that doesn't exist
... There are too many failure modes to constructing a grid out of making things conform
... You really have to have a grid, and have thing participate in the grid or not
... to get the vertical rhythm feature

koji: I actually understand the concern, but if author wants vertical rhythm, he has to pay attention to every space anyway
... How it fails differs by having a grid or controlling heights
... If you have a grid, fails, need to jump to next grid
... Author doesn't want that big space, it's a failure anyway

Florian: I think my view is similar to Alan's
... You are right, this is probably simpler to implement than exisitng proposla for line grid
... Increasing chance of happening is useful
... In very controlled situation, can get decent results with this
... But it's quite fragile
... So many situations that will break the rhythm
... If it only sort of works, instead of really works, then we still want the other proposal
... If we implent this sort-of-works thing, is that worse because we sort-of-solve the problem?
... And therefore not motivated to fix the good enoug h thing?

koji: I actually agree with that
... I'm not saying grid is bad
... I'm fine to have 2 specs, Level 1 / 2 or something
... But for the fragility, it exists even with grid
... Poeple who care about rhythm also care about unintentional large spaces
... So if fail to set space correclty, not pay enough attention, they either i nthis proposla they break rhytm
... In real grid they get big space, which is also bad
... That's my view

astearns: It's the same problem in both
... I fyou have something that doesn't fit the grid
... in your proposal, then get a space
... in grid, you ge ta space, but rid is also resumed
... Once you have a stacking failure in this proposal, then eveyrthing is off

koji: That's true, so I'm not ..
... My propsal is ony that before we have grid, is this good to have or is it useless

astearns: Like I said, I think snapping to intervals is a fine feature to have
... Ohter use cases for that also
... Probably belongs to sizing module

SteveZ: Coudl you extend line-height using the algorithms that you're talking about, so it always came out to an integral number of the snap unit?

astearns: Doesn't give you a different proeprty, just a different way to have line-height
... Could have something that's a new lenght type
... a function, or lenght unit
... I'm not sure

koji: I thought about it, but functions or unit can introduce complex cases because can apply anywhere
... Goes against making things ismper to implement
... The other one, is after this one, I applied it to block heights
... I don't care much about syntax or how many properties to use
... But not really positive about making too general

Florian: You were asking whether useful or useless
... I think this is useful
... But I'm conerend about being a little useful, but not enough, and decrease priority of real solution

astearns: I'm not as worried about it, as long as we don't sell this as a solution to line grids
... Another argument for doing more generally is that line box heights, or block heights, maybe they are the only thing that stack...
... But I assume people would want to use multiple sof a particular length for margins/padding/ other things

Florian: If the mltiple is 1, then we can probably itnroduce a unit that is the linehight
... And you can use margins and paddings in that
... I can easily imagine ...

<zcorpan> fantasai: if all of you margins are a multiple...

fantasai: I think I see 1.5lh on top and bottom margins being useful

SteveZ: Also have to worry about margin-collapsing

fantasai: No, not really a problem. If all input marigns are multiples, output marign will be multiple

koji: Flroian's concern is hard to answr
... But when I google veritcal-rhtyhm css, 37K hits
... These are asking how to do that

Florian: Pain is great, want to solve problem as well

koji: I know ppl hate to hear this, but Word shipped this height feature 20 years ago
... from what I hear from colleagues, not hearing any compaitns about that. Turned on by default in East Asian versions

Bert: If I understnad correctly, was looking at Exampel 1 in current line-grid spec
... Trying to figure out how to do that in Koji's spec
... but can't figure out how to do that.

astearns: You'd have the headline's block-height snapped to a multiple of the line height
... and levae the line boxes alone
... The line boxes within the headline would stack as you see it in the example of the spec
... You'd just have more space above and below
... In order for the next paragraph to fit on the gid

grid

Bert: Wondering if that's possible to specfy with snap-height

Florian: You would need to use it with custom-properties so you have a repeating value

astearns: There would have to be a block-height-snap added to koji's proposal

koji: If the heading wraps to multiple lines, Alan is correct
... If it's simple line, then it works

SteveZ: That's an example of the problem!

koji: Here the heading is larger than one grid, so automatically expands to 2 grids
... As you see, centered to 2 grids
... Hvaen't explaiend that yet, but see below -- snapping block boxes option

astearns: So, interest?

koji: I'm interested in this, any other implementers?

Florian: Vivliostyle might be interested. We're interested in this, not sure what we will cosnider first

<zcorpan> fantasai: the border box the margins added to it

fantasai: How feausible is it to have a property that snaps the margin-box height of a box is the box to an interval of length X

dbaron: what's a margin box?

<dbaron> (in the presence of margin collapsing)

dbaron:

astearns: One failure mode of the SASS approach is solved, if eveyrthing buys into this model

fantasai: Could you do it with the border box? (dbaron??)

koji: Adjusting line-height, adjusting margin is second part
... That's problematic?

Rossen: In general, if you marry the size of a box to the its position
... If you're fixing the height of the box base don its position
... Then the problem becomes hard

dbaron: So, if you were to
... I'm curious why you want the height

fantasai: The goal is to snap the height of an element's margin box to a multiple of the line height

dbaron: If it always breaks margin collapsing, then maybe it's implementable

Florian: why does margin collapsing matter here?

fantasai: If we don't have any collapsign margins, does this work

dbaron: Part of the issue is, is there going to be a problem when you try to implemnt and fuzz it, and is there an infinite loop
... hard to answer off the top of my head

Florian: For this use case, if it would be with an uncollapsible marign, that's fine
... Not sure if that's necessary, but if necessary to make sane to implement, sounds okay

dbaron: To e clear, my worry is about the margin inside the box collapsing to outside the box

koji: I myself don't really understand margin collapsing code atm.

Rossen: It's pretty straightforward. :)

koji: I'm sure I'll run into issues
... But haven't discussed how block snaps in my propsoal

fantasai: I'm actually more worried about line part than block part

koji: There's a talbe about use cases and what gets adjusted
... I'm seeing that centering is quite difficult for us
... For first phase, only adjust margin-bottom
... After layout
... After height, determine positoin
... Height or margin is nto affected by position in this proposal
... Only about adjusting mragin bottom, output from height

Rossen: Are you looking into A) sampling impelmenter interest B) moving into a spec and making a spec out of it or C) both
... Think we should star twrapping up

koji: Asking both
... Wnat to see how much technical trouble sI would go into by experimentally implementing in blink

Rossen: Is this something that should move to line grid spec?

astearns: I'm of the opinion that this should be a more general thing
... that can be applied to any length
... It's a multiple legth, will snap to a multipel of the length you supply
... useful thing in all sorts of situations

fantasai: I think it's a useful direciton to go in. Wouldn't implement just yet, want to work out e.g. interaction with margin collapsing etc. before trying to implement.

koji: So make an ED?

fantasai: Yeah, work out the details a bit, then decide where to put it

Rossen: For the B) part of the question is, let's start with an editor's draft, and go from there
... For other ones, implementers intent, that's an answer that we'll be getting as we work on the spec
... At least our reaction is, this is an interesting problem to solve
... Heard quite a bit in tersm of itnerest at least in Japan
... That was one of the ver clear asks from the Japan Industry Meetup
... Would we just throw everything away and star t workin gon this immediately, probably not

Florian: Another comment

Rossen: Not sure how much will bring to the tatle
... If there is an implementer really interes,t engage with koji
... Otherwise let's take a break and come back for ...

RESOLUTION: Make an ED for snap-sizing

RESOLUTION: Editors koji and fantasai

<Bert> (As the use case is double-sided printing, I guess it is more interesting if PDF formatters want to implement it than browsers...)

<liam> (i think that's only one use case, but also it'd be a mistake to think people don't print web pages)

<br>

Florian: For CJK layout, in addition to line height snapping, it's important to do the same thing in the inline direction
... The problem is slightly simpler, don't need to snap every character. Line length is sufficient.
... When you want ot do such a thing, you use a font where each character is exactly the same width
... No need for magic
... The other reason is that at least in Japan, and mainland china, if some chars aren't full-width
... You don't line up to the grid, you line up the start and the end and justify between
... There are some cases where you want something else, but usually that's enough
... Koji's spec, and mine, trying to addres sworking on that line being a multiple of the char width
... So that it works fine within the line
... My proosal is an extension or varant of the line grid spec
... Koji's proposal is more in line of size snapping
... Same diferences apply
... what we discussed briefly uring the break is that we can add my propsoal to line grid spec
... and as we work in parallel on line gri dspec and snap height,s do the same thing on these two features for inline axis

<franremy> Bert: discussed it with astearns; you can disconnect now

Florian: Proposal is to fold my proposal into Line Grid spec and figure out detaisl there

<franremy> I will follow using the irc

SteveZ: One comment -- seems to be em based, need to use multiple of ideographci advance which is not necessarily 1em

<franremy> Bert: thanks for asking

Florian: Need to base on a different char
... Similar to ch unit
... Should probably use that unit instead of em

fantasai: On the topic of units, we've discussed line height unit and ideographic char unit. Are there othe runits we need, maybe add to Value sand Units 4?

Florian: Wanted to add my porposal to spec

fantasai: We deliberately left it out to keep the draft simpler

<franremy> Bert: for me too ^_^ 9PM here -- have a good afternoon!

<gregwhitworth> thanks @franremy :)

astearns: I'm okay to add bakc in and split out later

Florian: Would prefer to have it in a spec rather than in ppl's heads

<Rossen> franremy, thanks for joining

fantasai: I would be okay with it if we clearly mark it as targetted at level 2

Florian: Second issue is adding unit for ideographic character

fantasai: Seems useful for me
... Would be a unit based on the advance width of the character for water.

dbaron: Need height and width

<dbaron> ...since it has a fixed orientation

fantasai: So ih and iw?
... Does it need just a single thing that's the advance measure?

dbaron: If you do that, need to write down entire property dependency grpah, to make sure it doesn't introduce any cycles

RESOLUTION: Add ideographic advance unit to Values and units 4, come back to WG for approval after details worked out

Oveflow

<dbaron> https://wiki.csswg.org/spec/property-dependencies

<gregwhitworth> scribenick: gregwhitworth

fantasai: Tab and I took the overflow module and trimmed it down to overflow-x and y props
... we replaced a lot of issues
... As we discussed in the past there is ink overflow and scrollable overflow
... The x and y props have the clip value, everything else is pretty much what is in browsers today
... there is a placeholder for max-lines prop
... we're going to go over these issues

dbaron: why is max-lines in here instead of overflow 4

fantasai: it's probably going to get dropped
... The first issue is - [reads issue]

dbaron: what is hanging punctuation
... I know what it is conceptually, what does the purpose of the prop

fantasai: it does not measure the glyph that is hanging outside of the box

dbaron: only if it's at the end of the line?

fantasai: yes

fantasia: I don't know what's correct, do you want it to clip or to scoll?

stevez: Why would I not increase the size of the box so there is room for the hanging of the punctuation

plinss: I think it's just ink overflow

astearns: This is a complete surprise to me, when did this happen

fantasai: I forgot we didn't check with the CSSWG, but Tab and I did talk with the editors, we wanted to look into this. The x and y props have existed for about 15 years in all browsers
... We've been needing to refer to ink and scrollable overflow for while from other specs, and currently it sat in the overflow spec but that's all brainstorm level and we need implementation detail right now
... That's basically why we trimmed the spec down to only contain those two things so that we can solve these actual issues with the stuff that is implemented

florian: Also you didn't modify the spec

fanatasai: yes we forked the spec and changed this stuff in a separate repo

fantasai: we did this a few days ago

astearns: Ok. But having notice before the meeting would have been helpful

fantasai: difference between ink and scollable overflow, if I have a box with no margin/padding etc, everything outside the box gets clipped if it's scrollable overflow. Ink overflow you can't scroll to see it (box shadows, image backgrounds, etc) spill outside of the box but we don't increase the box so you can see it
... is it the author's responsibilities to fix this issue?

takao: at least the shadow does not expand the cursor, but hanging punctuation should expand the cursor

rattan: if you have hanging punctuation inside of something that is not scrollable, should you be able to see it or not?

stevez: no
... what I hear takao saying is that the content box needs to make space for the hanging punctuation to make space for the cursor
... it's not accessible that it requires a scroller to see it

rattan: when we compute scrollable bounds it can be impacted multiple things. Back to the questions, are hanging punctuation included in that calculation?

stevez: the real question is why are you making it overflow?

rattan: because that's how it broke in this case.

stevez: if I resize the window so I have to scroll anyways, then the hanging punctuation should be scrollable too, but if I turn on hanging punctuation you shouldn't need to scroll

fantasai: that's not how it works

plinss: turning that on makes it say that hanging punctuation should not be included in calculation for content box

rattan: reads from spec

plinss: by definition you're putting it outside of the box

fantasai: that is the definition of a hanging punctuation

rattan: if you have a float that has one line, no padding, no border, no margin in shrink to fit, what happens?
... if you add to that same example, you add overflow-x to that should you be able to see that comma or not (example is in that spec)

plinss: not necessarily

rattan: then in that case, it's ink
... however if this was considered the same as inline abspos element which is not considered for it's space, but it is considered for scrollable bounds so you would be able to scroll to it?

florian: based on your argument if you drop some of the text I think it should be scrollable

plinss: That makes it so that if you have a simple comma at the end you'll end up with a bad user experience where content is being scrollable. That's on the author

bert: I agree with Florian, by default it should be scrollable, maybe what stevez said that it should be part of the content

rattan: it would be if it was overflow: hidden

florian: but you're asking for it to be hidden

fantasai: I'm fine making it scrollable, I don't care

stevez: if the padding is there would it still be scrollable?

dbaron: re-ask your question

<Bert> (if width is 'auto', it will not scroll.)

stevez: if I turn on scrolling since the comma is hanging over the content box and I do have padding

dbaron: you won't get scrollbars because you don't have content that's extending outside of the padding box

stevez: what I don't want to do is turn on scrolling because I turned on hanging punctuation
... when authors see the scrollbars they'll learn to add the padding

Tantek: are we only talking about the hanging punctuation at the end of the line

fantasai: both

Tantek: How do make the scrollbars go away is a common request from devs
... Let's not make that worse
... I'll just use negative text index

dbaron: This will not cause any more scrolling than negative text indent will
... it will only cause scrolling if the quote mark would have been partially hidden

tantek: and that would happen with negative text indent as well?

dbaron: yes

stevez: not if you add padding

tantek: not sure I believe that without a test case
... It's very annoying

rattan: is it more annoying than not seeing the content?

tantek: yes

rattan: then it's ink

fantasai: I'm leaning towards scrollable overflow

plinss: does shadow cause scrolling

fantasai: no

plinss: hanging punctuation is similiar

*murmurs*

<zcorpan> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3851 - i don't see a scrollbar here (negative text-indent outside padding box)

plinss: I do not want to wrap or break text due to a comma overflowing, this is how it's done in page layout and the author should not have turned on this feature
... making the user scroll is also punishing the user

<fantasai> Florian draws a CJK period glyph, where the period is in the bottom left corner of the em square

xidorn: in some forms the punctuation could take a small portion of the area, like in simplified Chinese it's at the bottom left corner. If we make it scrollable it could be very confusing

s/xirdorn/xidorn

<dbaron> dbaron: I'm ok with just doing ink overflow then

florian: can we do a hybrid thing where we measure the size of the glyph bounds?

dbaron: no, no, no
... In particular I'm not ok with that because glyph overflow is not scrolling overflow and that's very important

plinss: this is morally the same thing as a big swishy glyph

florian: if you remove the punctuation you may not understand it, it isn't the same as text shadow
... trying to handle the error case well should not get in the way of handling the correct case

RESOVLED: Hanging punctuation causes ink overflow

fantasai: next issue is about masking
... if you mask stuff that's overflowing do we clip it in regards to scrollable overflow
... if I have a div with overflow: auto, and I put an abspos div we'll put a scrollbar to allow you to see it
... what about masking?

astearns: masking can only partially occlude the content?

Elliot: are you saying that clipping impacts the scrollable area

dbaron: yes, clip does and mask does not

Rossen: probably for a good reason

florian: what for, I would assume they would be the same

dbaron: clip has always been that way and it would be a lot of work to do that for mask

fantasai: *made a quick testcase*

<fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0A%20%20div%20{%20height%3A%2050px%3B%20overflow%3A%20scroll%3B%20border%3A%20solid%3B%20position%3A%20relative%3B}%0A%20%20p%20{%20margin%3A%2025px%3B%20background%3A%20red%3B%20position%3A%20absolute%3B%20clip%3A%20rect%280%2C0%2Cauto%2C%20auto%29%20}%0A%20%20q%20{%20position%3A%20absolute%3B%20background%3A%20blue%3B%20top%3A%2025px%3B%20margin%3A%2025px%3B%20}%0A[CUT]

<fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0A%20%20div%20{%20height%3A%2050px%3B%20overflow%3A%20scroll%3B%20border%3A%20solid%3B%20position%3A%20relative%3B}%0A%20%20p%20{%20margin%3A%2025px%3B%20background%3A%20red%3B%20position%3A%20absolute%3B%20clip%3A%20rect%280%2C0%2Cauto%2C%20auto%29%20}%0A%20%20q%20{%20position%3A%20absolute%3B%20background%3A%20blue%3B%20top%3A%2025px%3B%20margin%3A%2025px%3B%20}%0A[CUT]

<fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3852

fantasai: it should reduce the scrollable area due to the clipping

dbaron: FF/Edge don't scroll, Chrome scrolls

Rossen: I think that matches 2.1

dbaron: wait you think 2.1 defines that

Elliot: that was the one part that was specific

fantasai: reads 2.1 spec

Rossen: for this case, FF/Edge works correct

Elliot: We have two implementations that don't
... We have to measure

fantasai: we have two implementations and a spec that agree

Elliot: I don't think we'll implement masking because it's too expensive

fantasai: I don't care, I just need an answer

astearns: there's a lot that you would have to define to determine the bounds of the mask would apply, etc

dbaron: the other question, do you take the bounding box of the mask before or after the intersection of the scrollable bounds

Rossen: We would have to implement masking within layout in order to take into account all of the children that are to be masked
... *gives an example*

fantasai: that's the question I'm asking

dbaron: I think we should, it may have been a mistake that clip does this. I think that both clip and mask should not
... if you want to do it right, you have to keep scrollable region in sync with what mask and clip support, not just a rectangle

*draws another potential issue due to masking*

dbaron: I just don't think it's worth going into all of this

fantasai: my inclination is to have clip path do the same as clip, as an author it would be confusing if I clip something and I still get a scrollbar
... with masking it's very difficult because you're you can mask with images etc

dbaron: doing it with clip is very hard, and web authors do care about perf even if you don't

florian: tantek as dev rel which do they need more, scrollbars or perf?

stevez: the authors will wonder why the scrollbars will be there

Elliot: webkit uses a very simple model, visual overflow or layout overflow, anything that is NOT css overflow is visual overflow. They're computed during paint

rossen: it's the same in our implementation

<zcorpan> 160050 resources in httparchive that have both overflow:scroll|auto and clip:rect( -- seems difficult to check which of these would regress by changing (i'm happy to dump this table if anyone wants to investigate it)

smfr: my recollection is that webkit does clump visible overflow and the old style clip property, but I agree with dbaron that it's probably too expensive

<esprehn> https://developer.mozilla.org/en/docs/Web/CSS/clip

smfr: I would also like to see someone else implement clip path

<esprehn> the example is scrollable in Safari and Chrome

dbaron: I believe we implement clip path

<esprehn> and not in Firefox

smfr: maybe it was masking

Elliot: I posted the moz example, it's scrollable in wk/blink but not in FF

*everyone looks at MDN testcase*

<esprehn> doesn't look scrollable in Edge either

rossen: I heard almost all of the implementers not want to support mask and clip path in scrollable bounds

astearns: given that, there are two ways of going - put in this draft that there is a legacy capability
... Or, since two of them follow the spec and two of them don't we could have in the new spec say that none of affects scrolling

stevez: it's clear that no bugs have been filed on this

esprehn: the clip path is used on 31%

<koji_> https://www.chromestatus.com/metrics/css/popularity#clip

zcorpan: it's on 160K resources from httparchive (which is live sites)

ojan: either way it's way too high
... we don't have a good way of measure it though

rossen: we need a resolution, after 28 minutes of discussion are we ready to resolve
... we can take a straw poll or put it up for resolution that clip path and masking do not effect scrolling
... who wants to have clip path and masking to affect scrollable bounds

florian: who cares

rossen: I'm just asking so that five or ten years from now we're sure that we're not just resolving for the sake of this

plinss: We should allow authors to declare random shapes and allow those shapes to affect scrollable bounds, maybe that's shape inside

RESOLUTION: Hanging punctuation causes ink overflow

RESOLUTION: Clip path and masking do not affect scrollable bounds

florian: do we leave clip alone, or do we address this first?

esprehn: I said that we care about this, we'll measure this and discuss it with the working group

<esprehn> :)

<scribe> ACTION: esprehn to Look into compat for clip affecting scrollable bounds [recorded in http://www.w3.org/2016/01/31-css-minutes.html#action06]

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

<scribe> ACTION: esprehn to Look into compat for clip affecting scrollable bounds [recorded in http://www.w3.org/2016/01/31-css-minutes.html#action07]

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

<astearns> <fantasai draws>

dbaron: we have a special pass for 3d transforms

florian: is this the situation where we should use a 'should'

<Rossen> [fantasai draws a picture showing two nested, transformed boxes that endup affecting the scroll bounds]

florian: one behavior is better, but more costly

<smfr> the issue is with two nested transforms, e.g. rotations

<fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/

<smfr> 2 ways to implement overflow tracking:

<fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3853

gregwhitworth: Based on what tantek says, I don't think we should allow for scrollbars in one UA and not another, with no clear way to fix the scrollbar

<smfr> 1. track an axis-aligned bounding box at each level, but that can lead to bounding box explosion

<smfr> 2. track corner points through all rotations, and do bounding box computation once at the end

<smfr> 2) is more accurate but more expensive

fantasai: it has scrollbars because the height is calculated based on what's in flow, you can adjust the scale factors to get different effects. It's overflowing in FF

<fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3854

dbaron: so.... I have a different testcase

<dbaron> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3855

rossen: interop
... so back to the issue

fantasai: what do you want in the spec

florian: we have a trade off between scroll bars and perf

fantasai: in all cases you're triggering scroll bars where stuff is not visible

dbaron: it's way easier than the clip path situation

fantasai: how?

smfr: I think it's fixable, but will any UA change?

<dbaron> I think you'd just need to maintain a set of points and could probably cull a lot of them.

zcorpan: I think there needs to be a really good reason to change away to something else when we have interop on this and no one is complaining

<astearns> +1 to zcorpan's point

<hober> zcorpan++

dbaron: I wouldn't quite say no one complains

<dbaron> dbaron: but still in favor of not changing

tantek: If better behavior is possible then I would suggest a should

fantasai: I suggest making it a note where we can state what it will do and say that the WG is open to other implementations trying it and us possibly changing the spec
... I wouldn't recommend making a should on the cheaper thing, the should be on the better thing
... is there an RFC...?

<zcorpan> next topic?

plinss: must but we know you won't

rossen: let's do that

fantasai: this is a whole mess of issues regarding transforms
... You may calculate it more precisely but...

astearns: We would like to see suggestions for how all browsers could make improvements in lock step

rossen: that's exactly how I feel

astearns: we should encourage people to provide solutions, but let's not request breaking interop

fantasai: it's not hard to spec, but making it hard to implement

stevez: we need a compelling use case to make the implementors want to change

RESOLUTION: Spec the current behavior and add a note that this could be improved

<dbaron> (do we want the note to make Alan's point about improving in lockstep rather than breaking interop?)

fantasai: do we want to keep border box overflow in the level of the spec?

rossen: isn't the point of this spec is to define what we all do

dbaron: this is what we do for outline, and outline is very loosely defined

rossen: basically that outline is not ink

dbaron: most implementations do outlines around border boxes, that means the outline does not go around descendants where as we union the descendants to outline all of them

rossen: what do you do for inline?

dbaron: we do but we don't do the thing where we merge the lines

<fantasai> Sorry, I forgot to regen the spec. The previous issue's testcase was this one: http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20class%3Dparent%3E%3Cdiv%20class%3Dchild%3E%3Cdiv%20class%3D%27grandchild%27%3E%3C%2Fdiv%3E%3C%2Fdiv%3E%3C%2Fdiv%3E%0A%3Cstyle%3E%0Adiv%20{%20padding%3A%2030px%3B%20min-width%3A%2030px%3B%20float%3A%20left%3B%20border%3A%20thin%20dotted%3B%20background%3A%20rgba%280%2C0%2C0%2C.2%29%3B}%0A.pare[CUT]

florian: IE does some complex shapes, but others don't. Other people recently said to leave it undefined

rossen: in other words, take this out of the spec

<fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3856

dbaron: yeah... uh...
... web devs want outline to be just an additional border, it would be nice to have a formal spec
... yeah I'm ok dropping this

florian: we can discuss it future versions

RESOLUTION: Drop border-box move to UI or Overflow 4

fantasai: there was another issue where the scrollable area with abspos elements
... edge/ff don't include the margins of the scollable areas
... we think that is author hostile
... we want to present that issue to the working group

dbaron: you're saying margin box only for abspos?

fantasai: the others include the margin box

dbaron: only some of the time, we don't normally include the margin box in scrollable overflow, we scroll to the collapsed margin

<fantasai> Testfcase:

dbaron: we did kind of agree to changing to what webkit does

rossen: was this found on broken content?

<fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3857

rossen: this is for abspos?

fantasai: yes because we have interop

dbaron: I doubt that

fantasai: for inline content we take the line boxes

dbaron: no we take the border boxes

zcorpan: but it's interopable

dbaron: but not on the margin boxes. I'm pretty sure if you have a large padding and border on a span, it will increase the scrollable area, but not the margin
... I'm interested to see what webkit does here

fantasai: Blink does border-box for inlines

<fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3858

dbaron: I would suggest more research is needed here
... I think it would be better to get the big picture here, to see how the implementations vary beyond just abspos

fantasai: what specifically

dbaron: floats, relpos, blocks where the margins do collapse through to the scrollable area and vice versa
... and probably inline side margins as well

<fantasai> dbaron: and inline side margins on blocks and inlines

fantasai: my general thought though, is that we don't provide breathing space for an abspos

rossen: kind of like an inline case

fantasai: I don't really care about the inline case

hober: webkit matches FF/Edge on those testcases

rossen: so you're saying that one implementation is doing it wrong and you want all of the others to change

fantasai: at least that implementation allows breathing space and you can remove it if you want

<esprehn> what implementation behaves differently?

dbaron: but there are other test cases that need to be done to ensure that we're getting a consistent end result

rossen: ok
... let's move on
... are you looking for a resolution

fantasai: it looks like people are wanting more test cases

zcorpan: it would be nice if we get feedback from web devs

fantasai: the one issue we have is whether or not if clip should cause a bfc

rossen: which one?

fantasai: ff does not create a bfc

rossen: I thought we discussed this
... as soon as it becomes a bfc those margins won't collapse

fantasai: the margins don't have to be large

rossen: also if you have floats within the bfc the inline content will be affected but it won't be visible
... which is the really weird case

ojan: is any vendor interested in implementing this

florian: yes there is a dependency by contain

ojan: and we think that dependency should be removed
... I don't think we should add all these weird things in computed style

florian: if overflow is visible and you have containment, what happens
... the reason we wanted it to change was something else depends on it, the text-overflow property
... if it's visible you can't have the ellipses affect
... that would cause the scrollable byte buffer would be created and that's a perf negative
... you need this to avoid that, or something

ojan: that is definitely a legitimate use case

florian: also resize

ojan: I see...

florian: there may be another solution

zcorpan: then we could have those other things look at containment
... I'm not sure which one is better on the impl side

florian: moz has a variant of overflow: clip without containment

ojan: do other impl have thoughts on this?
... is anyone thinking about impl this (I know Apple can't say anything)

<fantasai> https://lists.w3.org/Archives/Public/www-style/2015Jul/0459.html

ojan: then the separate thing, should the containment spec depend on overflow clip or text-overflow/resize depend on CSS UI

nevermind on the last 20 minutes of discussion

rossen: anything else?

fantasai: there's a thing on overflow style, florian?

florian: when you want the scrollbars to be overlay scrollbars, or autohiding scrollbars, should we support this and how should we support this?

<ojan> can we put up an issue to discuss (tomorrow) about this CSS containment + overflow:clip issue?

rossen: just use the -ms-autohiding

<zcorpan> [side discussion -- knee jerk reaction: containment shouldn't affect computed style of overflow and containment shouldn't affect resize/ellipsis, not author intent]

florian: my only issue, is that you get the choice between space consuming or autohiding

esprehn: we have overlay which is in webkit and blink

<tantek> ojan put the issue as the first thing on https://wiki.csswg.org/planning/sydney-2016#tuesday-am and let's see how it goes

<fantasai> Florian++

florian: I like the ms one because it has fallback and you want them to cascade independently instead of having this on overflow
... I support the MS behavior

<astearns> tantek, ojan - afternoon rather than morning, as there's probably no one that needs to call in for it

esprehn: why do you want to change all scrollbars on a page?

<tantek> astearns: makes sense. https://wiki.csswg.org/planning/sydney-2016#tuesday-pm then

esprehn: we have authors arguing that scroll bars taking up space

fantasai: we all agree with that

esprehn: they're the same person making this determination

philipwalton: I think you're saying the same thing

esprehn: do they overlay?

rossen: it's up to you
... the styling should be different than making it a scroller or not

<ojan> astearns, tantek: thx. that's better for me since i can't be here in the morning. :)

esprehn: you run the risk of the scrollbar covering up content

fantasai: if you're reserving space, why have them overlay?

rbyers: it's for auto, you want to auto scroll and be transparent, but it overlaps

fantasai: that makes sense

florian: auto reserve or something like that?

fantasai: that would make more sense than the author guessing the size

smfr: overflow: overlay was a mistake
... we would prefer not having scrollbar customization

rbyers: what about the idea that if it's auto, and the padding is auto set

esprehn: you want the overlay and you want padding to come in

rbyers: should we have that?

zcorpan: would it make scrollbar not ugly

smfr: we did that already

esprehn: you have a scrollbar above it, the grid gets smaller when the scroll bar comes out and then goes back out when the scrollbar goes back. It's very hard to adjust

florian: this new feature, is that a value of overflow or something else

fantasai: I think overflow: style is good to handle this

rossen: what you're saying, is that every time you have overflow: auto you have extra padding

rbyers: if we don't break content

rossen: that would be worse

zcorpan: We should have overflow scroll, but there is nothing to hide scrollbars when there is nothing to scroll

esprehn: that doesn't solve everything as the scrollbar doesn't know the size of the scrollbar

<esprehn> toolbar

<esprehn> toolbar doesn't know the size of the scrollbar

<Bert> (I think I like zcorpan's idea. And can add 'overflow-y: scroll' to that toolbar area)

<tantek> ADJOURNED.

<SimonSapin> https://drafts.csswg.org/css-tables/ has a link to https://github.com/gregwhitworth/css-table-3/issues which is now 404

<SimonSapin> in "Issue Tracking"

<BradK> Anyone awake?

<tantek> good q

<astearns> the room's about half-full so far, iank's still making everyone coffee

<glazou> is Bert around yet?

<glazou> he's the host for webex

<astearns> glazou: not yet

<astearns> Bert has arrived. phone soon

<glazou> Alan, I saw you put CSS Text before Bert's report ?

<glazou> ughhhh

<BradK> Now I can hear

<astearns> e

<glazou> thanks a lot

<astearns> rossen: after two days of ftf collaboration in Houdini, we have a first slate of FPWD drafts ready to publish

<astearns> Rossen: no objections from the TF

<glazou> yes please Bert's report first

<fantasai> ScribeNick: fantasai

<Rossen> glazou, you're welcome

Bert_: I was in Melbourne the last week. Went to see 2 different groups of people
... First group is people from Monash University, especially Kim Marriott ????
... he's professor at Monash, works on constraint solving etc.
... Met some colleagues as well
... And met people from YesLogic, Michael Day and Peter Moulder who used to be at Monash
... Talked about many things
... What they're doing at MOnash
... They do document engineering
... But much more than that
... algorithms for constraint solving and optimizing
... Interesting equipment, 3D Printers, laser cutting, 3d environments
... Can make many things and animate them with computers
... Interesting parts for me were things for constraint solving and optimization
... Tryng to explore semi-automatic constraint solving
... Number of constraints, computer finds a good solution
... These problems are hard, can't do an exhaustive search
... In practice many can be solved fairly well this way
... One problem was a cancer treatment, placement active charges on needles

<Rossen> glazou, it's all about stacking ctx there

Bert_: Before that make 3D omdel of the area
... visualized in real time, you can see the computer finding a set of points where you should stick in needles
... It's interactive as well
... So if you see that some needles are not where you would put them, or you have some extra knolwedge dnot captured in constraints, can drag and drop needls around, and it will recompute solution based on this new constraint
... Variant of travelling salesman problem
... Computer finds optimal route
... But maybe you didn't think of before, e.g. driver get sick, road is blocked, certain driver can't go a certain place, etc.
... Solve those
... Also thought about applying to layout problems
... Brainstormed about what an editor would look like
... What are things you would want to influence?
... want certian constraints, number of articles to be put on a page
... But not happy with results, might might want to drag things around a bit
... Couldn't think of any editor that worked that way
... Maybe Daniel wants to build in constraint solvers into his editor? :)

glazou: Get me funding, and no problem!

Bert_: This assumes the editor interactively and in real time computes the layout
... What would the output be, though?

<gregwhitworth> worth looking at for this: http://marvl.infotech.monash.edu/webcola/

Bert_: Does the computer output the final set of constraints, and browser recomputes?
... Or should the editor not assume the computer has the same capabilities?
... This interactive maniuplation is a way to create constraints without using syntax

Florian: Don't know how much they looked into it, but if we're thinking about CSS and the attempt that we generally make for it to be robust in varying environments
... These manually added constraints, have they thought about how to express that when not in authoring environment?

Bert_: No, they've done some demos of .e.g. table algorithms
... Table layout could be very fast and always better than the current layout
... But haven't tried to think about syntax lately, just about algorithms

Florian: My question isn't about syntax, but these manually added constraints? What are they expressed in terms of? When the screen size changes, what happens?
... One reaosn it's hard to make a good CSS editor is that you start with a semantic layout
... How do you epress these constraints that's not just wyswyg

?

Florian: If you make wyswyg, it maps poorly to CSS

Bert_: They haven't done any work on that

<gregwhitworth> http://gridstylesheets.org/guides/ccss/

Bert_: But there is something from other people they worked at in teh past, Washington Uni in US, ?? adn ??? constraint cascading style sheets
... Using a syntax made by Apple for the internal UI

glazou: It is not difficult to write a good CSS editor that is strictly visual
... outputs layotu based on mouse-defined rendering
... What is extremely difficult is taking an existing document with existing stylesheets, and add stuff like that.
... That's why this is complex
... that's why you have so many editors outputting HTML+CSS, but not using it as their native format
... Other than that, fairly doable

Bert_: Michale Day of YesLogic has ben thinking of how to use things like that

<astearns> also why you have editors that do not take arbitrary HTML+CSS as input

<Florian> glazou: I'll have to have a longer discussion with you about this, you know more and I have a ton of questions

Bert_: In a reglar language, could say e.g. box a is zero or more copies of box C followed by box D
... something like that
... Usable by people to express how they want the layout to be
... we had a thought, also mentioned there, if Houdini works well
... It might be possible to keep the same underlying system, Houdini, but offer alternative ways to express your stylesheet
... Doen'thave to be CSS syntax
... Gets translated down to same base level as Houdini
... Might be a way to get away from courrent constraints of CSS
... Talked about some of the difcicult things in layout: footnotes, sidenotes, spreads of pages
... Differences between superficially similar things: footnotes vs. sidenotes vs. floating images
... Similar layout -- float to a side -- but different constraints
... Floats can only go later, can't go higher
... Sidenotes are a bit like normal floats. But don'thave to be same height or lower, could be higher on the page as well
... If you have a spread
... Sometimes don't need to put a float on the same page. Could put on previous page -- it's still visible anyway
... How to formalize such constraints
... Same thing for line breaking
... Maybe not use a single algorithm, but plug in different algorithms to do better or faster job
... Apply different rules for a praticular application
... Given Houdini beign prepared, maybe it becomes possible
... Someone mentioned during lunch that, just occured the day before, found himself reading the same line over and over again until he realized both lines were ending with the same word.
... Maybe you want an algorithm that avoids situation like that: same word ending two lines
... If it doesn't work quite with just changing spacing/line breaking, would be nice to have possibility to change the text
... If the author is available, you can ask author to rewrite text to fit better. But on the web, author is not available
... But maybe allow alternative text in the document

Florian: This also came out in a11y discussion
... Some people have difficulty metaphors, maybe you have alternative texts one literal one figurative
... Multiple reasons to be interested in this other than layout itself

Bert_: Michael Day was interested in development of his market, PDF renderers
... Looks like he would get more competition.
... He's happy about that, proves it's interesting and market is getting bigger
... Makes idea of outputting to paged media / PDF more popular
... But was wonderign what competitors are working on
... Antenna House, Vivliostyle
... We noticed another one, existed for awhile but wasn't as good in the past, German company
... Improved a lot
... Competitor to Prince now
... Looked also at indexes
... If your output isn't interactive, you need things like ToC and alphabetical index
... They want to do that, and at the moment they are exposign a JS interface so you can write a program that creates an index
... But the index is created before the layout is done
... So you can create the index, sort the index, placeholders for page numbers which get resolved after layout
... But then want to do fixup, like replacing duplicate numbers
... Or maybe need JS that runs after formatting
... Were asking if we in the WG were thinking of adopting things from XSL, since it can do that
... Antenna House can do that, Prince cannot
... So interesting to work on -- good indexes is a challenge

Florian: I thin kprioritis are different when you're doing interactive docs
... But even then, it's desired
... Should have in general

SteveZ: Part of secret is doing indexing after you've done the document
... In a batch process you can stick it back up front
... In an interactive world, there'd be no particular harm in being just another page that you accessed
... Does make sense in aninteractive context.
... Stuff in XSL is not that sophisticated that it would be a perf problem

Bert_: Interactive documents
... Forgot name of progream, but it allows you to see hypertext documents
... Gives previews of documents being linked
... Because screens are big enough now, can have a side panel
... Don't have to click the document to see what it is
... Maybe it's a nice feature for browsers
... Other things that could be done interactively that could make reading easier
... Exploring a document in various ways
... Particularly if you have talbes or math, can be veryinteractive
... Think of what you could do with data tables
... sort table,s make a graph out of it, like an excel spreadsheet
... Author says 'this shows a trend', you can make your own graph and come up with your own itnerpretation
... You can interact with math formua
... Could also do things with images: zoom in, enhance contrast, etc.
... That's about it

<Bert_> http://print-css.rocks/

Bert_: Print CSS site, it's a one person site, review of various programs for making print from HTML
... E.g. found links to PDF Reactor
... They can do things like hanging punctuation
... You can make really nice documents with PDF Reactor
... That's the end of my notes

glazou: First, Thank you Bert for the report, very interesting
... What can we take back to the CSSWG, and what is interesting for us to discuss, and how?
... And will the people you talked with help us to standardize?

<liam> [I sent a draft proposal for index fixup in January; I know TabAtkins commented on it. it needs work, but is largely based on XSL-FO]

Bert_: People from Monash, no, their job is teaching and writing papers. But you can talk to them and ask for algorithms
... They looked at e.g. are these algorithms practical enough to use in real time, and in their opinion, yes, they are
... YesLogic Mchael Day ahs more concrete requests.
... Would be best for him to join the WG, been asking for a long time
... But it's a very small company, they don't have a lot of money, not even an office
... They may have half of the market, but it's a small company
... We can talk to them. Peter Moulder is active on ML, Michael Day not so much, but happy to answer qustions
... He promised me he'd give me more complaints
... So I'll be asking for more complaints
... Concrete things they wanted, I mentione dindexes,
... Michael Day was interested in more constraint-like layouts
... A way to express two things side by side, third thing below

fantasai: You can do that with Grid

Bert_: I'll think a bit more

glazou: To enhance layout, giving constraints between elements
... I had a proposal for that
... I think Tab also had one
... We did some constraint-based layout long ago in Grif
... Maybe people at Amaya have some hints

Bert_: Nobody working on it anymore, but people who worked on it might know

dauwhe: I also have a good workng relationship with Michael Day, spend a lot of time on their support forums
... Do see a lot of pain points there, can try bringing those to this group
... Our system is based on Prince, so I have a lot of experience with them

skk: As far as I understand, the constraints is comeing from users

Bert_: Constraint is given by author or designer of document

skk: Not user

Bert_: That's an interesting idea. DIdn't think about allowing reader of document to give constraints

skk: If we can think about user also giving constraint ot document, I think it is interesting
... At that time we think about personalization of document
... There is one document, many readers
... E.g. I like hanging punctuation, but he does not, then user can see what they like
... Personalization can be done using these constraints method

Bert_: I like that, should think about that

<Florian> user stylesheets

skk: Can you let me know later, the ACM paper you mentioned in the talk?

<glazou> thank you very much Bert !!!

Rossen: In conetxt of all of this, would be great to ask if they can look at our Grid proposal
... That's a module where a lot of these constraints can be handled very elegantly on the style layer
... Worth having people with that kind of problem space looking to the spec at least
... Getting feedback

Bert_: Michael Day liked my grid better, but he'd looked into the new one

<franremy> fantasai: L2 otherwise ;-)

fantasai: On topic of Grid, planning ot transition to CR 2 weeks from now, so would be great ot get feedback within this time, otherwise hard to process

CSS Text

Bert_: Digipub wanted to talk about character alignment

dauwhe: Top of our wishilist is aligning on a character in a table column
... This is now in CSS Text 4
... At TPAC dbaron went and added a bunch of issues about nuts and bolts how this would work
... Firs tissue was 18: how woul dyou align the alignment characters themselves if in different font

<dbaron> I added some issues to https://drafts.csswg.org/css-text-4/#character-alignment pointing out things that need to be decided (some are technical, but some are actually questions about what the users want)

dauwhe: The most common use case is bold row for totals
... Did a bit of research looking into what existing tools do in this situation
... As far as I can tell, InDesign aligns the origins of the glyphs
... Some discussion on ML whether this is appropriate or whether the alignment chars should be centered

<dauwhe> https://lists.w3.org/Archives/Public/www-archive/2016Feb/0000.html

dauwhe: I just put together a diagram
... This overlays bold/roman text in the same font
... This is a very small effect

Florian: I dont' have as many examples as Dave has
... I've looked into it, talked to others

<Rossen> https://lists.w3.org/Archives/Public/www-style/2016Jan/0233.html

Florian: General agreement that main use case is bold vs regular
... Essentially they treat this as an edge case rather than a use case
... Author should have taken fonts the same size
... Not in that situation it's error handling
... So they don't have a strong request one wya or another
... tiny differences, maybe it doesn't really matter because barely visible
... If not tiny differneces, considered authoring error

SteveZ: I had a question about alignment whehn there is no alignment char in the object
... Numeric value without decimal, e.g.
... what happens if no character?

dauwhe: I think it inserts the character invisibly after the text
... e.g. 1000 without .0 at the end
... If you put other text in there, that would be a problem

SteveZ: In error-handling world, need to say what to do

franremy: I didn't think about this...
... Implementations looked into this
... ?

fantasai: i think we shoudl center it, it's not biased towards wond directionality or alignment
... Does anyone have a different opinion?

Florian: I don't think centering is the best option. I think it could be preferable to align to the left side of the character

<astearns> as long as the virtual character is added in the case where it's missing, I'm for center

Florian: Very often you are aligning numbers
... If you misaligning the right is owrse than misaligning the left

fantasai: I don't agree with you at all

Florian: Another way to deal is letterspacing

fantasai: No.,

Rossen: goign through 9.1 of text alignment

<liam> [ front-alignment (i.e. rtl-dependent) will give the strongest result in most cases ]

Rossen: As I understand current porposal, happens across table cells in same column
... It's a very simplified example
... What about borders, breaking, etc.

<liam> [ i.e. use the text direction of the table, not the actual text inside, but align everything to that, because the eye sees aligned things more strongly than centred things ]

Florian: This is for the simplest use case
... What would you do in such and such case? They say "you don't do it in that case"
... Nobody has any expectations for the complicated cases, because for people who need this nobody encounters those cases
... There is a very strong demand for this from many places
... Mabye less on purely web-oriented people, but as soon as you hit publishing

SteveZ: Financial publishing

<astearns> +1 to strong demand

<liam> [ this isn't an edge case if you have a total of a sum of figures and put the total in bold ]

Florian: Lots of people with tables with numers in them

gregwhitworth: While ther'es a very specific use case
... Still need to approach the generic standpoint, because people will put anything in a web page

Rossen: If you think about the way shrink-to-fit will be affected by this... just don't even want ot think about it
... Currently in table algorithm, no dependency of content of tables besdies knowing min/max

dbaron: To respond to what Rossen said, look at issues I added to the spec
... Covered by issues 22-23
... I think it's a solveable problem, but requires carrying around a bit more data
... But also some questions where the users need to say what they want before we can define the spec

SteveZ: Seems like this is analogous to baseline alignment, just in the other dimension

<dbaron> (Issue 22 being the one starting with "This should have a formal definition")

SteveZ: Baseline can be abitrarily aligned as well, yes.

fantasai: Yes, you have thsi same problem in the other axis with baseline alignment, or inteh column axis if the table cells' content is orthogonal

dbaron: We don't support that

Florian: My point is, a lot of these questions, we can't ask for examples because there is no such usage. We have to decide osmehting, but it can't be based on convention because there is no such cases conventionally

dauwhe: I've been searching for pathological examples of this
... So far very little luck
... I think this may be as publishers, we're operating in constrained space
... won't see the kind of craziness in web implementations
... Want to emphaisze this is really a problem worht solving. Really clear use case
... I think we should try

<Florian> +1 Yes, very clear demand

SteveZ: So off topic, of should we do this at all rather than where to align the character
... can we resolve on where to align the character, move on to other things?

fantasai: I'm advocating center alignment, does anyone object?

SteveZ: You'd have to compute the center, wouldn't require any kind of ocmputation

astearns: Liam is advocating fo rstart

Florian: Shoudl be left, not start, because even in RTL numbers are LTR
... Also, if you do have mixed directions across cells, the alignment needs to be consistent
... Imho center is acceptable, left is prefrable

astearns: Liam says we should use the writing mode of the table

Florian: No, because numbers are LTR

<Rossen> Rossen: The vertical centering is not a close behavior to how baseline alignment works. Table alg are based on clumn sizing as input and rows as results. Restarting row layout doesn't have global effect while column does.

<Florian> if the numbers are shifted, that shift is going to affect alignment on both sides, and the shift in the number is going to be much bigger

<Florian> fantasai: ^

<Florian> fantasai: the right edge has the stronger alignemnt axis in general, so why would you align to the left. Money has a fixed number of digits on the right

SteveZ: I disagree, what's to the right is less important than what's on the left.
... dollars more important than cents

<franremy> dauwhe fantasai: another idea? what if we do align on both sides and center? if one dot is bigger, all smaller dots gets some padding

<astearns> no, fremy :)

fantasai: But the left side is not aligned anyway in many cases, so why are you caring about alignment on that side?

Florian: The left edge is the easiest to implement, mgiht as well go with that

1. Center

2. Left

1

<liam> [ Florian, in the case of LTR numbers in RTL it makes no difference; in the case of another character it might ]

<zcorpan> abstain

<Florian> 2, 1

<SteveZ> left

<dauwhe> 2 1

<BradK> 2

<astearns> 1 2, don't really care which

<Rossen> abstain

<liam> 2 out of these

<gregwhitworth> abstain

<dbaron> abstain, but maybe slight preference for left

<koji> abstain

<skk> abstain

<Bert_> slightly prefer 2 over 1

<jihye> like 2 more than 1

<eae> abstain

<birtles> abstain

<dbaron> (I'm also fine with table-start)

<dbaron> let's look for examples with varying letter-spacing between the rows :-P

<Florian> fantasai: visually the strongest alignment is going to be on the right edge, if you have dolars and cent, hours and minutes, etc. So if that's what you care about, you want the right edge, not the left edge.

<Florian> fantasai: I think you're all wrong, but if you insist I'll put it in the spec

<gregwhitworth> fantasai: yeah I don't care, So I think you're wrong but I can live with it

<liam> :)

RESOLUTION: left-align the alignment characters

dauwhe: dpub will do what they can with the other issues, but some are beyond our capabilities, as they're impl issues
... Happy to answer questions about what's happening out in the world

<dauwhe> https://lists.w3.org/Archives/Public/www-style/2016Feb/0002.html

<BradK> I'm fine

<BradK> Same

<astearns> as far as I know, the round display topic is the last one anyone has specifically asked to call in for. Please let me know if there are any afternoon topics you'd like to be on the call for. We can try to move them earlier if that's the case

<franremy> astearns: if that can fit, "Behavior of contains:paint and overflow:clip, text-overflow and resize properties (Ojan)"

<franremy> if not, I'll read the minutes

<franremy> astearns: ack

Round Display

hyojin: I think if Web support various technology with display shape, a variety of products will adapt web-based platform OS in near future
... LG webOS is one of the platforms, and CSS Round Display is starting point in W3C
... Some polar issues

jihye: First issue is about percentage of polar distance when origin is not the center of the containing block

<astearns> https://lists.w3.org/Archives/Public/www-style/2016Jan/0152.html

jihye: This issue was action item at Sapporo meeting
... We need to define clearly about percentage of polar distance when origin is not center
... When origin is not the center, the distance between the origin of polar coordinates and edge of the containing block varies according to the value of polar angle
... With this method we have to assume that hte shape of the containing block is inscribed circle fo rapplying the method to round display
... We also have to use polar positioning for retangular containing block
... But aligning elements here seems to be strange
... Because if there are elements with elements with same percentage but different polar angle, they create an alignment in rectangular shape
... This is not an appropriate polar positioning
... We discussed about this problem and we got a reference of radial-gradient()
... So I suggest to specify percentage with extra keywords, e.g. closest/farthest-side/corner

<jihye> polar-distance : [closet-side | farthest-side | closest-corner | farthest-corner]? <percentage>

Florian: Looking at various use cases to see which is the correct definition of percent
... Different use cases give different answers
... Sometimes you want to follow the shape around you
... Sometimes you actually want a circle
... So having a choice among these four
... allows different circles
... And if you omit these keywords, then you do follow the shape
... So on each angle, 100% gets you to the edge
... If you are in a rectangle, you move in a rectangle, get ot the edge
... Sometimes this is what you want
... Sometmes this is what you want, but sometimes want to move in a circle
... So having theses keywrds, plus option to omit keyword,
... We get 5 behavior sinstead of 1
... Because I think one doesn't solve the use case
... And we reuse familiar syntax

BradK: I can see how closest-side would be use. When would you use closest-corner or furthest-side? Seems like you'd get a lot of clipping

Florian: Would use if you are in a corner, use closest-side

<dbaron> fantasai: seems problematic, because you want the shorter (?) side

Florian: If you're in a corner and use closest-side, result is the corner (0), then want farthest side

BradK: I think closest-side seems useful, unsure about the rest

Florian: Seems to be most useful, yes, but if borrowing radial-gradient(), just take the whole thing

polar-distance: <side>? <percentage>

jihye: I think this covers all cases developer would want
... Can we define polar distance by this method?

<gregwhitworth> fantasai: a good direction to go in, I'm a little concerned

<gregwhitworth> fantasai: if you have a point in the top left corner of a rect, and you want 100% to be on the short side, I don't see how you would do this

<gregwhitworth> because closes side would give you 0, but how would you get the furthest side

Florian: It would take us away from radial-gardients, but maybe it should be closest non-zero side

Rossen: Def moving in right direciton, might be some additoins to it
... But mostly okay with this
... Any objections?

RESOLUTION: Add gradial-gradent <side> keywords to polar-distance. Mark issue top left corner, asking 100% of shortest side, how to get that.

Florian: We currently have a 'contain' keyword adding to percentages for avoiding overflow
... Without it, cause overflow
... The 'contain' keyword modifies this to make 100% the point where you woudl just not overflow
... I have nothing to say behavior difference
... I have a worry about which is the two is the default
... I'd rather have no keyword doing the 'contain' behavior
... and add 'unsafe' to do overflow

BradK: I think we should revisit 'contain'
... I don't thin it's very effective at placing things where you want them
... I fyou have a clock face, the 6 will be really close to bottom
... but something like 10, that corner in order to contain will throw cetner of 10 closer to center of the dial than anything else
... I think you really want the center of the numbers to all align along a circle, but you don't get that

Florian: Round the corners

<gregwhitworth> fantasai: no BradK's right

BradK: That doesn't sound like a good general solution. Doens't make it useful
... Don't always want squares. E.g. have a 3 that's much arrower than 12
... Would be better to have 100% means put center along the curve, then move in by half the height or something like that

<confusion>

BradK: The way spec right now, 100% without contain puts the center of the element along the path of the circular container, right?
... If you're dealing with numbers on a clock face, all the same, they're all the same height, so you can take half that height an dmove it back by that amount
... And then it would be contained
... That would be better than have corners poking in more than sides do

Florian: Height doesn't work in [???]

BradK: If it was always half the height, and all the same height, then they would all move in by that amount

Florian: But that wouldn't be sufficient to avoid overflow
... If wider than tall, half the height isn't enought o move inward

SteveZ [mumbles something]

BradK: Don't have a perfect solution, but I think we need ot think some more. Because the one we have righ tnow isn't a great solution

SteveZ: Instead of half the height, could do half the largest dimension
... Has to be the same for all of tem

Florian: we don't have that, though

BradK: You'd have to have a fixed width, might have overflow becaue numbers wider than you anticipated....

Florian: I think there is more work needed on definition of contain
... Also need to take into account whethe ror not we care about rounded corners
... or shape-outside
... or shape-inside
... But assuming we have a 'contain' behavior, would rather it be the default
... Regardless of how we define it
... Maybe reserve judgement of that until we have a precise definition?

BradK: I don't feel strongly one way or another
... Sometimes want one or the other

Florian: My concern is not that, but what happens if the user has a differently sized screen and author didn't think abou tit
... If author didn't ask for overflow, let's not overflow

BradK: I think Ill reserve judgement until we had a better definition of 'contain'

Florian: Okay, let's work on contain mjore until deciding whether it's the default

jihye: Next issue is polar-positioning and abspos

<astearns> https://lists.w3.org/Archives/Public/www-style/2016Jan/0134.html

<Rossen> https://lists.w3.org/Archives/Public/www-style/2016Jan/0134.html

jihye: There was an idea of making polar-distance and polar-angle with abspos
... So polar-position properties used with abspos
... Use of polar positioning is changed

<hyojin> also refer to this written by BradK yesterday: https://lists.w3.org/Archives/Public/www-style/2016Feb/0002.html

jihye: If polar-distance isn't auto, then can be polar positioned
... ...

Florian: polar positioning is activated if polar-distance are not auto and tlbr are auto

BradK: I've evolved my position on that base don the alignment spec
... With alignment spec, you are using the TLBR to create a box that something can be centered in
... So needing something to be non-auto doesn't really come in any more
... Last email I wrote, detailed how it would work
... If you start at top and work your way down, top part is least controversial
... I think we agree that using position: absolute or position: fixed or position: relative would be good
... Instead of having a separate polar positioning spec that's the same as absolute except that it pays attention to polar
... The only really other thing different about polar positioning is that it centers things.
... If box alignment centers things, then we free up polar positioning to move tihngs at an angle
... You can decide to center something, move something at an angle, or not

Florian: so ?

BradK: Covers all the use cases

jihye: I think when we use polar positining on some elements

<hyojin> s/.../if any property among left/top/right/bottom isn't auto value, any of polar-* property is ignored

jihye: W have to set origin point to define distance and angle

Florian: Question is do you do that automatically, or use alignment first and then?
... SShould ? be magic or manually?

BradK: Manually with existing properties. Otherwise you have 2 properties that by themselves that center
... If you use position polar, same as using center alignment
... If we have a way of centering, we have a way to make off-center with TLBR
... don't need a separate thing to make it center
... to move it at an angle, you don't really need ot have a concept of a center point or polar coordinates
... You move the whole thing at that angle / distance

Florian: I'm a bit conflicted
... On the one hand, I completely see how this works
... On the other hand, the properties we have for doing the centering
... are in a fairly different mental model than when we're doing in polar coordinates
... I'm not sure it makes sense to author to mix these tow
... alignment isn't something yo uthin about when doing polar positioning
... Not sure what I think

BradK: I think forcing person into different model is polar coordinates, very different from CSS coords in general
... The effects rae centering, and moving at an angle
... Don't have to change the 0 0 no longer top left left, now in the center
... don't have to think about tha
... question is do I want centered or not?
... Indpenednet thought of moving it at an angle
... Cutting ocrner across a right angle
... Could do same thing with TLBR properties
... Don't have to change my mental model
... Don't need to use left and top to move at a 45deg angle anymore, just use polar-angle and polar-distance.

Florian: My assumption here is that even among the people who write CSS, more people have an intuitive understadning of polar coords that they learned in middle school than how CSS layout works
... Not that ppl have advanced understanding of math, but that much they do

plinss: I think you're overestimating people
... I think more people understand CSS than understand polar coordinates

Florian: ...

BradK: We went over this with radial gradients
... 0deg is at top
... not changing the coordinate system,
... origin is still top left corner [?]

<gregwhitworth> fantasai: If I understand correctly, let's drop polar-origin and position things with alignment and that's your origin for moving

<gregwhitworth> fantasai: I think there are use cases for that, and what happens if you want your origin to be something other than the center or the edge, that's really hard without the coords

<gregwhitworth> fantasai: I think BradK has a great point though, and I think it's worth separating these things out

<gregwhitworth> fantasai: I can see also how you would want to have a polar positioning

<gregwhitworth> fantasai: if you make the initial value the polar origin could be auto which would mean do your layout like normal. If you have polar origin set to a specific coordinate then that becomes where you start from, and you can share the polar origin among all of the different layout models

<Florian> I'm ok with that

<gregwhitworth> fantasai: for relpos you would probably ignore the polar origin prop, but for fixed and abspos you would look at polar origin

<gregwhitworth> BradK: you would have two different ways for layout then

<gregwhitworth> fantasai: I think there will always be many ways to center something though

<gregwhitworth> fantasai: centering in the future will be possible in many diff ways which is ok

<gregwhitworth> plinss: I like the proposal but I don't think it should just be polar origin

<franremy> BradK Florian fantasai: Are there written examples of both proposals, to see which one is more compact? I fear the normal-css way might be too long to write, but I am not sure.

BradK: After leaving alignment, I don't see the need for polar-origin, because you can just adjust the size of the box you're centering in

plinss: I like the idea fantasai is talking about

<gregwhitworth> fantasai: I don't understand, there is no origin in any other one

plinss: But don't think it should be restricted to polar
... Why not change th origin in any other mode?

[above line goes here]

<gregwhitworth> fantasai: that's defined by the writing mode and the rect

<gregwhitworth> fantasai: there's no numbers, so the align props don't have lengths, cords etc - they're just keywords and you're working off of the rect

<gregwhitworth> fantasai: it's not really an origin system

BradK: I fyou want center to be move dot the left, use the right property

plinss: Just because we don't have ability to set something
...

<gregwhitworth> fantasai: can you give a better example

plinss: I want to have a box where 1/3 of it is going to align on this point
... Can't do that today

Florian: so you're asking for polar-origin + polar-anchor
... So you say polar-anchor: 33%; polar-origin: <coordinate> ?

plinss: I don't think we shoudl restrict to polar positioning

Florian: I don't think i can agree or disagree so long as you're being this vague

BradK: That's what I was describing before in earlier emails
... I did have the idea of polar origin, which I was calling 'center', that could position things base don their center
... You could' move this cente rwith property, 'centerpoint' or something
... Could position item based on any point in the item and any point in the contianing block
... Would get same ffect of putitng 1/3 of element ot align with top center of CB, or whatever

Florian: General ide aof what Brad and Peter are describing does sound reasonable to me
... But not convinced until more ocncrete
... Didn't like the concrete proposal of Brad earlier
... Maybe a different proposal would be better

SteveZ: It's very similar to character alignment for images in inline
... In this case alignment ot a baseline, but conceptually the same kind of idea

Florian: I think yo'ure generalizing too much here :) But see where you're coming from

SteveZ: It's taking what an alignment poin would mean in inline alyout vs block layout
... Still the same 1/3 in 2/3 down kind of point

Florian: I stand by my previous remark :)

Rossen: What is the current favorite proposal?

Florian: I think we have general agreement for making polar positioning work in absolute/relative/fixed
... Don't have agreement on how to get to center
... My favorite concrete proposal so far is fantasai's
... But interested to see what Brad and plinss have to propose

jihye: I agree with generalizing polar origin

<gregwhitworth> fantasai: I think, if we go with the proposal that I had, there is no new prop. It could be renamed

BradK: Could be renamed. It's not necessarily polar
... position-origin might be better
... I was suggesting that this could even be a transform
... function
... It doesn't even really need postion, coudl just ransform something with angle movement
... Could stop having to change your mindset
... Differen than startpoint

<gregwhitworth> fantasai: you may want them to cascade seperately

<gregwhitworth> fantasai: if they have hover effects mixed in with layout, that makes it awkward for the author, transforms should just be a graphical thing on top

Florian: My proposal would be, 1. Resolve on what fantasai proposed earlier, with the understnading that we will explore generalizing it further
... I think bradk and peter have some interesting ideas,
... But what fantasai propose dis a clear improvement over what we have so far
... So I'd rather have that in the spec
... and then improve from that

BradK: Do we have to call it polar-* ?

Florian: I haven't seen an obviously better name proposal, so I think we should discuss that from a better starting point, from what fantasai proposed
... This way reduce the problem space
... And then make concrete steps from a concrete proposal

BradK: Sortof agreement on the list to have this be part of positioning anyway

Florian: Let's turn this into a concerete set of resolutions
... I think what fantasai proposes is a clear step up from what we have so far, so let's take that step and then move forward from that

<gregwhitworth> Fatasai: add the auto vals to polar origin

<gregwhitworth> s/fatasai/fantasai

<gregwhitworth> fantasai: apply the polar coord to all positioning schemes, not static, and remove 'polar' value

<gregwhitworth> fantasai: auto on polar origin, would the be the initial value and would have them do normal layout

<gregwhitworth> fantasai: polar distance initial value becomes 0, remove auto value

Florian: The definition of how does "polar origin work" in that model, if you are in anything but position absolute/fixed, it does nothing
... If you are in position absolute/fixed, when polar-origin is nonauto, you do that instead of the traditional way of finding your position
... I'm in favor of this proposal

BradK: what happens when you have align-self: center

Florian: If you're in abspos, self-align: center; justify-self: center; and polar-origin: auto
... Then you center through the alignment props
... If polar-origin is non-auto, yo uignore align/justify self and instead do what polar-origin says to do
... That's the model. And again, we can lookinto futher generatlizatio, but the model currently described is this

jihye: When polar origin is not auto, what happens to the TBLR properties?

<gregwhitworth> fantasai: we could ignore them, or we could use them to reduce the size of the box in which you're positioning in

BradK: Or could just pay attention to top and left

<gregwhitworth> fantasai: no, no

fantasai: I don't like using only half of this set of 4 properties

Florian: So I propose we resolve on the proposal, and then mark an issue of what happens with top/bottom/left/right

Proposed Resolution:

1. Remove 'polar' value of 'position'. Polar positioning applies to absolute/fixed/static/sticky/relative positioned elements

2. Remove 'auto' value of 'polar-distance'. Initial value is 0

3. Add 'auto' value to 'polar-origin'. This means find the origin using normal rule sfor absolute/fixed/statick/stick/relative positioning.

4. Make 'auto' initial value of 'polar-origin'

5. Add an open issue as to whether top/right/bottom/left properties are ignored or interpreted somehow when 'polar-origin' is not 'auto'.

Rossen: So current proposal is resolve on the proposed rsolution above, points 1-5
... Any objections?

Bert: I'd liek to propose a modification

<BradK> I can't hear anything

<gregwhitworth> fantasai: no, the auto value is on the origin because it allows all of the other layout modes to work

<BradK> Complete silence

<astearns> (what was missed was Bert proposing what he put in his q+ above)

<gregwhitworth> fantasai: *gives an example*

<dbaron> fantasai is using the mic

<BradK> No

<franremy> the room is not in the call

<gregwhitworth> fantasai: the distance and angle being auto doesn't make sense

<franremy> anymore

<gregwhitworth> fantasai: once the origin is set by the default layout modes, then you can use distance and angle to position it

<gregwhitworth> fantasai: in that case you can set it to center, or use the alignment props

<gregwhitworth> fantasai: but you have to ask for it to be the center, but polar pos will always work generically

<BradK> Distance and angle can both be 0

<gregwhitworth> fantasai: so the initial behavior has to be backwards compatible

<gregwhitworth> fantasai: it's through a switch that makes the polar coordinate capabilities become possible

Bert: I think I have a misunderstanding of what fantasai is proposing, I'll figur eit out later

Rossen: Back to objections on proposed resolution?

BradK: No objection

RESOLUTION: Proposed resolution above.

NOTE: polar-origin doesn't apply to relpos. (Or mark an issue for making it apply somewhow)

<astearns> (Joone getting set up)

polar properties as CSS transofrms function

joone: I wanted to extend this idea to 3D transforms
... Here is proposal

transform: polar(angle, distance)

<astearns> (Joone showing a presentation)

transofmr: polar-origin(percentage|length, oercentage|length)

transform: polar-anchor(percentage|legnth, percentage|legnth)

joone: No changes, just use exisitng properties as transform functions
... If you use transofrm function
... WE can move the element in the contianign block like this
... If you use polarorigin
... you can nmove the green block like this
... If you use polar-anchor can do this
... If you use polar anchor, use polar origin to gether
... Could extend this idea to 3D transofrms
... use polar3d function

<BradK> Is anyone tweeting the visuals?

joone: 3 parmas are polar3d(r, theta, phi)
... Place elemtn in 3d space like this
... can also use polar-origin3d and polar-anchor3d

functions

joone: polar-origin3d(r,theta,phi)

polar-anchor3d(50%, 50%, alpha, beta)

(joone's diagram has alpha and theta be the angles of the element with respect to the ray from the origin

)

joone: This is the inital idea. Might be some issues with this idea
... 3D function and transform

<dbaron> Is the idea that these are equivalent to translate/translate3d transforms?

joone: That's it!

Florian: I woudl split my feedback on 2 aspects
... one being transofrm and one being 3d
... Earlier today fantasai explains why doing positioning with transforms cascades badly, wnat ot do transforms on top
... So because of that I don't think we should be doing this with transforms
... Wehther or not we cna do in 3D can discuss separately
... For 3D side of things, I don't htink there is any particular difficultiy in understanding how the math works
... But I want ot see use cases before diving into it
... This is solveable, but wouldn't work on it without use cases
... 2D without transforms is what we resolved on previously
... 3D maybe, but why?
... Would like more convincing use cases
... without that I think it's complication without justification

dbaron: I guess I didn't even understand what the proposal was
... Are these translations? Are they translate + rotate?

joone: Internally we use translate and rotate functions
... I want web deveoper to be able to just use polar poperties

dbaron: I look at transform polar3d(r, theta, phi). What is that transformation?
... Is it a translation? Is there some roation, too?

joone: No rotation, just move

dino: If it's a translation, why isn't it a translation?

dbaron: I can understand wanting to express translate as polar coordiantes, but if so, would want translate in the name

dino: Can you go back to the other slide
... example in 2d
... The thing I don't understand, maybe it's because I haven't been listening well nough, but
... We start there, then next slide...
... We've changed the positioning completely of the element
... There's this implied traslate to the middle of its ocntaining block
... which is really confusing, because nothing else does that in a transform
... polar angle and polar distance, inital value is located in the middle of contaiing block
... Sure, but no other tarnsofrm needs to know what its containing block is

hober: What are the arguments to the function here that would be the identity transform?

dino: What would you do if you wnated to keep something where it was

?

dino: I think I can see there's a use case for adding polar transform functions that simplifying the case of moving something a position rotating it, translating back out, etc.
... But don't like that this function completely changes transforms completely
... If you do translate(0,0) nothing changes. I fyou do rotate(0) nothing changes
... but here polar(0,0) completely chagnes where the element is

Florian: This is a conversion into transofrms from what the polar positioning model was before we made the resolution 15 minutes ago
... polar posisitioning in the old model had a jump-to-center effect
... but we just change that

dino: Transforms isn't the way to magically change the positioning of an element

<dbaron> I agree with dino.

Florian: Without using trnasforms
... swhat we just discussed dealt with that
... and as fantasai explained, not good to use transofrms for positioning
... For 3D polar positioning, we need use cases

<gregwhitworth> fantasai: so here's the big issues

<dbaron> fantasai: 2 major confusions here:

<gregwhitworth> fantasai: one of them of which - you don't seem to know how the cascade works as you're overriding the transforms

<gregwhitworth> fantasai: the second one is that, transforms are NOT a positioning system, it's about shifting relative positioning system

<gregwhitworth> fantasai: that goes back to what Ted was saying, you need an identity transform - if you 0 out everything it needs to do nothing

<gregwhitworth> fantasai: when you add 1 to that it starts to do something - but we need that identity transform

<gregwhitworth> fantasai: we can add polar transforms which is basically syntactic sugar to other transforms

Florian: If we wnat ot workw ith transforms, then it needs to work the way she just said
... If we want 3D positioning, then I want ot see use cases first.
... And these two things are separate

dino: Florian made 3 points
... and fantasai described them better
... The points were
... 1. Transforms aren't a positioning system.
... It would be interesting to examine functions for doing polar-like transforms that are shorthands for polar positioning
... 3. and he wants use cases for what you wnat 3D polar coordinates for

Florian: If we want to do transforms, as fantasai described, then we don't need major use cases because it's syntactic convenience
... If we need a 3D positioning system, then we need to udnerstand why are we working on this hard topic

Rossen: Next is pseudo-class issue

<astearns> (Jihye setting up)

jihye: The latest smartphone from LG and Samsugn usese scrolling animation like this one

jihye shows off an email usbject line list, where the middle item of the 3 visible is larger and sifted left

jihye: There are sveral problems here
... One is that if the list item sizes are teh same as the contianing block there is some overflow
... If the list item size is same si inner circle of containing block, there can be unused spaces
... So recent smartphones use scrolling like this
... Dynamic scrolling and scaling of list items
... To implement this kind of scrolling animations
... This is implemented by JS
... It takes a lot of calculation, like exact posiion of elements while scrolling
... and doing some scrolling animations
... So to solve this problem we suggest ne pseudo-class
... We suggest regional pseudo class to handle this problem
... Can select an element in a specific area
... When the new type of pseudo-class is :region([center|left|top|right|bottomn]?)
... When element in the list matches with centerpoint of containig block, you can select :region(center)
... When element matches with top edge of containing block then select the element
... when you specify an element with region(center) that kind of element scaling bigger than the other elements then maybe you can deal with the dynamic scrollling I showed you before
... But I think this not quite perfect solution for dynamic scaling
... Because layout doesn't change when scrolling animations
... This is just one idea for dynamic scaling/aligning of items
... What do you think about this idea? Do you have some other solutionfor scrolling in round display?

astearns: Is Rick anyway near?
... The Houdinin scrolling stuff might help here

<dbaron> layout-dependent selectors seem unlikely to work

Florian: I am extremely skeptical that a selector depending on layout and scrolling cna work
... Since you can do it in JS, doing it in Houdini-powered JS would make it faster
... It would be nice to have a declarative way to say that, but I have no idea
... Maybe Bert has an idea, he's good at that.

Rossen: First comment, is that "region" in CSS and reusing name is confusing...
... But as some experimental work with shape inside
... also kindof suggests that, reinforcing Florian's point here, automatically scrolling mechanisms is quite difficult other than approximate rectangles
... When the shapes become more exotic this problem becomes not even solveable
... especially if you have disjoint shapes
... Not to say we should stop thiking about this.
... It is an issue
... If the script based solution works, that's already really good
... In Houdini we will try to make that more efficient...

Florian: Houdini is important here, works on desktop, not so much on watch

astearns: I suggest taking this specific issue to the github issues on Houdini as a use case
... And say that let's try to make our scrolling stuff hlp make this more efficient

Bert: Wrt currrent/past/future pseudo elements
... Can see what was coming and what's past
... That's the first idea I had with this
... scrolling also has this. So maybe with pseudo-classes can do something
... Just to remind people that we have something in Selectors 4 that might fit this

<astearns> perhaps it shouldn't be layout changes based on position within the round display, but transforms (scale as you get to the middle...)

<tantek> which new WD?

round display I think

Florian: So, next one is robustness of CSS on non-rectangular displays
... If you ignore bugs and stuff, if you take an unstyled document, or to which only the UA stylehseet has been applied
... We've never had a situation where doing this would result in invisible oveflowing clipped content
... With shaped dispays, we do, because corners get clipped
... Starting with invisible content from which the author has to work from is bad
... The author cannot be expected to anticipate all the devices in the world
... and make their page work in all of them
... I think we should find a way to have the default situation for a web page to not clip and hide content on round displays
... Should we apply shape-inside by default?

<hyojin> I modified that the revision of CSS Round Display as last item.

Florian: But that's tough because we don't even know how shape-inside works precisely enough
... What I think he's suggesting is that by default the device manufacturer or provider of UA for that device
... Would make a viewport that doesnot cover the entire screen, but is either entirely contained or something that overflows it so little that you don't use much

Rossen: So we already have the concept in most implementations of physical viewport and layout viewport
... What I'm hearing is that we should allow sizing of the layout viewport from the host level

Florian: Bogdan?

Rossen: Currently layout and device viewport is completely internal
... not targetable by content script style anything
... This would be the first requirement that allows programmatic access to the layout viewport

Florian: Recommendation would be, ask the UA to start with a layout viewport that is smaller than the screen
... and sized smartly to not overflow at all or too much
... and to give either through <meta> or @viewport, allow author to opt into the full screen
... If you're askign for it, fair to let you deal with the situation

Rossen: If a manufacturer of such a device is using a web view or any other way to host web platform
... How is what you're saying different from resizing overall host container

Florian: The difference is matter of intial setting, and allowing author to opt into the full viewport

<BradK> We're talking about a square peg in a round hole now, right?

Florian: I'm not strongly defending this solution, just preenting it
... People should design for devices everywere generally, and then tailor to speciic devices
... Impossible to do this for round displays if we just use the entire circle as the display for the page

fantasai: The key thing is being able to opt into the full display

Rossen: At the app level it's fine.

Florian: I'm not concerned about app leve, for content targetted to the watch. I'm thining about ocntent not targetted at anything in particular. that needs to work

Rossen: So you have a round display, and by default you don't want to clip
... As Brad says, putting a square peg in a round hole
... At some point you want the user..

Florian: Opt-in is for the author, not user.
... If you display any web page not authored for a watch, should display just fine on the watch

Rossen: Agree with the general statement
... Don't understand the solution

Florian: If hte author does nothing, the UA should provide a layout viewport smaller than the screen.
... There is no clipping
... If the author is ready to tdeal with shaped screen
... Can ask for viewport that covers the entire screen
... and be prepared to deal with the clipping

Rossen: As long as its the on/off switch, it's palatable at least to me
... I'd be more reserved if we go the next stop, which and thorugh this media feature do a whole bunch of things to viewport sizing

Florian: Don't want to do shaping of viewport with this
... just opt in/out of the viewport fitting ithin circle
... Would like to tag this into the Device Adaptation spec

plinss: Why aren't we doing shape-inside by default?

Florian: Wll, we don't exactly know what that does.
... Also if you have less content than the screen, fine. What if you have more content than the screen?

<gregwhitworth> fantasai: we don't have a solution for that

Florian: In 15 years maybe, you can do that , but need a solution for now

Bert: About the smaller viewpor,t coudl be maybe a little bit bigger have margins

Florian: I don't think we have to be overly strict, can let device manufacturere be smart about that

<Zakim> Bert, you wanted to suggest Florian's smaller viewport could be the largest rectangle inside the round display, *plus* the (collapsed?) margins of the root element, given that

Rossen: Not necessarily a new problem, at least in Widnows Table mode, number of reasons why you'd wnat ot constrain the viewport of the browsers for different UIs and impinging elements that are either par tof the browser chrome or extension of it
... This is just hte same problem
... Impinging items are part of actual display
... @viewport owkrs just fine
... Anything else on this?

Florian: If we agree that's the wya forwrad, someone needs to take an action to figure out concrete syntax for this and put in either round display or device adaptation spec

Rossen: Start with round display and move to device adaptation?

Florian: Wrt time constraints on my side, would rather we actioned LG to write it, and I'm happy to review

<scribe> ACTION: hyojin add @viewport switch for opting into full round display size as viewport [recorded in http://www.w3.org/2016/01/31-css-minutes.html#action08]

<trackbot> Created ACTION-751 - Add @viewport switch for opting into full round display size as viewport [on Hyojin Song - due 2016-02-09].

discussing new WD publication now

RESOLUTION: Publish new WD of Round Display, with polar-positioning resolution incorporated (@viewport for next publication okay)

Florian: If you remember in Sapporo we revisited the media query and sort of concluded on a proposed MQ that no longer measures roundness of corners
... but instead queries whether a certain box sized and position in a certain way would be in the visible area of the screen or not

device-radius

Florian: I don't think the spec has evolved since then
... I thin the spec still has what we had before that
... I think we need to revisit that entire discussion, because there are two things that you want to query
... If you're wondering if osmehting will be visible or not, that's a good answer

<hyojin> the summary about it written by David baron: https://lists.w3.org/Archives/Public/www-style/2015Oct/0220.html

Florian: But there's a qualitative question as well
... Ther'e also, am I on a round screen? In that case maybe I wount round buttons and a round layout etc.
... But if I'm on a square display, maybe want more rectangular look and feel
... So the quesiton is, do we need to revisit conclusion in Sapporo?
... Or do we need two media queries, one for whether area is visible, and whether the shape is roundish or squarish

Rossen: Wrt resolution from Sapporo, what happened?

hyojin: corner-radius query to check that, also is-visible mq is strong, but seems very complex
... LG prefers simpler olution
... In consideration of extensibility, we should make this media query

extensible

hyojin: I would prefer to keep current media query
... and rename to corner-radius
... Address others in next level

Florian: I'm sympathetic, but skeptical
... It doesn't really answer questions for ...
... We have a syntax but don't have a clear idea what it means
... We discussed and came up with is-visible
... But that doesn't answer whether it's round or not
... I'm okay to have "am I round" query in L1 and is-visible in L2

Rossen: You can check is-visible with IntersectionObservers
... If you have an element and know if it's within the bounds of a scroller
... Similar to a mutation obsrever
... If the thing you're observing intersects a scrolling viewport, we can ...

dbaron: I'm a little worried about the intersction Observer analogy
... I don't think it deals with partially-visible in the way you want
... For the use cases of intersection observer, partially visible is often okay and you want to be notified that yu're visible
... But these use cases you care if you're completely visible
... But need to check before concluding that intersection observer is the right thing

Florian: That leaves us the question of how do we make query of "am I round"
... I don't think corner-radius is the right MQ

fantasai: But what does round mean?

<gregwhitworth> fantasai: for answering the qualitative question of screen round/square is a device mq possibly

<gregwhitworth> fantasai: it doesn't answer the question of if my corners are visible

<gregwhitworth> fantasai: you can have a watch that has a rounded corners but it's still a square, so you want to know that it's round but it's not a circle

<gregwhitworth> fantasai: having just "am I round" is not enough

<gregwhitworth> Rossen: what about the negation of that?

<gregwhitworth> Rossen: Am I rectangular?

<gregwhitworth> fantasai: we did discuss a JS api that gives you a path that allows you to do what you need

fantasai: can build whatever logic you need on top of that

zcorpan: Last time we discussed, a screen shape that's almost rectangular with corenrs a bit cut off, shoudl probably be considered rectangular

<BradK> Why not just allow overscrolling the round viewport to see things that would get clipped by default?

fantasai: What if that cuts off the "close" button? Need to know that the corner is clipped

BradK, I think that's an excellent solution to the previous issue; and I think tha't sin fact what some of the watches do

Florian: Maybe a non-boolean query
... But if we had a 'device-shape' MQ that has 'curved' and 'square'
... Let the device manufacturer opt in to roundish or squarish designs

Rossen: Remind me the use case?

Florian: If you look at the UIs for such watches
... They look round
... Not just to avoid corners
... But everythin'gs round, let's be round, round buttons etc.

<tantek> I'd like to see photos/screenshots to such "UIs for such watches"

Florian: But we can't make an MQ that only answers yes when perfect circle

<tantek> like if you have these readily available and have seen them, please upload/email to www-style

<tantek> so we can refer to them

<jihye> http://anawhj.github.io/jRound/demo/weather/index.html

joone: I implemented device radius on Android

<tantek> even better, perhaps we need a "watch-ui-examples" page on the wiki

joone: Only one API that returns this information
... I thikn we need first talk to the platform team
... in MS or Apple or Google
... Making the API to return the device shape
... Before can make the media query API

Florian: The Android API returns "am I a circle or not"

Rossen: Which works perfectly for... circles.

hyojin: we're also positive to specify just rectangle and round as the values, but I don't know how to define the media feature syntax in Media Queries.

?

Florian: Something like @media (shape: rectanglish|circlish)
... I'm not very excited about this, but don' thave a better idea

<BradK> Trianglish

Rossen: I think we have two proposals
... one is a binary switch
... tells you whether or not rectangular
... Other one is actually get a shape

<BradK> I never learned to speak Circlish.

<gregwhitworth> fantasai: I think there's three things that would be useful

<heycam> An alternative might be for the author to declare the unsafe area around the page, and then the device can know whether any important content would be clipped out. This could be useful for the "square display with rounded corners" case.

<gregwhitworth> 1. Have a js api that provides the screen shape

<gregwhitworth> that will allow you to build any logic for an mq you want

<gregwhitworth> The two things that can work together are corner radius and corner shape, the radius would tell you the smallest number the cutoff and the shape would say the shape, square, round or weird

<joone> Here is the code for getting display shape information from Android Wear: https://github.com/joone/crosswalk/commit/4613bf9e2d266fe60a26631e475aaa7392e4c4c5

<gregwhitworth> those were from fantasai

Rossen: Seem to have nothing approaching consensus

SteveZ: We need a solution for people to do something different for the round case

<tantek> I'm going to point out that old TVs had round corners

Florian: Authors are interesting is am I round

<tantek> and this wasn't a problem (e.g. WebTV)

Florian: OS can answer am I a circle
... So this is implementable and useful
... We need to make the definition fuzzy enough
... That when egg-shaped screens start existing
... and OSes can be asked about it
... An egg-shaped screen can describe themselves as round

<liam> [ the TV image was square; depending on CRT adjustment you lost the corners or had a Dark Margin ]

Florian: But this is implementable, usable, pragmatic, overly simplistic, but not a terrible starting point
... Device manufacturers that ship non-circular devices can adjust their Android...

<heycam> tantek: I think that wasn't a problem because TV was shot with a known unsafe region (not sure "unsafe" is the right term, but an area around the edge of the frame that is allowed to be obscured by the TV)

<tantek> known safe region

Rossen: Still no conclusion

<tantek> heycam - perhaps that's a better method then - safe regions

SteveZ: Agree. Need an action to write up a proposal

<heycam> tantek: the author could declare that in the page, too

<scribe> ACTION: Florian to make proposal for round display media query [recorded in http://www.w3.org/2016/01/31-css-minutes.html#action09]

<trackbot> Created ACTION-752 - Make proposal for round display media query [on Florian Rivoal - due 2016-02-09].

<BradK> Dinner-time!

<BradK> Good night.

<Bert> (Lunch until 14:00, i.e., 55 mins)

<franremy> have a good lunch

<franremy> will probably not join this afternoon

<franremy> or maybe just by irc

<BradK> Same here. At best I will glance at irc before sleeping.

<Bert> (Lunch is now officially over, but some people don't know it yet.)

<astearns> still waiting on a few people to settle, but we'll start soon

<astearns> anyone still on the phone? please speak up in irc if you are

Behavior of contains: paint and overflow somethingorother

<astearns> Behavior of contains:paint and overflow:clip, text-overflow and resize properties

<eae> leviw

leviw: Position that I have is that we do not want to conflate the notiion of having a resize handle and text ellipses with paint containment
... keep that just a performance thing
... Want to support clip as overflow: clip
... But not have it as part of paint containment
... Florian has differnet position

Florian: If we look at how we came to this, the reason clip was introduced and depended on
... Was that it wouldn't make sense to have resize handler and text-overflow: ellipsis containment on the other hand
... but not be able to have both at the same time
... or the full effect ove both at the same time
... By the full effect of both at the same time, I mean, if you wanted both and didn't have 'clip', you'd need ot have 'overflow: hidden' which may be less performant because of possibility of scrolling

leviw: we don't allocate the buffer but okay

Florian: If you spport overflow: clip and you support containment, and authors can use both they can do everything they want to do
... I would prefer one step less, but preference not a requirement

esprehn: If you trigger too much behavior, you break the multi-actor situation
... two libraries: spreadsheet library that turns ellipsizing on/off
... Separately you have an animation library, which adds 'contains: paint" when it runs animation for perf reasons
... All of a sudden your ellipsis triggers
... I like idea that they are separate concepts

<dbaron> fantasai: historical interesting point here:

<dbaron> fantasai: which is that text-overflow:ellipsis should have always triggered, but for historic reasons due to WebKit had to make it depend on overflow; not an intentional design

<gregwhitworth> fantasai: text overflow ellipses should have always worked, due to webkit we had to make it dependent on overflow

<dbaron> fantasai: designing things architecturally around this concept seems awkward

<gregwhitworth> fantasai: designing architecture around this makes no sense

Florian: for other implementers implementing containment, do you either also plan on implementing 'overflow: clip' *or* have an implementation of 'overflow: hidden' that has no perf cost

?

Florian: If that's the case, I'm okay with the plan

dbaron: We have more-or-less overflow: clip. Trivial to adjust it to curent spec

Florian: Do you allocate a buffer for potential scrolling for overflow: hidden?

fantasai: There's a different frame tree if it's scrollable

Florian: So there's a perf downside to hidden

dbaron: There is, but not graphics memory

Florian: I'm convinced by the multi-actor story

<dbaron> (I don't think)

leviw: The change is that 'contains: paint' doesn't compute 'overflow: visible' to 'overflow: clip'

ojan: This is section 3.3., delete item 1
... Remove "must convert to clip"

<leviw> https://drafts.csswg.org/css-containment/#containment-paint

<ojan> https://drafts.csswg.org/css-containment/#containment-paint

fantasai: "used value is clip" ?

dbaron: Used value is messy

<dbaron> (used value isn't really a general concept)

<ojan> Proposed resolution: Remove any mention of overflow:clip from the containment spec and change section 3.3 to define that clipping happens (just not via used or computed values)

<esprehn> sgtm

<Florian> lgtm

RESOLUTION: Remove any mention of overflow:clip from the containment spec and change section 3.3 to define that clipping happens (just not via used or computed values)

Font Somethingorother

gonna skip coz editor is not here

White space Stuff

Florian: I want a resolution on this, in my head it's done
... No idea how to get rest of group to agree
... We discussed this in NYC, came to a resolution
... which I'm happy with, but koji isn't
... Being a co-editor of that spec, his pov is at least somewhat relevant :)
... At a very high level my position is simple
... 1. Interop is desirable
... 2. whitespace: pre-wrap shoudl preserve and wrap
... We don't have these things today
... Browsers all do different things
... Relevant question is what happens to white space at the end of a line

gregwhitworth: What was the resolution in NYC?

Florian: Resolution at NYC was that white-space: pre-wrap would preserve white space, and break between spaces
... This is not what is happening today
... In Chrome and webkit, all whitespace is preserved *if it would not overflow*
... The bit that would overflow is compacted to zero width

<tantek> or like overflow ink

Florian: which makes it very confusing when you're trying to edit
... The Microsoft behavior does the white space, but the white space at theend of the line is allowed to overflow (like hanging-punctuation)
... Firefox behavior, which is what's specced, is preserved white space is non-breaking and break opportunity at the end of the run

<gregwhitworth> http://log.csswg.org/irc.w3.org/css/2015-05-18/#e553590

<gregwhitworth> resolution from NYC

Florian: doesn't overflow, doesn't compact
... NYC resolution made the default behavior good for the case I care about
... Koji is right to point out that this behavior is not great for other use cases
... I'm okay to have default behavior that's not that
... Whatever we resolve, the default behavior to be, we also need a mode where
... 1. All white space is actualy preserved
... 2. It does not cause overflow, it does wrap
... Afer that I have preferences on how it should wrap, but these are only preferences
... Preferr that asking white space to wrap should not simultaneously allow arbitrary breakpoints in the middle of words
... Fairly strong prefernce

SteveZ: Clarification, you have to pick some breakipoint at the end of the line
... You're saying that breakpoint is the end of the line whethe rin a word or not, at least for one option, and you don't like that option.

fantasai: I have a proposal
... My proposal is maybe in level 4 or possibly right now
... We define Microsoft's behavior as the default behavior
... Because I think that makes the most sense

<tantek> is that Microsoft Word behavior?

fantasai: add value to word-break property "break-spaces"
... which allows breaks between white space characters
... I think that would be the best end result

koji: First, I'm not sure if we officialy revert NYC resolution

Florian: I don't want to revert resolution and then close the discussion. I'm okay with reverting resolution in order to replace with better solution

SteveZ: I think a number of us willing to revert resolution if there is a replacement but not without one
... So can't break it down like that. Let's agree on the replacement first.

koji: For fantasai's propsoal, agree on 2nd point add value to word-break property
... For first point, I would prefer of Word behavior over IE behavior
... It works better for me if default behavior is IE or Word (same as Chrome/WebKit)

Florian: I prefer IE behavior, but okay with allowing both
... On the condition that Chrome will break and wrap the extra spaces, not collapse them at the end of the line
... when word-break: break-spaces is specified

fantasai agrees with Florian

SteveZ: i'm getting confused, if the spaces disappear if I don't say "break-spaces", but they're visible if I say "break-spaces"
... Seems like that would be confusing to a user.

Florian: This is why I prefer the IE behavior over the Chrome one
... I think it's weird that in a mode called "white-space: preserve and wrap" it's not preserved
... But given what's out there, I think it makes sense to allow it

[...]

<gregwhitworth> http://jsbin.com/zudatozoqi/1/edit?html,output

Florian: From 5-sec check, looks like Chrome is doing the IE behavior

ojan: My guess is that this was an accidental change, but maybe we'll keep it ^_^

Florian: In a quick demo, it looks like Chrome does what we've been calling the IE behavior
... So I'm happy
... Safari probably didn't accidentally do the same thing at the sam time
... So we probably still need the same exception
... Unless Apple wants to align on the IE behavior for this?

[...]

fantasai: I think we shoudl just allow both for now

Florian: agree
...

dbaron: The IE behavior is that you're allowed to have white space hang outside the edge of the line box

Rossen: and it's scrollable space, I know :) :) :)

tantek: It's scrollable!?
... you can scroll to see nothing?

Florian: You should be able to scroll to see your caret when you are editing

tantek: We have so many problems with editing, we shouldn't solve this one either.

Proposed resolution:

Spaces at the end of a line must be either visually collapsed if they woudl either overflow or cuase wrapping, or they must hang outside the line.

<Rossen> :)

In order to prevent overflow or wrapping of invisible white space, spaces at the end of a line must either be visually collapsed to fit within the line or must hang outside the line (as in hanging punctuation)

(better wording)

In order to prevent overflow or wrapping of invisible white space, spaces at the end of a line must either be visually collapsed to fit within the line or must hang outside the line (as in hanging punctuation)

koji: This looks good to me
... I still don't understand conversation over there (waves at gregwhitworth )
... Seems there was some miscommunication, I think I'm fine if current Canary behavior is fine

<dbaron> fantasai: proposed resolution has a second part: adding a break-spaces value to word-break

<dbaron> fantasai: ... details to come later

<dbaron> fantasai: definition is that breaks are allowed between whitespace characters

<dbaron> (to satisfy Florian's concern)

SteveZ: Which means white space at the end of the line can wrap to the next line.

tantek: You could resolve that independently.

Florian: I want to resolve together, because replacing the NYC resolution means we lose what I want, unless we add this behavior.

tantek argues over process

<tantek> no I objected to tying too many things together

koji: One issue, NYC allowed breaking before spaces?

Florian: Not doing that break is okay with me

More arguing over process

dbaron: I'm not happy adding more stuff here

astearns: Are you objecting?

dbaron: Not really

astearns: What we have sketched out seems like it'll get us better interop today, and will not close off functionality

dbaron: We should talk about functionality that exists today as functionality that we have interop one

tantek: I'm happy with NYC and happy with today's change that gives us more interop
... I'm not okay to committing ot new funcitonality
... okay with leaving the door open
... I'm not okay with committing to it, it's a separate discussion

Florian: IF we have identified the way to solve a problem, let's put it in the spec and mark ti at-risk

astearns: We've literally spent hours on this. Would you object to resolving to adding the new value to Text Level 4?
... Then we are resolving both, because I've heard nobody objecting to both

RESOLUTION: In order to prevent overflow or wrapping of invisible white space, spaces at the end of a line must either be visually collapsed to fit within the line or must hang outside the line (as in hanging punctuation)

RESOLUTION: Add 'word-break: break-spaces'

Florian: As part of that discussion, we added pre-wrap-auto, do we need it?

fantasai: I'm strongly in favor of dropping it

RESOLUTION: Drop pre-wrap-auto

<tantek> when in doubt, drop

text-wrap: balance and fragmentation

astearns: When you have text-wrap: balance, and the element fragments across fragmentainers, do you continue to try to balance
... I think the answer is yes

Florian: Question is also what does balancing mean?

fantasai: the goal is to minimize the sum of the squares of the extra space left in each line in the element across all fragmentainers

astearns: If I have a 2-line heading that fragments, then don't want to have one word on the second line
... bad enough on one page, it's worse if it's fragmented

SteveZ: Balance means that every line in a given fragment has the same ending point, and there are an integral number of lines
... If the second fragment is shorter than ... ?

Florian reads from the spec

Florian: You want to minimize the variation overall, but you want to do the averaging over the fragment
... If your first fragment is 10em and the second is 4 em don't want to balance at 7.5em
...

SteveZ: fantasai said it correctly. You want to minimize the extra space to the line, it's not the length of the text in the line you care about
... If you say it that way, then you don't run into the issues Florian said

astearns: I'm happy to make that change

RESOLUTION: text-wrap: balance evaluation works off of remianing space in the line, not average line length

text-decoration

koji: Topic is by Masayuki at Mozilla

<astearns> https://readable-email.org/list/www-style/topic/css-text-decor-doesn-t-example-3-in-text-underline-position-break-current-ua-behavior

koji: There was some conversation with fantasai and me

;)

koji: Current text decoration assumes we have a UA style sheet ot determine underline position based on language
... What masayuki and myles and I prefer is that it be more automatic
... rather than UA style sheet to define
... Second point is that current syntax is extensible but more complicated that necessary today
... So prefer simpler syntax
... good enough for now

fantasai: I don't think I understand why we are putting magic into auto instead of relying on UA style sheet

dbaron: We didn't do text-emphasis the wya the spec said

koji: two value syntax is more complicated than single-value syntax
... when single value can do the work, prefer single value for now

fantasai: I still don't understand the issue here, really, so I can't comment

xidorn: what we did for text-emphasis-position was to implement it as a presentational hint

fantasai: So identically to UA style sheet, but it's at the wrong level of the cascade

[which is mostly unnoticeable, unless your'e in a user style sheet rather than author sheet]

xidorn: ...
... text-underline-position has specific concerns
... text-underline-position is something authors are more likely to change

Clarify when "under" alone is used, its position in vertical flow is automatic (the behavior isn't defined today.) The value syntax could be one of: a. No change: auto | [ under || [ left | right ] ] b. Full options: auto | [ under || [ left | right | auto ]] c. Simpler: auto | under | left | right

<koji> https://lists.w3.org/Archives/Public/www-style/2016Jan/0195.html

So now my proposal is above 1 and 2, and:

3. Clarify when "under" alone is used, its position in vertical flow is

automatic (the behavior isn't defined today.)

4. The value syntax could be one of: a. No change: auto | [ under || [ left | right ] ] b. Full options: auto | [ under || [ left | right | auto ]] c. Simpler: auto | under | left | right

fantasai: I agree with 4, I don't agree with 3.
... I don't think we shoudl have auto be language dependent, use the UA style sheet for that
... UA style sheet would assign CJK languages to left or right as appropriate
... and everyone else woudl get auto
... left/right implies either auto ro under, don't really care
... I think that auto should never switch the underline to the over side

koji: I don't know how Gecko switches between two underlines, but with this spec if the page has lang=ja, page would use automatic switching

xidorn: I don't think we've implemented that
... so we haven't supported text-underline-psoition yet

koji: Gecko changes underline position without property, depends on fonts or whatever
... Having this spec will force the underline position to be under

fantasai: Different fonts have different underline positoins anyway

koji: Font infromation has alphabetic position
... If japanese, most ignore that and draw at correct position
... When the page has lang=ja, this spec forces that underline-position is under
... what gecko does, or what I guess gecko does it regardless of language, usuing font or whatever information, they would use auto
... I actrually agree that that's better behavior for CJK
... If the page has lang=ja, but still the underlined text is only alphabet, then underline should be drawn at baseline position

fantasai: I still don't understnad what you're proposing so I can't comment on it.

<Bert> Scribenick: Bert

koji: I need to talk to Moz people and see if I can better understanding.

astearns: Can that be on the www-style list instead?

koji: Yes
... I'll take it back to m-list

astearns: OK, break now

[break]

<tantek> <break duration=15min/>

<zcorpan> ScribeNick: zcorpan

Exclusions and bidi

koji: the issue is CSS exclusions when exclusions speads align
... bidi defines that after linebreak was determined
... bidi algorithm is applied to the line
... so when the line is spread my multiple by css exclusions
... does each part of the line apply to bidi algo?

astearns: my understanding is that exclusions will fragment the linebox and each line will be individually considered for bidi

koji: that answers my question but it's not in the spec

shane: is this the easier behavior?

koji: yes

astearns: an exclusion can intrude in the middle of a line box
... when that happens two lineboxes are created
... each is individually considered for bidi

Florian: need to elaborate on the last part
... is it just like line breaking?

astearns: everythign that would happen with regular linebreaking would happen ehre also

dbaron: i agree this makes sense
... need to specify which half of line goes where

<shane> it's the reordering part that would be impacted by the decision of whether there is one line or two lines.

dbaron: depends on block's directionality

Bert: if the exclusion is very small, might look better to do the reordering as if it were a single line

astearns: this is an error case, it's better to make it so lines are not split

Bert: [describes edge case]

Florian: it's not a problem for LTR-only or RtL-only

Proposed resolution: lines split by exclusions is equivalent to a regular linebreak for the purposes of bidi algorithm

Proposed resolution: lines split by exclusions is equivalent to a regular linebreak for the purposes of bidi algorithm, where which half of the line goes where depends on the block's directionality

RESOLUTION: lines split by exclusions is equivalent to a regular linebreak for the purposes of bidi algorithm, where which half of the line goes where depends on the block's directionality

<eae> yay

Snap points

<gregwhitworth> scribenick: gregwhitworth

florian: Not sure how much we can do without Matt R. and Tab

<astearns> https://lists.w3.org/Archives/Public/www-style/2016Jan/0193.html

florian: the snap points spec does not say whether pseudo elem can have sp or not
... the pseudo spec implies that everything should work unless there is an exception

florain: snap points not having an exception they should apply

florian: there are many specs that say it one way, others another and some don't at all - so assumptions are made and at times are incorrect

rossen: this is in context of snap points why?

florian: because I wasn't sure

dbaron: the way to solve this is to find a spec that should have a definition for this and assign the all elements and hyperlink to a definition to that

<dbaron> i.e., there should be a hyperlink in Applies to: <a>all elements</a> with the anchor linking to something that says "all elements" includes ::before and ::after

fantasai: any spec that states specifically applying to :before :after should be removed unless it's stating that it's excluded

ACTION TabAtkins to change bikeshed to: there should be a hyperlink in Applies to: <a>all elements</a> with the anchor linking to something that says "all elements" includes ::before and ::after

<trackbot> Created ACTION-753 - Change bikeshed to: there should be a hyperlink in applies to: <a>all elements</a> with the anchor linking to something that says "all elements" includes ::before and ::after [on Tab Atkins Jr. - due 2016-02-09].

<tantek> question, what do implementations do with snappoints on :before and :after?

florian: the second part of the question is can you have snap points on other pseudo elements other than ::before/::after - TabAtkins said no

astearns: usecase is to snappoint to spelling errors

rossen: there's scroll to for that type of thing

Tantek: first-line you wouldn't
... it's not cut and dry

fantasai: there has to be a clear use case as it's significant impl cost to achieve this
... I'm not convinced to add this to the spec unless there is author demand
... you might want to have it snap into the viewport, but that's an edges value

florian: I think ::before/::after are compelling

fantasai: for consistency sake

rossen: even they're on the border

plinss: I'm confused about future things, and I don't like constricting it pointlessly

florian: it's due to impl complexity

plinss: think about psuedo's for columns, paged etc - we shouldn't set a precedent

fantasai: I would happily introduce a column pseudo that take snap

rossen: it's most useful on structural elements

plinss: If it's a big barrier I'm ok with a should

rossen: for us it is

fantasai: I would prefer it not, because of the additional testing
... the pseudo draft says whether it applies or not, and when we add more we can add them in

astearns: that means in the future if we have compelling use cases for this we can bring them back in to have support
... in general closing them off now, does this close them off forever

rossen: no - just for this version of the spec

esprehn: I don't think you're ever stuck, we can just add more props if necessary
... as an impl, anything other than ::before/::after is really hard

tantek: there has to be a way to spec an opening for more psuedos

plinss: I'm open to a note that says we may apply this to new psuedos in the future

tantek: I'm ok with an informative note, I don't want to mislead people

<zcorpan> use might instead of may

<zcorpan> in notes

<tantek> ok with might

RESOLUTION: the only pseudo elements that snap points apply to are ::before/::after but add a note that suggest there "might" be a future pseudos that can support snap points

<ewilligers> ScribeNick: ewilligers

florian: if a snappoint has always been beyond reach, and you scroll beyond,
... (draws on board)

it has a somewhat large snap-padding area

we have a large element with a centre snappoint, some margin

a small element with a centre snappoint

<fantasai> Florian draws a scroller, with snap-pading on the top and bottom.

the snappadding is larger than the small element

<fantasai> There's a lare element, fills the size of the viewport

<fantasai> There's also a tiny element, at the bottom of the scrollable area

<fantasai> Both request center snapping

there is no way that you can scroll the small element into the centre

the spec is vague / contradicting itself - two parts of the spec

<fantasai> fantasai: That is a valid snap point.

one : things that are unreachable would be the most appropriate to snap to, you must snap to them

spec does not clarify "most appropriate"

second part of spec: if an element is entirely outside the scrollsnap area, it is not considered

suspects was intended for 1d scrolling

Lots of things should be up to UA, but not this.

making things reachable should not be UA dependent

Floarian: spec is ambiguous. "Must" part relies on ambuguous term

fantasai: we should reorder the paragraph. Expected snap position is bottom of screen

Florian: the part of spec that says you must snap to it use ambiguous words. Other part of spec contradicts: part that speaks about corridor
... accidentally contradicts

"if you never enter the scroll area, not considered"

esprehn: As a user, what do you want to have happen

Florian: I think it is a wording issue

fantasai: We need a specific wording proposal

Florian: Based on tab's answer, I thought there was actual disagreement

<esprehn> astearns: the next step is for Florian to propose a wording change, send to the list

Florian: Spec describes 3 types of scrolling, ... semantic scrolling, inertial scrolling,

4th type: indirect scrollong: move focus, or change carat. no wording in spec

<alancutter> Photo of Florian's diagram: http://imgur.com/27CdHCU

fantasai: explicit scrolling is scroll to specific position

Florian: you are not scroll to specific position. On focus, scroll is a side effect. Do we have invisible carat / focus button. It is not clear.

fantasai: There is a section in spec that Tab and I added, dealt with target case

<fantasai> “

<fantasai> If a page is navigated to a fragment that defines a target element (one that would be matched by :target), and that element defines some snap positions, the user agent should snap to one of that element’s snap positions. The user agent may do this even when the scroll container has scroll-snap-type: none.

The user agent should snap.. So should we apply this to more?

<fantasai> ”

Florian: what happens if container has mandatory snaping and element does not have a snappoint?

fantasai: you need to be careful with mandatory snap position. Authors need to be careful

Florian: other option: things that match the target pseudoclass and focusable things and editable things in a mandary scroll container

if they are not within things that have a mandatory snappoint, have a snappoint

hober: prefer first option

Florian: in that case, the magic is not that hard, but if we want to go without,

make clear to authors

<shane> ScribeNick: ewilligers, alancutter

<ewilligers> esprehn: want to talk to accesibilty people

<alancutter> Florian: As currently defined it will not

<astearns> for those following along on IRC and listening, please do help the scribes by s/error/correcting/

<alancutter> Florian: I think the magic is something we can work and and will be useful.

<ewilligers> zcorpan: web authors will hate this

<ewilligers> zcorpan: gives behavior they didn't ask for

<ewilligers> .. I think we should avoid magic

<tantek> zcorpan: in general we should avoid magic stuff

<alancutter> gregwhitworth: While I sympathise with authors end users will expect endpoints when they hit tab

<alancutter> gregwhitworth: I would prefer accessible users to see input that is selected

<alancutter> Than the preferred behaviour of web authors.

<ewilligers> zcorpan: you are talking about keyboard navigation

<alancutter> esprehn: People make their browser different sizes that produces bad situations.

<ewilligers> zcorpan: when navigate by keyboarf, user tabs between form controls

<ewilligers> .. I would expect snapping to not happen

<alancutter> gregwhitworth: I think that's what we're saying, we should put together a bunch of test cases.

<alancutter> gregwhitworth: We could potentially fake it in some cases.

<alancutter> I don't know if we can resolve but it's worth testing.

<ewilligers> Florian: we need to eventually resolve this,

<alancutter> gregwhitworth: Sure.

<ewilligers> Florian: I have a related other topic, also about indirect scrolling

<ewilligers> Focus on something, moving the carat. Proximity snapping/ . We have a button with no snappoint.

<ewilligers> .. nothing to prevent scrolling into visible area.

<alancutter> astearns: If this is the email that you sent on the mailinglist we should wait for editors to respond.

<alancutter> Florian: If this in not a good time to talk let's talk later.

<esprehn> fantasai: there was a bike sheding discussion to have, about the naming of proximity/mandatory

<esprehn> astearns: what is the names?

<esprehn> fantasai: near and always?

<alancutter> fantasai: The proposal was "near" and "always".

<alancutter> Any other ideas?

<alancutter> esprehn: Sounds great.

<alancutter> Florian: I prefer the current one.

<alancutter> astearns: The benefit to near and always is shortness and we use it in other CSS things.

<ewilligers> Florian: we removed them.

<esprehn> ScribeNick: ewilligers, alancutter, esprehn

<esprehn> Rossen: I prefer proximity and mandatory

<alancutter> astearns: Sometimes it's good to have bikeshedding face to face but it seems like it's not working right now.

<fantasai> fantasai: force / allow?

<fantasai> scroll-snap-type: none | force | allow

<zcorpan> no | yes | maybe

<gregwhitworth> +1 zcorpan

2-d snapping keep or push out

<gregwhitworth> rossen: we did look into, and we agreed with your request

<alancutter> esprehn: We support shipping a minimal subset.

<alancutter> dbaron: Not sure what we currently implement.

<ewilligers> ojan: our people working on snapshots are not here

<alancutter> esprehn: They're interested in shipping an interoperable implementation

<alancutter> Rossen: Is there an official resolution to this in supporo?

<alancutter> Can we put this for resolution?

<esprehn> hober: didn't have an exact resolution in Sapporo

<alancutter> Florian: If this is something we all agree on at-risk is fine.

<alancutter> At risk is the wrong tool and we should remove it.

<alancutter> dino: We want to be the trail blazers and implement it and find it's not useful.

<alancutter> Florian: At Risk allows you to do that.

<esprehn> dino: we don't*

<alancutter> dino: If the other implementors don't want to do it what's the point?

<ewilligers> rossen: This is a really awesome feature, when we ship it would be great if we can without prefix/holding back.

<esprehn> Florian: don't want to drop it and end up with a spec we can't add it back to

<esprehn> hober: we have version control

<esprehn> fantasai: we already accounted for this in the text

<esprehn> dino: we appreciate the great work from TabAtkins and fantasai

<esprehn> dino: but we want the spec to be merged soon so we can implement soon

<esprehn> astearns: not saying keep it out forever

<esprehn> fantasai: Florian is saying we don't want to make changes in the merge that make it impossible to go back to the 2d design later

<esprehn> fantasai: I don't think that'll be a problem

<fantasai> fantasai: That's not what we resolved on, so I don't think that'll be a problem

<esprehn> astearns: I think we have consensus?

<esprehn> ... quiet ...

<esprehn> astearns: RESOLVED

RESOLUTION: defer 2D snap to the next module level of snap points

<ewilligers> astearns: force and allow snapping, much shorter words

<alancutter> SteveZ: Doesn't say the same thing.

<alancutter> Florian: Permit is a good synonym for allow.

<alancutter> SteveZ: Force is a verb, it needs to be a verb..

<alancutter> esprehn: What's the default value?

<alancutter> Florian: None.

<alancutter> esprehn: Why not auto?

<zcorpan> none | force | auto

<alancutter> Florian: Proximity is auto?

<alancutter> Rossen: Auto is the default word for magic.

<alancutter> Florian: It's hard to guess what it does from the name, proximity is more clear.

<zcorpan> none | force | magic

<zcorpan> none | force | proximity

<alancutter> dbaron: Near and exact?

<alancutter> Rossen: Force and proximity sounds good.

<alancutter> Florian: Force and proximity makes force sound like a noun.

<zcorpan> none | woot | lol

<alancutter> When it is a verb.

<alancutter> shans: What about exact?

<Rossen> none | force | ish

<alancutter> Florian: Exact is bad, it sounds like you have to go exactly to that point.

<ewilligers> dbaron: we seem to be happier with nouns and adjectives than verbs

<alancutter> astearns: Next thing, bookmark level auto.

<astearns> https://lists.w3.org/Archives/Public/www-style/2015Nov/0310.html

<Rossen> none | force | near

<alancutter> Florian: I want to talk about bookmark level.

<ewilligers> Florian: there is a set of properties, bookmark-level. When generate pdf

<esprehn> https://www.w3.org/TR/css-gcpm-3/#bookmark-level ?

<alancutter> The bookmark you get in PDFs that take you to certain parts of the document.

<alancutter> The nesting of your sections seem like something derive from the structure of the document instead of

<Florian> https://lists.w3.org/Archives/Public/www-style/2015Nov/0310.html

<alancutter> requiring authors to define it.

<alancutter> "auto" could derive this structure for the author.

<alancutter> esprehn: Which thing does not exist?

<alancutter> Florian: Bookmark level auto, this should be something you can figure out from the structure of the document.

<alancutter> Instead of manually specifying it.

<alancutter> Things could get out of sync.

<alancutter> esprehn: Does any one implement bookmark level?

<alancutter> Florian: Print formatters do.

<alancutter> This will lower the work required to take a document for the screen to a PDF with bookmarks.

<alancutter> I don't think we can do this with selectors.

<alancutter> I tried existing selectors including non-implemented ones and failed.

<alancutter> esprehn: auto doesn't seem very hard to implement this (as an implementer that doesn't implement bookmark level)

<alancutter> As long as it's not like counters in CSS I support this.

<tantek> plinss: I kind of have a fundamental issue of why are we reinventing hyperlinks?

<esprehn> esprehn: I don't want reset, skip, increment, etc. again

<alancutter> Florian: I don't mean we should mandate how a sidebar works.

<tantek> plinss: this whole feature smells like something very specific to PDF and has nothing to do with the web platform

<alancutter> astearns: dpub have been talking about an explicit <nav> element with links.

<alancutter> astearns: I don't think it's adding a random feature it's streamlining a process

<alancutter> fantasai: There are multiple implementations of bookmark level.

<alancutter> Florian: Viviostyle has it in their roadmap to implement this for screens.

<alancutter> I think this is part of CSS and shouldn't be treated as a separate focus group.

<alancutter> esprehn: Thinking of houdini this is not the way we want to go with CSS.

<alancutter> We want to add extensibility points instead of magic.

<alancutter> Florian: What is magic about it?

<alancutter> SteveZ: It's a table of contents.

<alancutter> plinss: If you want an element that generates a TOC that should be part of the document not CSS.

<alancutter> Florian: Our engine needs to implement this to be compatible with exsiting content.

<alancutter> plinss: TOC is content, not styling.

<alancutter> SteveZ: A TOC is a relabeling of content. It's presentational.

<alancutter> plinss: I disagree.

<alancutter> SteveZ: It's taking existing content and putting it elsewhere in the display.

<tantek> Is bikeshed considered presentational?

<alancutter> skk: The bookmark sounds like a data structure and not like styling.

<alancutter> esprehn: With custom properties you can define the bookmark level property to do whatever you want and we don't have to talk about this.

<alancutter> Florian: It has three interoperable implementations, it's not a new feature.

<alancutter> tantek: Let's see the usage numbers, if it's like 10...

<alancutter> Florian: Should I go to WHATWG for this, is the CSSWG not allowing this?

<alancutter> .. I can't do this with houdini with current browsers.

<alancutter> esprehn: I don't think this fight is productive, there's an out now for this.

<alancutter> Florian: This is a request for a new keyword for an existing property.

<alancutter> .. Not about removing this property from CSS.

<alancutter> astearns: We are not going to resolve modifying or removing this property today.

<Florian> http://jsbin.com/fuloge/edit?output

<ewilligers> Florian: If you open this, it appears that Chrome and Webkit do one thing

<ewilligers> other browsers, and print formatters, do something else

<alancutter> Florian: Chrome and WebKit are the only ones that get this right.

<alancutter> It's a list of numbers positioned relative down.

<alancutter> dbaron: You have to use frame source. It doesn't work in jsbin.

<alancutter> The question is "does position relative work across pagination?"

<alancutter> Florian: I think the spec says...

<Florian> https://drafts.csswg.org/css-break/#transforms

<alancutter> dbaron: Is this CSS break? This is a new spec, newer than the implementations.

<alancutter> Florian: Am I correctly understanding that the spec is asking for Chrome's behaviour?

<alancutter> astearns: The spec is a bit older than David represented.

<dbaron> OK, the spec is 4 years old

<dbaron> still newer than all implementations

<alancutter> It ended up this way so we would not lose content when paginating with relatively positioned content.

<zcorpan> in httparchive 470k pages i see one page matching bookmark-level in css (actually prince-bookmark-level:1): http://www.wowrean.es/ http://eu.wowrean.es/public/print-default.css

<alancutter> dbaron: Does Chrome get this right because it gets all the other parts of this section wrong and it gets this right?

<alancutter> Florian: We're wondering what our implementation should match.

<alancutter> esprehn: Firefox looks like it's moving all the content down in each column

<alancutter> astearns: Both behaviours have their uses.

<alancutter> Either in printing or in scrollable situations.

<alancutter> I think Firefox's behaviour looks nicer in this case.

<alancutter> esprehn: We implement this section of the spec wrong.

<alancutter> Florian: So after fixing you're likely to match Firefox?

<alancutter> fantasai: A transform element that spans pages should

<alancutter> The reason for that is if you don't do that you lose content.

<alancutter> We recommend that for printing we do this slicing after having tranforming stuff.

<gregwhitworth> In addition, I opened a bug on Chrome that deals with multicol that got duped to this one, and it's assigned - they may be able to address this while they're in this code: https://code.google.com/p/chromium/issues/detail?id=223068

<alancutter> esprehn: I suspect our response is we will not implement this, multicol implementors have said this seems very complicated.

<alancutter> Florian: I'm not happy about the "should", some browsers will behave different.

<alancutter> fantasai: I would rather a should than nothing at all.

<alancutter> dbaron: I'm skeptical about "should" because it takes a lot of energy to implement this and browsers are probably going to implement something else.

<alancutter> I'd rather not add complicated things to specs for things no one implements.

<fantasai> "3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

<fantasai> "

<fantasai> RFC2119

<alancutter> esprehn: We are interested in an interoperable version of multicol, we're not interested in anything fancy.

<alancutter> Florian: Once that happens all browsers and print formatters will do the same thing.

<alancutter> hober: We don't want to regress wrt the epub corpus too much there.

<alancutter> Florian: I have my answer regardless of what the spec ends up saying.

<alancutter> astearns: Sounds like a good place to leave this.

<fantasai> fantasai: If Hyatt has a *better* solution, be happy to consider that for the spec

<alancutter> astearns: Shane wants to have a talk about scroll linked animations

<alancutter> astearns: The second thing is koji had an additional topic if you're ready.

<alancutter> We have <30min left.

<astearns> https://lists.w3.org/Archives/Public/www-style/2016Feb/0010.html

<alancutter> Koji: I replied to mailing list about non standard property to remove from blink and WebKit.

<alancutter> "word-break: break-word"

<ewilligers> koji: Should we add 'break-word" to the spec.

<ewilligers> Historical from webkit

<alancutter> It was historically added to WebKit for web compat despite being non standard.

<ewilligers> BogdanBrinza: 9 years ago, change in webkit references IE7

<alancutter> BogdanBrinza: The usage is fairly high.

<ewilligers> .. Used in yelp, stack overflow, fairly big sites

<alancutter> koji: It's very similar to word-wrap: break-word except it doesn't expand the containers.

<alancutter> The use case is imagine normal word wrap where the text contains a long URL.

<gregwhitworth> they add it to contenteditable by default, here's a testcase http://jsfiddle.net/pfe9mj4o/10/

<alancutter> word-wrap: break-work expands the container while word-break: break-word will break the word to maintain the container size.

<alancutter> fantasai: Is Microsoft implementing this?

<alancutter> BogdanBrinza: We are considering it, the web depends on it.

<alancutter> We will consider implementing it for web compat.

<alancutter> fantasai: The naming is very confusing.

<alancutter> Florian: These names are already confusing, adding this makes it worse.

<zcorpan> break-break: break-break;

<shane> bork-bork: bork-bork;

<alancutter> astearns: That's a good question, if there's a typo do you standardise it for web compatibility?

<alancutter> fantasai: I think the better solution would have been to let the author set the minimum size of the table cell.

<alancutter> Florian: Regarding this it sounds like you're considering this for web compat, I don't think the working group is best for this decision. Decide and if you do send us the spec of what you implement.

<alancutter> fantasai: I don't object to adding this if implementers decide it's necessary for compat.

RESOLUTION: Add to spec depending on whether Edge/Firefox implement it.

<alancutter> fantasai: Do we know whether we can switch table cells to honour the min width property?

<alancutter> gregwhitworth: I don't have data but I'm shocked that you can't use it.

<alancutter> We can gather data.

<alancutter> fantasai: Proposal if it's possible: min-width applies to table cells.

<dbaron> dbaron: we could add properties that set the intrinsic widths, unlike the min/max-width properties that set constraints on the width ... useful outside of tables

<alancutter> fantasai: Let's switch to sizing.

<alancutter> Was talking to Tab about sizing module.

<alancutter> Propose: Taking keywords that we have and define them in terms of CSS2.1.

<gregwhitworth> ACTION: gregwhitworth to look into allowing min-width on tables to work, and auto to work like it currently does - will require test cases for L2 of tables and possibly sizing as dbaron said it's helpful for intrinsic sizing beyond tables [recorded in http://www.w3.org/2016/01/31-css-minutes.html#action10]

<trackbot> Created ACTION-754 - Look into allowing min-width on tables to work, and auto to work like it currently does - will require test cases for l2 of tables and possibly sizing as dbaron said it's helpful for intrinsic sizing beyond tables [on Greg Whitworth - due 2016-02-09].

<alancutter> fantasai: ... This would let us trim down the spec a lot.

<fantasai> https://drafts.csswg.org/css-sizing/

<alancutter> astearns: Sounds like a fine plan, make the edits, send to working group and see what feedback you get.

<ewilligers> fantasai: dropping chapter 4 and 5, and fill-available keyword

<alancutter> astearns: Anyone object to this idea?

<alancutter> Florian: Does this limit us to refer to these concepts?

<alancutter> fantasai: No you can still refer to them in Sizing 4.

<alancutter> astearns: I'm not comfortable with resolving on this strategy just yet as we've only had 5 minutes to think about it.

<alancutter> fantasai: I have an issue with alignment but I'll talk to dbaron first.

<alancutter> astearns: Adjourned.

<astearns> skk: https://www.eventbrite.com.au/e/web-developers-meetup-css-svg-houdini-registration-20098723824

<astearns> don't know if the list is in order, though.

<BradK> Is there going to be a WebEx today? I didn't see a new url

<astearns> did you want to call in for the fx topics?

<BradK> You mean a separate fx meeting, or is that the topic for CSS today?

<astearns> BradK: today's meeting is the joint-CSS/SVG groups

<skk> Ala

<skk> astearns: thank you!!

<BradK> Ah. Then yes. It doesn't mean I would have anything to say, per se, but would at least like to listen.

<astearns> BradK: OK, when Bert gets in, we'll set up the phone

<BradK> Thanks. Am I the only one who wants to call in?

<astearns> so far

<BradK> For me, it would just be for the morning, if that makes any difference.

<astearns> BradK: good to know - thanks :)

<BradK> Oooh, I missed page floats yesterday. 😢

<BradK> Lol

<astearns> room still a bit less than half-full. will start a bit late this morning

<BradK> Thanks. Hope it isn't too onerous.

<BradK> For you, I mean

<Bert> WebEx: https://mit.webex.com/mit/e.php?MTID=m80f28373d096fdf9a857d8834566e782

<Bert> Or: +1-617-324-0000 643 987 115 and same password as yesterday

<BradK> 👍 California

<tantek> scribenick?

<tantek> scribenick: tantek

Florian: not a solid offer, but I can try to co-host 2017 April

astearns: we have Europe in the fall (TPAC), probably Japan in the spring
... as much as I like Sydney in January, might be better to have January in the US next year

fantasai: possibly Europe in January?

astearns: there's a possibility of glazman desiring to host next February
... maybe October 2017

fantasai: when is TPAC?

Bert: probably later in 2017

astearns: with TPAC in September, then meeting in April [2017] that's a long time in between

fantasai: maybe January/February 2017

astearns: main thing is fixing the location for the next meeting

dbaron: what I'm writing is Jan/Feb US or Europe
... spring 2017 possibly Japan
... summer 2017 meeting likely if TPAC late

<franremy_> * shane zcorpan the room temperature is a proof its true

astearns: now that we have CSS and SVG together
... let's do introductions
... people on the phone

<dbaron> I updated https://wiki.csswg.org/planning#upcoming-meetings

BradK: I'm Brad Kemper, invited expert for the CSS WG

please type your intros into IRC!

BradK: franremy_ is on the phone too

<gregwhitworth> Greg Whitworth, Microsoft

BradK: ... peter rossen shane greg ted

<BogdanBrinza> Bogdan Brinza, Microsoft

<Rossen> Rossen Atanassov, Microsoft

<dino> Dean Jackson, Apple

<shane> Shane Stephens, Google

<nikos> Nikos Andronikos, Canon

<birtles> Brian Birtles, Mozilla Japan

<Florian> Florian Rivoal (Vivliostyle)

<SteveZ> Steve Zilles, Adobe

<heycam> Cameron McCormack, Mozilla

<xidorn> Xidorn Quan, Mozilla

<zcorpan> Simon Pieters, Opera

<dbaron> L. David Baron, Mozilla

<astearns> Alan Stearns, Adobe

<eae> Emil A Eklund, Google

Tantek Çelik, Mozilla

<Bert> Bert Bos (W3C)

<ed> Erik Dahlström, invited expert

<fantasai> fantasai, Invited Expert

<skk> Hiroshi, from BPS

<AmeliaBR> Amelia Bellamy-Royds, Invited Expert (SVG)

<baba> Takao Baba, BPS

astearns: plan for the morning is FX in this room, text in the morning

shane: ...

<dbaron> Jihye Hong, LG

shane: we're going to break out and talk about scrolling and animation effects

<dbaron> Hyojin Song, LG

<dbaron> Joone Hur, Intel

dbaron: I think that also requires knowing what the other agenda is

Florian: (reads from wiki)

https://wiki.csswg.org/planning/sydney-2016#wednesday-am

this room is talking about text

break-out follow shane to talk about scrolling and animation effects

astearns: fill & stroke on CSS text - who put this? Elika

<astearns> (elika sets up)

elika projects

trackbot, status?

<fantasai> https://drafts.csswg.org/css-text-decor-4/

fantasai: tab and I had action item from couple of years ago
... to draft up fill & stroke properties from SVG
... and how they apply to text
... we did that a few weeks ago
... which spec should they go in
... we stuck them in text-decoration
... might need to go into their own separate spec
... so that's one open question
... where should we put these properties?

heycam: I break-out some improvements to the stroking properties which we decided to defer from SVG2

<heycam> https://svgwg.org/specs/strokes/

heycam: has not been made a working draft yet
... should be a single place for all of these

<dbaron> We're minuting the other conversation in #fx

heycam: rather than multiple documents
... I don't particularly mind where they go
... so this is just breaking out the SVG definition and then a couple of extensions to those values

fantasai: I think we can mere the two
... for stroke-alignment we shortened to stroke-align
... we had stroke-position but that was confusing with all the image stuff that has to go in

heycam: so that's the alignment property that ...

fantasai: we were talking about it last time
... we had agreed to add it
... it doesn't work to stroke text with center alignment very well
... if you have a semi-transparent stroke

tav: I looked into implementing stroke-alignment
... and it was quite complicated
... what you do with the end caps
... it gets quite complicated

fantasai: I think the round cap would be a full / whole circle
... the rest of it would look like you clipped the shape itself

tav: what do you do about paths that cross each other
... how do you handle the fill rules
... i would love to have
... thought it would be easy
... turns out to be very complicated
... presumably these issues don't crop up with text

^^^ last one was heycam

<AmeliaBR> Examples of these problems in the Issues in SVG Strokes: https://svgwg.org/specs/strokes/#SpecifyingStrokeAlignment

fantasai: we can put it into the draft

Tav: would be good to work on it
... one thing that was missing, SVG now has paint order

fantasai: we didn't think that would be needed in CSS
... you never want to put the stroke behind the paint

heycam: conceptually yes, but in practice, outsetting the stroke
... and making sure you don't get "seams"(?) between the outer stroke and the shape
... at least if you have opaque colors

Tav: you could also do the painting and then apply the opacity to that

fantasai: you could also ... solid filld and transparent stroke
... we re-arranged tthe way the properties interact so we have shorthanding
... so stroke is stroke-...
... same with fill

<BradK> Or always have the text knock out the stroke

fantasai: we put in all the background properties
... have all been put in as equivalent fill and stroke things
... we have the fill-break and stroke-break properties about how you deal with multiline elements
... do you glue everything back together
... do you take bounding box
... do you clone it separately

heycam: shorthand for stroke, concerned that SVG defines specifying stroke-width before stroke
... I don't know if you done any research

fantasai: we had two options for stroke shorthand
... 1 include all
... 2 include only paint related properties

<Zakim> AmeliaBR, you wanted to discuss about breaking fill/stroke paint into sub-properties & how to integrate with SVG paint servers

?

<AmeliaBR> sorry, WebEx says I'm not muted.

<BradK> Maybe wrong input source for the microphone?

Bert: everything looks ok (webex)

(hears noise)

AmeliaBR: this is me without the microphone so I hope it is not too noisy
... couple things I wanted to break out
... so far SVG has talked about breaking out stroke and fill point into many different subproperties
... to match the CSS background
... that seems to be what they have done here
... would love to get that into SVG2
... that puts a lot of timing on getting all the issues cleaned up
... when I looked at it previously the main issues come around how do you work the CSS background properties with SVG paint servers, things like object bounding boxes

fantasai: we did ... with the fill and stroke-origin properties
... on the background where it is transparent, the text is painted by itself
... you need to know what is settting ...
... if I am an element and parent has a fill, need to not just use same image but also origin
... decided to make these inherit
... use a match-fill value
... use the same fill positioning area as my parent
... so that if you sent a bunch of backgrounds on the paragraph, those properties will inherit to the links and anything inside it
... but you would use the positioning area defined by the paragraph
... so that it looks like there is no element tree
... everything's got the same positioning pattern
... you can also do some of the text has a different color
... when you set the stroke or the fill, you choose which box to use as origin, content-box, stroke-box, fill-box
... for the shorthand instead of settting fill-origin to initial value,
... when you set the shorthand you set your fill, it will automatically make that the origin for that element and its descendants

AmeliaBR: that makes sense
... does enable matching up with existing SVG behavior
... which is that TSPANS and other child elements match the bounding box of the parent text element for painting and scaling the paint content
... there are a couple of other confusions with paint servers, because the paint server itself has these two different options
... for object bounding box vs. user space use
... those are issues we have seen come up with filters and masks and clip paths
... we don't know how those translate for non-SVG content
... overall this is a great draft
... I'd like to see all these options and controls in SVG2
... or whatever part of SVG start supporting multiple layered fill & stroke
... right now all we have in the spec is single complicated shorthand property
... at the very least we have to make sure that the syntax we are using for the fill and shorthand properties
... are consistent with all the options you are adding
... there is a timing issue about what spec should have all these in it

fantasai: If we are applying these to CSS, these should not be in the SVG spec
... we need these either in a CSS module or an FXTF module
... there's a couple of issues
... 1 was SVG paint server issue that was mentioned
... 2 there was the question of default fill origin. if you don't see it it should it be the content box or the fill box
... so the content box padding box border box defined as CSS. for SVG shapes we tried to be consistent with masking
... box ... box ... box...

if it's an inline element, the intention was the glyphs themselves, not the box

if you have Zapfino and want to fill it that goes from super darkto super light

scribe: it includes all of the glyphs, including the descenders outside the box

heycam: for text the fill bounding box is the one that gives you the union of the glyph cells
... a different name like ink box may make sense

fantasai: what about the stroke box

heycam: yes stroking box

fantasai: what does the stroke box mean for SVG? is the fill box sometimes smaller?
... what do you do when you have those kinds of glyphs?

heycam: maybe it's an internal naming term in the spec that conflicts
... mention fill box in the SVG spec
... and then change the glyph cells to something else?

fantasai goes to draw a picture

<AmeliaBR> That's probably an issue in the SVG spec currently (multiple bounding boxes not well defined for text)

AmeliaBR: one thing, have you looked at it yet, I've seen it come up in SVG
... painting order for fill and stroke, it's a question of when glyphs overlap, or stroke from one overlaps another, or text-shadows, whether you draw one glyph at a time (most SVG implementations), or one element at a time.
... not sure if that is spec'd
... it's something that results in unpleasantly ugly options
... I want it as an option in the spec eventually

fantasai: in CSS the text for shadows, the shadows are supposed to be just below the text
... the shadows are all underneath all the text for the element
... ...
... we encourage the user agents to paint the shadows behind all of the text

heycam: ... strokes underneath the other glyphs...

<scribe> ACTION: fantasai to investigate the paint order of the glyphs with respect to shadow and stroke and fill [recorded in http://www.w3.org/2016/01/31-css-minutes.html#action11]

<trackbot> Created ACTION-755 - Investigate the paint order of the glyphs with respect to shadow and stroke and fill [on Elika Etemad - due 2016-02-09].

fantasai: ... because if you have negative letter-spacing you have glyphs that end up on top of each other

AmeliaBR: it's also ugly when you have glyphs showing boundaries between glyphs when they're supposed to look continuous

fantasai: excellent point and why we should bias towards not doing that

heycam: before you were talking about issues with SVG paint servers
... is that with the URL syntax?
... same issue as in masking spec?

fantasai: we didn't really go too much into the paint servers and how they should work
... we wrote it up as if paint servers didn't exist (laughter)
... haven't really incorporated that aspect into the spec

heycam: in general this looks good

fantasai: one other thing we came up with
... bikeshedding issue
... getting pissed off at how inconsistent SVG names things
... made a table of this is the syntax, this is the syntax we want to have

heycam: to chang it?

fantasai: we don't know
... we just want to ask SVG WG

heycam: many things are possible if you're willing to put up with aliases to your code paths
... we can try

<astearns> https://drafts.csswg.org/css-text-decor-4/#perfect-world

heycam: we tend not to introduce aliases to fix things like this

fantasai: the dash-adjust ...

heycam: nobody implements that yet

fantasai: we made some slight modifications to the syntax

heycam: tav just asked is that really useful for text?
... i have a concern about dashing on text in general
... it exposes things like where is the implementation considering the start of the glyph
... I almost want to disallow dashing on text completely

fantasai: I don't have a strong opinion on that

<AmeliaBR> We (SVG WG) has already decided that text does not have a canonical origin for dash-offset

fantasai: we were talking about it because of borders and wanting to be consistent

<BradK> +1 for borders

fantasai: anyone that wants to dig more into anything
... the shorthanding issue is something we need a good understanding
... should stroke be just painting
... there's one that deals with geometry
... ... paint stuff

<BradK> +1 for adding dashes between words

Tav: SVG also has text-decoration where you can put different stroke and fill

fantasai: how?

Tav: part of SVG 1.1

fantasai: haven't read it

AmeliaBR: in SVG2 there are two new properties that are replacing text-decoration-color
... with text-decoration-fill and text-decoration-stroke

<AmeliaBR> https://svgwg.org/svg2-draft/text.html#TextDecorationFillStroke

AmeliaBR: and so they would naturally fit with these schema

fantasai: I don't think you can replace text-decoration-color because we already have that in CSS

we have to define the relationship

Tav: I think that's what we do

AmeliaBR: ... you have fill-color having an intial value of current-color
... can do with default style sheets ... it's just an extra complication

fantasai: a little confused
... you want the fill-color not to default to current-color?

AmeliaBR: in SVG you have to set fill to current-color
... if you want the color property to have an effect

fantasai: so the default is...

AmeliaBR: fill defaults to transparent black

fantasai: that could be handled by a user agent style sheet

heycam: next steps?

fantasai: you have to tell us if you want this in a separate "paint" spec?
... and we need to incorporate your spec

<ed> the initial value for 'fill' is black, not 'transparent black'

heycam: I'll take a look at the two specs

AmeliaBR: I would vote for having a "paint" spec that could be used by both SVG and CSS
... that section in SVG2 is not very defined now, but is something people want for the multiple layered fill & stroke stuff
... would be good to get that cleaned up
... even if implementations for SVG text were slower to happen

Tav: does this allow for having multiple strokes? with different stroke widths?

fantasai: we didn't add that to the spec

Tav: sometimes you build up complicated paths like a road, center of the road red, dashed lines on shoulders

fantasai: that's going to be tricky because we're already using commas in the stroke-image
... so we can't use comma-separate syntax
... unless you're ok with using image fills for everything

Tav: how would an image fill work per path

AmeliaBR: I don't think it would be a complication
... it is matter of the stroke geometry properties also being list properties

fantasai: then you would be able to define geometry, but how do you define what color they are

heycam: if you really had to you could have CSS image values you would "salt"(?) with colors

fantasai: those layer. you want to have things side by side. different kind of list.
... so you have a two color stroke, one red, one blue

if you have two colors, you will get red and blue stacked on top of each other in z-order

scribe: we don't have a syntax for having multiple fills
... beause the fills are already a list of z-ordered images
... and you want laterally stacked fills

AmeliaBR: the idea is that each stroke would be a different stroke layer
... the only place it would get confusing, is
... that the CSS background syntax has multiple images but only one color at the bottom
... it would be nice to be able to have multiple colors especially for stroke
... one way would be to use the image function to have a solid color

fantasai: I think I understand what you're saying
... similar with people asking for multipel borders

BradK: for decorate borders
... my experience
... make each one wider than the one above it

Jet: question about fill
... it's great that these specs are coming around
... we (Mozilla) are currently being lobbied to implement the circa 2006 -webkit-text-fill-color
... my question is about the delta between the fill color stuff we are working on here
... and the implementation detailas of -webkit-text-fill-color
... and if there is a delta
... then for the same reasons we have to implement the -webkit-...
... then webkit and blink can't change either
... is that something we can align on
... to cover existing content?

fantasai: those should ideally map to what we are doing here

<BradK> s/1make each one wider than the one above it/make each one wider than the one above it, and then knock out the text shapes

fantasai: it should just work that you drop the -webkit- prefix and just get the stroke-color

BogdanBrinza: if you implement ...
... what we've seen on some websites is fill but not stroke, it makes things worse

fantasai: we decided to reuse the SVG properties because they do the same things already

AmeliaBR: they match up pretty well
... they should match up pretty well
... the other one that should match up is background-clip
... because that's where I most often see text-fill to transparent in order to just show the background fill to text

astearns: and that's the next topic

hober: question
... the stroke-align property
... could we add an issue?
... CG (?) doesn't really provide this capacity
... so I'd rather not have it
... maybe too early to mark at-risk?

fantasai: we can mark it at risk

hober: basically we can do center

fantasai: which is the intial value

<astearns> (or add a note that we're not sure it's implementable)

fantasai: goal of this spec is to replace the SVG properties ...
... not sure of the web compat impact

astearns: let's close this topic

<alancutter> ScribeNick: alancutter nainar

<alancutter> astearns: New topic: background-clip

<nainar> jet: need to project?

<nainar> jet: beack to agenda and paste the url

<nainar> .. to irc

<jet> https://webkit.org/blog/164/background-clip-text/

<nainar> jet: another request from core web compat team circa 2006/2012

<nainar> ..background-clip-text

<nainar> .. desire to specify a way forward in a universal way "correct way"

<nainar> .. desire to implement ... in FF

<alancutter> ... implement -webkit- syntax in FF

<nainar> .. see if we can write spec text around that behaviour

<nainar> jet: first thing - see documentation that can be normative text

<nainar> .. around that behaviour

<alancutter> ... around the existing behaviour

<nainar> jet: edge team implement this one?

<alancutter> .. did edge team implement this -webkit- one?

<hober> https://webkit.org/blog/164/background-clip-text/

<nainar> gregwhitworth: i dont think so - filed multiple times

<nainar> gregwhitworth: do want to implement havent gotten around to tit

<nainar> jet: interest in spec

<nainar> jet: webkit behaviour appear as normative Behaviour

<alancutter> jet: Is it desirable for it to appear as normative text or should it be a compat spec entry?

<nainar> fantasai: should be a compat spec entry

<nainar> fantasai: should be a background level 4 module entry

<BogdanBrinza> Edge didn't implement background-text-clip but it's known issue on our backlog

<nainar> fantasai: if it needs to exist for engines to implement for web compat

<nainar> .. spec the prefixed thing - unprefixed thing

<alancutter> jet: I'll take an action to write

<nainar> .. the acual defacto spec for the webkit property and run it by people who dont have implementation

<nainar> fantasai: do we resolve to add to background level 4?

<nainar> plinss: i really reaaly dislike the idea of having a prefixed and canonical spec

<nainar> .. we have quirks spec for stuff that isnt css do for web compat

<nainar> fantasai: harder to write spec - standards mode thign

<alancutter> AmeliaBR: If the longterm goal is to use the new fill properties

<alancutter> does it make sense to have it in the same spec as the fill properties

<nainar> fantasai: no because value for background-clip property

<tantek> W3C specs (e.g. HTML) have put things directly into deprecation that were never in any previous W3C spec

<nainar> .. could put in here not a filler stroke value

<tantek> deprecation does mean that implementation should (or must) support it but authors should not use it

<nainar> fantasai: thats fine

<alancutter> astearns: I like having it in the same spec as what is actually CSS so people find it.

<alancutter> astearns: Are you okay with putting it in an appendix.

<nainar> Florian: it is normative - authors must not use this - browsers may/should support this

<alancutter> fantasai: I think "may" is fine

<nainar> Florian: normative - must not use for users, in same spec - yes ugly name - others names due to legacy that arent branded

<alancutter> plinss: I'm okay with it being in the ? spec as long as it's clearly defined.

<nainar> fantasai: youre a bad person if you use this

<alancutter> plinss: Your website is bad and you should feel bad if you use this.

<nainar> astearns: resolve to add this to the spec with caveats proposed

<nainar> RESOLVED : resolve to add this to the spec with caveats proposed

RESOLUTION: Merge heycam's spec text with paint fx repository

<nainar> astearns: objections?

<nainar> new topic: more text issues

<alancutter> Tav: Let me paste link.

<Tav> http://tavmjong.free.fr/SVG/TEXT_SYDNEY_2016/

More text issues

<fantasai> Note to fantasai: switch default value to fill-box, map it to padding-box, define more clearly that it's glyph ink bounds on inlines. Or something

<alancutter> Tav: I have a whole series of issues with trying to finalize SVG text

more text topics

<alancutter> ... maybe I should go through how SVG text differs from CSS text.

<alancutter> .. I have two diagrams there

<alancutter> ... For HTML you have an absolute size and right flow left

<nainar> ... float right float left using shape oustide property you can cut out regions - you end up with a region you can fill

<alancutter> .. you can cut out regions and have a region that you fill which is the blue line region

<nainar> ... in svg we dont have floats - have a text element

<alancutter> .. because we don't have floats you can have a shape outside that you exclude

<alancutter> ... once you get to that point everything that works for CSS should work for SVG

<alancutter> ... we in the SVG group have discussed at what level do we combine with CSS?

<alancutter> astearns: One way to paper over the difference is to have shape-outside to apply to exclusions.

<nainar> astearns: apply to exclude - 1st diagram could have instread of floats exclusions - map closer to svg

<nainar> ... map closer to what we are trying to layout

<alancutter> fantasai: SVG provides some shape and you get a containing block

<nainar> Tav: yes, been mine..

<alancutter> ... CSS just fills that makes sense to me.

<alancutter> fantasai: Whether you think about that as a shape inside or a bunch of floats.

<alancutter> ... the spec only needs to deal with containing block and shape.

<nainar> Tav: right - a few issues

<nainar> ... in html a float on one side - float right on the other side

<nainar> .. because the shape outside applies to float..

<nainar> there is one shape per float

<nainar> .. in svg have a float on each side so you can exclude values

<alancutter> AmeliaBR: The exclusion spec would do this

<alancutter> ... but its not using the syntax you have here

<alancutter> ... shape-outside is applied to the element that interrupts the flow not the shape below.

<alancutter> .. with CSS exclusions it could be made consistent.

<alancutter> ... depends whether SVG wants to go ahead with ways to do the exclusions or ???

<nainar> astearns: i would qualify the status of the spec as waiting implementer interest beyond the first implementation

<nainar> ... better if svg forges on

<nainar> Tav: get back to we are wrapped text

<nainar> .. relies on a lot of modules

<nainar> Tav: how to layout the top line?

<nainar> .. not just svg issue - you can with floats and now with round display

<nainar> .. you can have a non straight edge

<nainar> .. what do you do .. move down a few steps

<alancutter> fantasai: Yes that's how normal floats work.

<nainar> ... not sure thats

<alancutter> fantasai: It's not fantastic but that's how normal floats work ... baseline grid

<nainar> Tav: i saw there wasa spec - line width? may be solution

<nainar> ... slide down till you fit something in

<nainar> ... next question how to handle overflow - n natural way of expanding

<nainar> .. a good solution would be to expose the text somehow

<nainar> .. by clicking on ellipsis on end - eg

<nainar> .. or a tooltip appear

<nainar> .. in shapes too you continue underneath rectangualr area

<nainar> .. covering up other content..

<alancutter> astearns: That's the general situation for overflow.

<alancutter> ... I like your overflow tooltip to add.

<alancutter> .. The basic case should be what CSS does with their defined boxes.

<alancutter> ... it overflows in the direction

<nainar> Tav: ok we dont have a block content - we could fake it

<nainar> .. using he width?

<nainar> s/whiff/width

<nainar> Tav: how to handle shapes like doughnut holes?

<nainar> .. the svg 2.1 spec had

<nainar> .. kind of looks like a lot squeezed in the middle

<alancutter> astearns: Is this the same link?

<nikos> http://tavmjong.free.fr/SVG/TEXT_SYDNEY_2016/

<Tav> http://tavmjong.free.fr/SVG/TEXT_SYDNEY_2016/

<alancutter> Tav: Same link here.

<nainar> Tav: same discussion that wrap flow property not appropriate in this situation

<AmeliaBR> I've written up some comments here, too. Possible new property: https://github.com/w3c/svgwg/issues/37#issuecomment-178850020

<nainar> .. limit text to one side or other side

<nainar> .. to start what is shown there is the proper thing to do..

<nainar> .. in the future add another property

<alancutter> astearns: I'm not sure I understand... looking at fig 11?

<nainar> Tav: yesis there a problem with the way its filled

<nainar> ... borken up into L/R side

<alancutter> astearns: Right, we did talk a bit about this yesterday where we're going to tighten up the spec to say in these cases the lines are broken up into separate line boxes

<nainar> Tav: yes

<alancutter> .. and are placed in the roder determined by the writing mode

<nainar> Tav: yeah i agree with you

<alancutter> .. probably not what anyone would want to do.

<nainar> .. but thats a behaviour you should do

<alancutter> astearns: That's my expectation.

<nainar> .. next thing - fill sequential..

<alancutter> AmeliaBR: I agree that it's not ideal especially when fitting text to an SVG shape

<alancutter> .. one suggestion: add a property that by default is the behaviour ... continue on in a straight line

<alancutter> .. stand across the line and put text in that or .. interruption ...

<alancutter> ... The wrap flow property has different applications and different values that can control wrapping outside a solution region

<alancutter> .. here we're talking about an arbitrary shape.

<nainar> astearns: already wrap flow max and min

<nainar> .. you are correct there is something called wrap flow fill - we can add that you are correct

<nainar> astearns: sure

<alancutter> Tav: I don't see that as high priority but something maybe for the future.

<alancutter> AmeliaBR: Couldn't be the same wrap flow property, it's the difference between shape-inside and shape-outside.

<alancutter> .. talking here about what happens inside a shape inside propertty.

<alancutter> .. it would be parrallel ..

<alancutter> .. as long as there's a clearly defined default behaviour.

<nainar> astearns: i see you rpoint - we dont have the max and min for the shape inside - can be added

<nainar> Tav: moving on - next topic - q how to fill sequentail into multiple shape

<alancutter> Tav: this was something in SVG 1.2

<alancutter> .. I would like to be able to preserve that.

<alancutter> .. At first CSS regions seems like a solution but I tried sitting down to mock up something but couldn't.

<alancutter> .. The easiest way seems like have a shape inside and a list of URL references.

<alancutter> .. You fill the first shape and if there's text left over you fill the next shape.

<nainar> astearns: going by the name flow termiinilogy - create a region with id - doesnt work for svg purposes - what is in the region spec

<nainar> .. row from? wouldnt get the list from ... we have talked of creating differnet region chains before

<nainar> .. have an element say what the next thing in the list is

<nainar> .. css mechanism if that doesnt work

<alancutter> Tav: would a list shape inside and a list work?

<nainar> astearns: i suspect so - more flexibility - css gets order from document order cant change

<alancutter> fantasai: You can use order height.

<nainar> astearns: took that out

<alancutter> AmeliaBR: The main difference is CSS regions assume there are elements in the document that provide ...

<alancutter> ... While in SVG the shape wouldn't necessarily be text containers.

<alancutter> ... Is there any objection to expanding shape-inside and should it be SVG specific or welcome in CSS shapes in general?

<alancutter> ... would not be the union but you spill across....

<nainar> astearns: i think if you are going to come up with a new mechansm for a region chain - should be svg specific - rejected ways of constructing region chains in svg

<alancutter> Tav: We would just define SVG shape inside syntax for SVG purposes.

<nainar> astearns: i think so - that would be right way to start - merge later

<alancutter> Tav: Okay.

<alancutter> .. Same thing for shape-outside

<nainar> astearns: the shape outside - might be better to converge with how exclusions are created in css - nothing new needed to be added for svg

<alancutter> Tav: I can take a look at that.

<alancutter> shepazu: Is it tha case that an implicit

<alancutter> .. if you have a class on an element or selector ... you had one or several text elements

<alancutter> .. you used the wrap selector it would fill them sequentially in document order?

<nainar> Tav: one text elemtn taht has all text

<alancutter> shepazu: What about there regions?

<nainar> Tav: different regions are properties within that element - referenced in the region

<alancutter> shepazu: I see okay.

<nainar> Tav: ok.. the final item in the section

<alancutter> .. In that case could the list be generated by the shape inside the elemn .. let's talk later.

<nainar> .. how is the first glyph positioned and aligned - easiest thing is considering the embox? height

<nainar> .. fit it against whatever edge you have

<nainar> .. what if line-heoght of 2

<nainar> .. extend the box up and down - thats the box up against the edge

<nainar> .. nowhere in css a spec

<nainar> Tav: understand what im asking?

<alancutter> astearns: Catching up. This is fig 13?

<nainar> Tav: fig 13 - css inline spec

<nainar> .. some gray boxes, assume they wouldnt be existant in our text wrapping - shape margin/padding at edge

<alancutter> fantasai: I think it's an alternate way of thinking about it, it's equivalent.

<nainar> astearns: diag is misleading boxes dont exist outline exist

<alancutter> Tav: I understand that.

<alancutter> .. what part, o voting.

<alancutter> .. assuming V is giving the edge of the shape, how close does the o get to the v?

<nainar> astearns: entire height of the line-box

<nainar> ...as soon as any of it collides - it stops

<alancutter> Tav: Okay, I didn't see where that was specced in CSS?

<nainar> .. check and make sure

<nainar> .. certainly line height - make clear in spec

<nainar> .. working same way as floats - shape had been replaced by 1 px tall floats how line box would fit against floats

<alancutter> Tav: Okay. We can go back to baseline issues.

<alancutter> .. Section two. Let's talk about dominant baseline.

<alancutter> .. It shows the existing values of dominant baseline in SVG and tests what different browsers are doing.

<alancutter> .. The SVG dominant baseline is based on ? there's use script ... text before edge.

<alancutter> .. I'm not worried about losing use script, I didn't test other browsers.

<alancutter> .. Then there's reset size that has a purpose that maybe CSS ... it's not needed.

<alancutter> .. Is it possible to get id graphic and add it to CSS inline spec?

<nainar> AmeliaBR: it might be worth mentioning middle is in css inline not for dominant baseline

<nainar> .. for alignment baseline - as synonym for text top and text bottom

<nainar> .. for svg content - same can be done for dominant baseline

<nainar> .. also in most forms equal to ext after edge

<nainar> .. can also be added in a fall back synonym for fallback svg synonym

<alancutter> fantasai: the list of baseline values that are in the spec are trimmed down, we have an open issue to check what's acutally needed.

<nainar> Tav: in fonts - the baseline table

<alancutter> fantasai: Less clealr what middle means.

<alancutter> Tav: It's half of the x height.

<nainar> AmeliaBR: middle is very useful in svg - things look nicely in lower case text - center is good for upper case ideographical texts

<alancutter> fantasai: Okay.

<alancutter> ed: I have a question about flow regions, is there a way to get a callback for when a flow region is full?

<nainar> astearns: yes

<alancutter> .. to generate additional regions in script?

<nainar> astearns: in the region specification - specified there

<nainar> Tav: it woudl be great to get those two added

<nainar> .. 2.1.3 is baseline table

<nainar> .. svg 1.1 xll - on which svg 1.1 i derived

<nainar> the baseline table changes when baseline font changes

<alancutter> .. looking at CSS inline spec it's not clear what expected behavoir is.

<alancutter> .. tested browsers don't follow this.

<nainar> ... browser dont implement - follow - behaviour in svg 1.1 xll

<nainar> .. change font size hanging glyphs hang from same point - alphabetic scripts - would be positioned along alphabetic baseline

<alancutter> fantasai: We're not doing that and that's an intentional change

<alancutter> .. if we need a value that preserves baseline table.

<alancutter> .. You have a bunch of small text and text twice as big.

<alancutter> It doesnt' make sense to have hanging baseline hand down.

<alancutter> .. makes sense to reset instead.

<nainar> Tav: i was thinking about where it makes sense - make font 10% bigger to emphasize

<alancutter> fantasai: Alright.

<nainar> .. only a problem if mixing script - strange to have baseline shift

<alancutter> fantasai: Would be strange to have it not shift.

<alancutter> fantasai: Let me draw it.

<BradK> Draw on WebEx whiteboard?

<alancutter> AmeliaBR: Related is to have CSS inline .. domainant baseline property.

<alancutter> .. define dominant baseline that sets layout grid .. is not layout grid until set to explicit value.

<alancutter> .. the fact that dominant baseline is inherit by default

<alancutter> .. tab's issue .. you're always calculating it ...

<nainar> fantasai: dominant baseline property inherits

<nainar> .. baseline doesnt..

<nainar> small text big text in middle

<nainar> .. take text to align to hanging baseline

<nainar> .. fine if same size here - if same size here - expect it to go here

<nainar> .. off s=center - shift to bigger size

<nainar> .. stuff of same size align togethere

<nainar> .. thats why we reformat baseline evrytime font changes

<alancutter> Tav: Now do the opposite, make the things smaller.

<nainar> fantasai: <draws>

<nainar> .. vs floating way up here.. weird also

<nainar> .. nesting structure - makes sense for content of same nesting structure should fit same nesting structure

<nainar> .. parallel structure floats together

<nainar> .. when nexting - each unit of text consistent with itself..

<nainar> thats why reformat baseline table .. when font changes

<nainar> ... mixed content aligns to single unit with respect to text

<alancutter> Tav: I'm not sure I would expact that, if I had handing glyphs in the ABC I would expcet the smaller text to match the ABC.

<nainar> fantasai: if you asked it to attach itself to a nesting element

<nainar> .. if this is a sibling of that and the alignment is a sibling of the other

<nainar> .. if this is a parent element with text inside it

<nainar> .. then that intermediary element - will reset base element for all its kids

<nainar> .. if you arent inside here use parent inline baseline table

<alancutter> SteveZ: So the differenc arises when I have an element that is inside and have a hanging text in it.

<alancutter> .. The small hanging text goes to the top the alphabetic text ... it's all going to be smaller and the alphabetic will all be at the bottom or all at the top.

<nainar> fantasai: no actually that is not what happens

<nainar> .. not about what element comes first if you decide you have a quote

<nainar> inside a p you have a quote with text in diff language

<nainar> if the quote is sized differently - fit inconsistent size

<alancutter> Tav: That's what reset size value is supposed to do.

<nainar> fantasai: we reset by default - usually what you want

<alancutter> SteveZ: We don't have a survey that says what you want.

<alancutter> .. I think the point is that what the default value for resize is it's clear there's usecases that want to avoid resizing or explicitly do resizing.

<alancutter> .. We could have a preserve value so that it doesn't change.

<alancutter> .. That's just changing teh default.

<nainar> fantasai: i mean if we look at single script - super/sub script

<nainar> teh script is not floating in line - in consistent position - i would expect similar structures to have same behaviour..

<nainar> no one has shown me a case where you want preserve behaviour

<nainar> .. love to see examples outisde of spec examples

<alancutter> Tav: Maybe it's not significant, it is a change in behaviour from SVG1.1 though.

<nainar> fantasai: i mean if svg needs behaviour for compat....

<alancutter> Tav: Maybe it is not needed. We still need to mention change in behaviour.

<nainar> astearns: so.. is that about as far as we will get on this one

<alancutter> astearns: Let's take a 15 minute break.

<astearns> will resume momentarily, but I don't want to cut off a side conversation about baselines

<nainar> Starting up agin

<alancutter> astearns: Let's get started again.

<BradK> Ready

<nainar> astearns: tav you ahve a couple more issues

<nainar> .. ?

<Tav> http://tavmjong.free.fr/SVG/TEXT_SYDNEY_2016/

<alancutter> Tav: Okay the next issue: auto values for text align.

<alancutter> .. No text orientation.

<alancutter> .. SVG has vertical values because there's adobe content whose output can rotate the glyphs.

<alancutter> .. The default baseline is alphabetic, in SVG1.1 the alignment baseline for vertical text was always central.

<alancutter> .. Is is going to cause text from old Adobe products to shift a bit when there's text orientation 90 degrees.

<nainar> fantasai: so, we should fix this by defininng that svg origin for coordinaes isnt changed by values from text orientation

<nainar> .. while dominatnat baseline may change

<nainar> .. auto value of baesline may change

<nainar> .. also causing svg to recoginze that orgin point for coordinates doesnt change

<alancutter> Tav: Okay so that would be in the CSS, would take care of that.

<nainar> .. i think that would end up being a change to online spec

<nainar> .. auto values that refernces auto mode - will also have this magic

<alancutter> Tav: Okay that sounds good.

<nainar> .. where coordiante system doesnt change

<alancutter> Tav: The nex issue is default values.

<alancutter> .. Default values for mathematical values.

<alancutter> .. There is a default value of .6em.

<alancutter> .. Might be useful for there to be a suggested value for mathematical values.

<alancutter> .. Firefox uses ? for the baseline which is not correct.

<nainar> heycam: easiest thing to get at.. nobody uses one

<nainar> heycam: had some discussions in houdid over weekend - exposing baseline to script

<nainar> .. didnt want to expose guesses - recollection correct?

<alancutter> astearns: We want to expose what is available for the font and the baseline but browsers need some heuristics.

<alancutter> .. It'd be nice to have standard heuristics so things don't jump around between browsers.

<nainar> SteveZ: a little bit more subtle than that

<nainar> .. come up with V1 for Houdini api

<fantasai> Tav -- https://hg.csswg.org/drafts/diff/6384ffddc849/css-inline/Overview.bs ?

<nainar> .. restructed to ideographic or alphabetic

<nainar> .. fairly reliably expect - come up with reliable heuristics - expose in future version of houdini

<nainar> .. dont start with a hard problem to solve

<nainar> .. havent specced good way to give that heiuristic yet

<alancutter> Tav: It could be possible to measure these values from a font.

<alancutter> .. Some fonts might be difficult because they only have ?.

<alancutter> .. The mathematical fonts would use the minus character.

<nainar> AmeliaBR: not sure the original svg spec had a sentence that if the exact value wasnt available UA should synthesize appropriate heuristic

<nainar> .. one option is to kep vague opening - vendors? choose to apply a fraction of em/ex

<nainar> .. or translate the glyph that way..

<nainar> .. other option is to give explicit easy to calcuate heuristic

<nainar> .. how do you expose data to script and houdini

<alancutter> SteveZ: One of the action items for inline spec is to come up with standard heuristics.

<alancutter> .. This is for interoperability, if things are different everywhere people will be unhappy.

<alancutter> .. Need to gather data for determining these heuristics.

<nainar> Tav: chicken and egg problem no one uses it

<alancutter> .. The same issue is for hebrew which is topaligned, most fonts don't have reliable values except for alphabetic and emba(?)

<nainar> astearns: specially in the case of Indic - font worked well enough

<nainar> .. everyone uses it

<nainar> .. we could either have heuristics that every browser must interopablly implement

<nainar> .. or we could allow browsers to implement better heuristics

<alancutter> SteveZ: Why don't we wait tfor data before deciding?

<nainar> astearns: that sounds good

<alancutter> Tav: That concludes my issue.

<nainar> astearns: thank you.. lets see

<nainar> Next top: css sizing

<nainar> gregwhitworth: covered yesterday

<alancutter> astearns: How about CSS alignment?

<nainar> astearns: css alignment?

<nainar> gregwhitworth: ilika?

<alancutter> fantasai: I don't have anything for that.

<nainar> fantasai: nothing to add

<alancutter> astearns: We can go to afternoon topics: dbaron's conflicting values in mask shorthand.

<nainar> Next topic: conflicting auto values in mask shorthand

<astearns> https://lists.w3.org/Archives/Public/public-fx/2015OctDec/0021.html

<alancutter> dbaron: mask properties do something we said we wouldn't do again.

<alancutter> .. I suspect... let me get the spec.

<dbaron> https://drafts.fxtf.org/css-masking-1/#masking

<alancutter> .. The basic problem is the mask's position section (chapter 7)

<alancutter> .. has a bunch of properties analogue to background properties and a bunch of new properties.

<alancutter> .. one you have these values.. two have an initial value of auto.

<nainar> .. makes parsing shorthand painful

<nainar> .... change mask shorthand to anything that is not value of other properties

<nainar> .. q1: constrained by compatability: not do it at this point

<alancutter> heycam: We might be the only one that do mask mode.

<alancutter> .. extending mask mode and mask properties might be two separate things.

<alancutter> .. We should be safe in renaming the initial values, even if people use mask mode they probably don't specify the initial values.

<nainar> dbaron: so does it anyone implement mask mode? looking at apple and edge and chromium folks

<nainar> .. less looking at chromium

<nainar> eae: dont implement mask mode

<alancutter> eae: We do not implement.

<alancutter> heycam: WebKit does not implement it?

<alancutter> .. Gecko has patches on nightly but not on other channels.

<nainar> dbaron: mask mode was done a year ago - separatly from other properties and is shipping

<nainar> astearns: are you concerned with existing content

<nainar> .. ok with getting other values

<alancutter> astearns: Mask mode should not have a value called auto?

<nainar> dbaron: mask mode is part of mask shorthand

<nainar> .. im pretty sure cjs patch added a mask property

<alancutter> heycam: I would be pretty surprised if we couldn't change the initial value names.

<nainar> dbaron: question - intial value for this property that isnt auto

<alancutter> heycam: This is the value that means...

<alancutter> astearns: either luminance or...

<AmeliaBR> "auto" means luminance for <mask>, alpha for <image>

<alancutter> heycam: or alpha depending on whether we're referencing an SVG ? or not?

<nainar> dbaron: yeah it really is a value we could auto - doesnt belong in shorthand where it also has value auto

<alancutter> astearns: It's better to change this than the mask-size property as that's following background-size.

<alancutter> dbaron: Correct.

<nainar> dbaron: webkit implements...

<nainar> AmeliaBR: normal acceptable synonym to auto

<alancutter> dbaron: Webkit implements a buch of these but not the mode property.

<nainar> dbaron: check that there isnt a normal in these other properties

<alancutter> heycam: It looks like the property got renamed at some point. when we shipped it it was called mask-type.

<nainar> dbaron: the spec has both mask-mode and mask-type

<alancutter> .. Now we have mask-mode as well.

<nainar> .. in S 9.2 has a mask-type with values luminace and alpha

<nainar> .. in S 7.1 mask-mode has values luminance and alpha

<alancutter> AmeliaBR: The different is make type allies on the mask element and mask mode applies on the element you're masking.

<nainar> fantasai:

<alancutter> .. We probably don't need both.

<nainar> fantasai: makes a lot of sense - masktype was for backwards compat

<nainar> .. otherwise could give it a different name

<alancutter> AmeliaBR: It's something requestied of SVG a lot, possible introduced in SVG1.2 and wasn't in SVG1.1.

<nainar> heycam: seems like it is safe to rename

<alancutter> astearns: Shall we resolve to fix this in some unknown feature solution?

<nainar> dbaron: name sooner rather than later - ned to ship this

<nainar> .. other havent implemented mask-mode

<alancutter> shepazu: Do you have a suggestion?

<nainar> dbaron: normal works, by type or by-image?

<nainar> .. or something like that

<alancutter> AmeliaBR: If you're going to keep mask type then mask-mode should accound for the mask element itself might have a preference?

<alancutter> .. Tthe logical would be something like use source or use element.

<fantasai> match-source?

<fantasai> like match-parent?

<alancutter> .. If it's an image use alpha.

<alancutter> .. If they both exist then the default value of mask-mode is to use the mask type of the mask element.

<nainar> astearns: in eg 9 it shows how you would use mask-mode to override mask-type

<nainar> .. not just a mistake of realizing the other was in spec already

<alancutter> fantasai: I think mask type was added because it existed somewhere.

<nainar> birtles: i might have added it

<alancutter> AmeliaBR: It definitely used to have a default override.

<alancutter> .. The wording of it, if using a word other than auto should use a word defined in the source.

<nainar> birtles: added both properties - added mask0type first as authors wanted to specify..

<nainar> later added mask-mode..

<nainar> dont need mask-type

<nainar> .. content should interpret luminance/ alpha values

<nainar> .. introduces complexity

<nainar> .. order by-type source-type makes more sense when referring to iamge

<nainar> image8

<alancutter> fantasai: We could do match source.

<astearns> +1 for match-source

<alancutter> birtles: We probably introduced mask type as an attribute at first and it became a presentation attribute.

<alancutter> .. Probably can drop it.

<nainar> astearns: mask-mode would still need that value

<nainar> .. not a replacement

<nainar> .. likes source-type as a value

RESOLUTION: cahnge auto value of mask-mode to match-source

<nainar> change*

<alancutter> birtles: If we don't drop mask type .. the example is right, it follows the mask type of what it's following but the normative text says to use luminance if referring to an element.

<nainar> astearns: can we put an action on you to update example and investigate that mask-type can be removed

<nainar> dbaron: update normative text

<alancutter> birtles: If we don't need mask type we should just drop it.

<nainar> .. if we dont drop itupdate normative text

<alancutter> astearns: Are we set for that topic then?

<nainar> dbaron: as far as i am concerned

<nainar> Next topic: CSS Transitions and Animations: path and obstacles to CR?

<alancutter> astearns: Next topic: Transitions in animations

<alancutter> birtles: Can we do that after lunch?

<nainar> astearns: after lunch sure after lunch

<nainar> .. start on filters

<Tav> http://tavmjong.free.fr/SVG/FILTERS_SYDNEY_2016/

<nainar> New topic: Filters

<fantasai> ACTION: birtles to Investigate dropping mask-type property [recorded in http://www.w3.org/2016/01/31-css-minutes.html#action12]

<trackbot> Created ACTION-756 - Investigate dropping mask-type property [on Brian Birtles - due 2016-02-10].

<alancutter> Tav: The first part, I want to understand CSS' status, what plans are there to get this to CR?

<alancutter> .. It hasn't been updated since 2014, anyone know what's happening?

<alancutter> .. Anyone working on it?

<nainar> fantasai: who is editor?

<alancutter> Tav: Dirk.

<nainar> ed: im also one of the editors - close to moving to CR

<astearns> (and Dino)

<nainar> ed: there might be a fe

<nainar> few

<alancutter> fantasai: Test cases are a CR issue, not a moving to CR issue.

<alancutter> I'm also one of the editors. Maybe I could push the last three issues along.

<nainar> Tav: that was the first thing

<BradK> I've got to leave. Bye!

<alancutter> dino: Apple would like to see this go forward.

<nainar> trackbot: its been implemented FF has implemented

<trackbot> Sorry, nainar, I don't understand 'trackbot: its been implemented FF has implemented'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.

<alancutter> dbaron: We have a bunch implemented and it's shipped.

<AmeliaBR> Firefox & Edge have shipped, Chromium still uses prefixes

<alancutter> Tav: I think chrome has it for HTML but not SVG.

<alancutter> dino: WebKit is interested in pushing this to CR. I'll take over the editing.

<alancutter> Tav: I have a fliter primitive that I'd like to see added to a level 2.

<nainar> hober: what does that mean

<ed> https://drafts.fxtf.org/filters-2/

<alancutter> Tav: I'd like to see an additional filter primitive but not as part of level 1.

<nainar> dino: sure yeah we have all already agreed that this is what we will push to CR - when you say new primitive

<nainar> .. we not might not necessarily mean a new css short hand right

<alancutter> Tav: Not a shorthand, an actual primitive.

<nainar> .. we have a lot of filter primitives that Apple would like to see in our native apps

<nainar> .. weve held of - waiting for other implementations to catch up

<alancutter> Tav: You'd be interested in level 2?

<alancutter> astearns: There already is a level 2 document.

<nainar> astearns: already a document that is L2

<alancutter> dino: That describes backdrop filters.

<alancutter> .. It's in a limbo where Webkit has a proprietary implementation. There's discussion to move it to a new syntax...

<nainar> Tav: ok so that covers the first item

<AmeliaBR> This email should turn into an issue on Filters 1 spec: https://lists.w3.org/Archives/Public/public-fx/2016JanMar/0020.html

<nainar> .. we (InkScape) have gotten a lot of complaints about uncanned filters

<nainar> .. some of them try to make things look 3d\

<nainar> .. there are a lot of artefacts - this is a result of lighting filters of images using 3 filters/ channel

<nainar> .. get large steps generated by Gaussian blurr

<alancutter> .. there are only 8 bits per channel that causes large steps.

<nainar> .. you can see that what you want is a red line - you get a black line

<nainar> .. tht produces artefacts F 3 shows that where instead of using an internal bump map you use external one

<nainar> .. one of the issues in 22950? all the ranges should be between 0 and 255 or 0 and 1

<nainar> .. in spec if we state between 0 and 1 allow floating point value - more bits to work with

<nainar> .. a quick scan of spec shows that FE filter primitives use 0 to 255 - need to be changed

<nainar> .. idea is to allow more bits basically - to go into these calculations

<nainar> dino: good idea need to investigate how to do it

<alancutter> dino: Sounds like a good idea that needs investigation.

<nainar> .. need to fix it

<alancutter> Tav: So basically you'll take on the job of finding out what's required?

<nainar> astearns: amelia suggested this should be an issue on level 1

<nainar> .. suggested on irc

<alancutter> Tav: That's what I had for filter issues.

<nainar> dino: yes i think you werent here for discussion on colors

<alancutter> .. Can we talk about positions in gradients, we get complaints about banding in gradients.

<nainar> .. we have hardware that supports more colors we would like a way to specify colors and see less banding

<alancutter> Tav: You do dithering or something?

<nainar> dino: actually i was always wondered why we dont have dithering for gradients

<nainar> .. why dont we specify for css gradients (and svg) add noise of dithering to not see banding

<alancutter> Tav: We've gotten complaints about that, people won't use Inkscape because of banding or they use workaround to add the noise themselves.

<nainar> dino: right it would be good if LeaVerou was here - would complaiun about it

<nainar> dino: we have a pretty easy solution - no one has suggested we do it

<alancutter> shepazu: I have a suggestion.

<alancutter> Florian: Is dithering difficult to implement?

<AmeliaBR> I don't think there is anything in the spec that prevents implementations from using dithering

<nainar> dino: on apple platform not easy for us to do

<nainar> .. we will try to find a way to do it

<alancutter> Tav: We rely on a library and we're thinking of adding it to the library.

<alancutter> Tav: What would be a way forward for dealing with this?

<nainar> dino: someone should make a proposal to the WW stylist or i mean .. then we can have the discussion on how to add it to gradient syntax

<nainar> .. implementation should od it by default

<nainar> .. there will be cases where an author wants dithering - css gradients are using it to checker gradient effects

<nainar> .. in a gradient

<nainar> dino: s/checkerboard/stripy lines

<alancutter> Tav: How do you do checker boards? Oh lots of stops I see.

<alancutter> AmeliaBR: It's already an issue whether implementations alias or not before you get to dithering comes in.

<alancutter> .. Some implementations don't alias the edges of vertical/diagonal stripes.

<alancutter> .. can create fuzzy edges on ... stripes.

<alancutter> .. There's already a variety of implementations.

<nainar> Florian: as for dithering breaking these use cases - do the dithering carefully

<nainar> .. can do it in a way that doesnt break it..

<alancutter> Tav: Did that use enough time?

<nainar> dino: so who is going to make this proposal, do you want to make it Tav?

<alancutter> Tav: I could make the proposal.

<nainar> dino: maybe AmeliaBR wants to make a proposal to control aliasing - use different aliasing

<nainar> .. i dont know

<nainar> dino:

<alancutter> AmeliaBR: Talking about having a property to allow author control or spec guidance for browsers?

<alancutter> .. I'm looking towards making colours as smooth as possible, use something else for stripes.

<nainar> dino: ok

<alancutter> astearns: On to the next thing, we have 30m before lunch.

<stakagi> https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Investigation_of_APIs_for_Level_of_detail

<nainar> New topic: Investigation about JS API for realizing Level of Details

<alancutter> astearns: JS API for realising level of details?

<alancutter> stakagi: Please see this wiki.

<alancutter> .. In response to last discussion ... next chapter this assumes content for level of detail.

<alancutter> .. This investigation assumes .. it's a characteristic that sources are embedded .. our sounces interacte with geographical systems.

<alancutter> .. must be documented by document object model.

<heycam> stakagi quotes from the wiki page: "The typical form of the contents which this investigation assumes is as follows. They are the hierarchical contents by which tiling was performed for each level of a detail. It is characteristic that each resources are embedded using iframe. It is because our usecase is interactive geographic information system, so graphics must be operated by DOM."

<alancutter> .. CSSOM build modules and CSS device adaption module 1.

<alancutter> .. Next chapter investigates panning or zooming action.

<alancutter> .. As CSSOM view shows there are two kinds of zooms, page zoom and pinch zoom.

<alancutter> .. Each browser implements natively.

<alancutter> .. I find CSS device adaptation has called pinch zoom and maginifying glass type zoom.

<alancutter> .. Page zoom is resize event where it has an issue.

<alancutter> .. The issue describes .. pinch zoom picture defines scroll, they also have issues. For scroll there's a scroll event.

<alancutter> .. APIs for zoom .. is next API. One is page zoom there's device pixel ratio where there's also an issue, Pinch zoom also has issue.

<nainar> .. there is device pixel ratio - there is also issues - and pinch zoom has also issue

<alancutter> .. <Reading wiki>

<alancutter> .. <Reading "The issues on existing APIs" section>

<alancutter> .. <Reading "Points in question" section>

<alancutter> .. That is my investigation of level of detail APIs.

<nainar> astearns: thank you for the investiagtion - useful info

<nainar> .. sounds like something that should go into viewport work that we are going to do

<alancutter> Florian: As a co editor of spec of that I agree there is a lot of editorial work needed to clarify the visual viewport.

<alancutter> .. Having rewritten and clarified what the various viewpoints are gives us the various types of zooming.

<alancutter> .. For all the points you made about this I agree it's been a matter of prioritisation.

<alancutter> .. One thing I disagree on is about transform.

<nainar> .. maybe a discusion would change my mind if transform was out of scope

<alancutter> .. Maybe discussion is to be had but I think this is out of scope for transform.

<nainar> .. had many side list offline discussion about what should happen to spec - agree to editorial problem

<alancutter> .. I think that what it currently defines is the right behaviour but it should define more things.

<alancutter> .. The problem has been having the time to work on it.

<nainar> .. how to make that actually happen - everyone involved in that spec agrees to the problem

<alancutter> .. I want to but have other things to do first.

<alancutter> .. Matt from Microsoft has been added as a coeditor.

<alancutter> .. I would be surprised if he disagrees but probably is busy.

<alancutter> .. Same for Rune from Opera.

<alancutter> .. Except for transforms I agree with everything you said.

<nainar> astearns: at the very least we shoudl take this report as an issue (several) things to work on

<nainar> .. in that spec

<alancutter> Florian: I would rather add one issue that points to the entire report instead of slicing and possibly missing things.

<alancutter> astearns: It records that its' something that needs looking at at some point in time.

<alancutter> Florian: There is substantial overlap with an article and what he is saying.

<alancutter> .. We can have both issues and both reports, they're asking for the same changes to the spec.

<nainar> astearns: i recall that we talked about having a new document that defined viewport better

<alancutter> Florian: The document we talked about assigned to Peter, Rossen and I is fuzzy about the viewport.

<alancutter> .. It's the thing around the root.

<alancutter> .. We may find that it's the missing thing or we won't it's not clear.

<alancutter> .. Once the other spec starts existing maybe some pieces can shift between the two.

<nainar> astearns: is there anything you wanted to talk about on this topic?

<nainar> stakagi: can i help your work?

<nainar> <points to Florian>

<alancutter> Florian: I want to answer yes but I'm not sure how.

<alancutter> .. I would like detailed issues about .. but before that I think we'd need a rewrite to get consistent vocabulary.

<alancutter> .. Even though teh end result is correct. Maybe I'll add an issue in addition to the report that there should be an API for this.

<alancutter> .. We could file an issue about the vocabulary, it needs a general overhaul.

<alancutter> .. I have very little or no time to work on this.

<alancutter> .. Thanks for the offer of help.

<nainar> astearns: alright then , break for lunch - come back for one remaining agenda item

<alancutter> fantasai: I'm doing a talk on best practices on CSS, if you have anything you want to convey to the web authors let me know.

<alancutter> fantasai: "Use shorthands to reset things because they will reset all the things"

<nainar> dino: dont use index over 999, anything below that is fine

<nainar> dino: use SASS

<franremy_> fantasai: use grid or flex not floats for grids

<nainar> astearns: Let's lunch

<alancutter> dino: Best practices for CSS: Use React, use inline styles on every element. (probably joking)

<alancutter> eae: Let's come back from lunch at 1:45PM.

<astearns> starting back up soon

<ewilligers> ScribeNick: ewilligers,alancutter

<alancutter> astearns: The last item is a discussion of transitions and animations.

<alancutter> astearns: Path and obsticles to CR.

<alancutter> dbaron: I'm hoping I'll get time to edit the path spec. It's hard to make promises.

<alancutter> .. If someone wants to help that will be useful but I'll try to make progress.

<ewilligers> bbirtles: Working on css animations, made some edits

<alancutter> astearns: Does anyone want to have a deeper discussion about the transitions to CR?

<AmeliaBR_> Can anyway say what the obstacles are?

<alancutter> astearns: So we have an update that Simon wanted to give.

<dbaron> (er, that should have been path spec / transitions spec)

<zcorpan> https://github.com/whatwg/compat/issues/19

<alancutter> skk: In the geometry spec there's an interface for matrices. I've made some edits to make it incompatible with CSS Matrix.

<alancutter> zcorpan: This is FYI, please review.

<alancutter> zcorpan: In particular that I didn't break compat.

<alancutter> .. As part of this a few methods were dropped because they were the same as some other methods.

<alancutter> .. Please review if there's a use case for them and we should add them back.

<astearns> https://drafts.fxtf.org/geometry/#changes

<alancutter> heycam: I'll compare it with SVG Matrix.

<alancutter> astearns: Can we get a summary of the scrolling discussion?

<ewilligers> astearns: the last thing - I am interested in what happened during breakout

<alancutter> shane: The full minutes are available on public-fx.

<alancutter> .. We talked about scroll triggered animations and paralax ideas that were brought to tpac before last.

<alancutter> .. There are potential problems with animations retriggering themselves but overall there's a fair amount of interest across browsers.

<alancutter> .. to get this area specified.

<zcorpan> csswg-drafts

<alancutter> .. Next steps is dino will ...

<dino> ... write an explainer document

<alancutter> .. We will be very interested in people asking questions, making suggestions and bashing on it.

<ewilligers> astearns: That exhausts agenda

<alancutter> astearns: We are ajourned but we have time to keep working together.

<alancutter> .. And there is the event tonight.

<ewilligers> shans: WE have 5 talks scheduled: best practics,

<ewilligers> css grid, houdini, round displays, new features in svg 2

<alancutter> .. There are 180 developers of all stripes signed up to show.

<alancutter> .. Please come tonight and show who you are, it's an excellent opportunity to meet the people you're building features for. Please come.

<alancutter> shepazu: There aren't many guns in Australia right?

<ewilligers> shans: In this room at 6:30

<alancutter> astearns: Adjourned.

<alancutter> astearns: <Hammer>

<fantasai> Discussing word-break stuff we need to add for the future...

<Florian> [ [normal | keep-all] || break-spaces ] | break-all

<fantasai> normal | keep-all | break-all | break-spaces | keep-words | break-words | magic-evil-value

<fantasai> keep-all keeps spaces + cjk + letters

<fantasai> break-words keeps spaces breaks cjk + letters (probably not needed)

<fantasai> keep-words keeps cjk + letters, breaks spaces

<fantasai> etc.

<fantasai> okay, I think yours makes more sense

<fantasai> except keep-all + break-spaces is kinda weird

<fantasai> normal | break-spaces | break-all | keep-all | keep-letters

<fantasai> otherwise it's

<fantasai> normal | break-spaces | break-all | keep-all && break-spaces

<fantasai> ?

<fantasai> "I think “except” is sufficently expresed by a space" -- florian

<Florian> s/^"/“/ s/"$/”/

<Florian> /undo

<Florian> normal | break-spaces | break-all | keep-all-but-spaces

<Florian> normal | break-spaces | break-all | keep-all | keep-all-but-spaces

<tripu> fantasai, thanks for those details :)

<JonathanNeal_> A question about https://www.w3.org/TR/css3-background/#special-backgrounds. Why is it that the spec recommends authors specify the canvas background for the BODY element rather than the HTML element?

<JonathanNeal_> All descriptions of the document canvas appear to match <html>. “The document canvas is the infinite surface over which the document is rendered”, “CSS propagates the background of the root element”, “For documents whose root element is an HTML element”. And later it describes how body backgrounds should push up to the root element “If the

<JonathanNeal_> computed value of ‘background-image’ on the root element is ‘none’ and its ‘background-color’ is ‘transparent’ user agents must instead propagate the computed values of the background properties from that element's first HTML BODY.”

<Ms2ger> JonathanNeal_, maybe that worked better in NN2?

<JonathanNeal_> @Ms2ger, run roh, did someone forget to write the actual reason down?

<Ms2ger> You could check if the note is present in CSS1 :)

<JonathanNeal_> @Ms2ger, slightly troubling “HTML extensions have set a precedent for the second question: attributes on the 'BODY' element set the background of the whole canvas... Until other means of addressing the canvas become available, it is recommended that canvas properties are set on the 'BODY' element.” https://www.w3.org/TR/REC-CSS1/#the-canvas

<gsnedders> JonathanNeal_: I presume that means body@bgcolor etc.?

<JonathanNeal_> gsnedders: seems like it. I know I followed a pattern of targeting <body> until I hit a snag and then targetted <html>, and eventually I stopped waiting for something to break and started targetting <html> to begin with.

<JonathanNeal_> I’m hitting up whatwg as well. I keep guessing and seems like you could too. Maybe someone there will have a non-guess answer.

<glazou> dauwhe: ping

<dauwhe> glazou: pong

<gsnedders> Was any decision made about next F2F location?

<gsnedders> I don't see anything in logs looking quickly?

<astearns> gsnedders: dauwhe: no decision made. We were waiting on a decision on San Diego, and got it last night: No. So we're now looking for a SF host

<gsnedders> astearns: any idea of when someone will volunteer to host? :P

<astearns> gsnedders: sorry, no. I'd hoped to have it all figured out by now

<gsnedders> (I presume you mean SF Bay Area rather than SF specifically.)|

<shane> astearns: I think we'd tentatively volunteered?

<gsnedders> for MV?

<astearns> For SF, perhaps splitting costs with Mozilla? Time to figure out what's possible

<shane> oops^

<gsnedders> Last I knew it was waiting on W3C staff.

<astearns> plinss: "WARNING: mysqli_connect(): (08004/1040): Too many connections" on drafts.csswg.org

<dauwhe> plinss: still seeing that now

<astearns> hmm - trying to remember whether plinss might still be diving somewhere. I think he said he was going home after the Sydney meeting

<plinss> I’m home

<astearns> pls fix srvr

<plinss> ? looks ok to me

<plinss> still seeing issues?

<astearns> argh, sorry. I thought I had reloaded. Looks OK now

<plinss> k

<TabAtkins> fantasai: Thinking about the iframe auto-resize. It seems like height:max-content is the way to go. Should I put this in Sizing, I guess? As some weird appendix or something? And maybe the MQ behavior (making the iframe contents use the parent window's height for MQs) in Mediaqueries?

<zcorpan> TabAtkins: re http://blog.innerht.ml/cross-origin-css-attacks-revisited-feat-utf-16/ i wonder if we should ignore the environment encoding if it's a utf-16 encoding, as another defence-in-depth. or just ban utf-16 for CSS completely

<Ms2ger> Florian, hi!

<Florian> Hi

<Florian> Ms2ger: may I be of service?

<Ms2ger> Wanna do a few mindless unused-code-removal reviews in csswg-test? :)

<Florian> sure.

<Ms2ger> That's the spirit :)

<Ms2ger> First three at https://github.com/w3c/csswg-test/pulls/Ms2ger

<Ms2ger> Though the next three after that should be simple too

<Florian> #1040 and #1041 have errors with travis

<Ms2ger> Yeah, they all do

<Ms2ger> Doesn't seem like plinss has fixed the server issues

<Florian> Does travis ever usefully fail in this project? I've only ever got false positives, never a real one.

<Ms2ger> The build only really gives warnings, not errors

<Ms2ger> So the output can be useful; the pass/fail status not so much

<Ms2ger> I kinda want to make warnings fatal, but that'll need some more work to eliminate the existing ones

<Florian> so why did these support/ directories end up there? Someone committed the output of a build script?

<Ms2ger> These keep getting copied around from the css1 test suite, afaict

<Ms2ger> [sic]

<Florian> Seem harmless to me to delete, but I wouldn't want to trample on someone's policy that because of tool blah, we actually need to copy these around.

<Florian> Know of anything like this?

<Ms2ger> I don't think there's anything like that

<Ms2ger> I'm sure someone will shout at me if it does cause issues :)

<Florian> or at me, since I just merged these 3.

<Ms2ger> Feel free to redirect all blame to me :)

<Florian> I'll absorb enough blame myself to understand what went wrong, and if there's any left over, you'll get it

<Ms2ger> Great :)

<Florian> #1039 seems sensible as well. Merged.

<Florian> same for #1038

<Florian> 1037 seems reasonable as well, but unline 1040 1041 1042 where the files weren't even used, here they are. So this one might be intentional

<Florian> (for tooling reasons or something)

<Florian> ccing plinss on this, and I will merge if he doesn't come up with a reason not to

<Florian> Ms2ger: 1011 seems reasonable as well, but isn't this one of these auto-sync directories from mozilla, and regardless of what we delete it will come back?

<Ms2ger> Looking

<Ms2ger> No, that's vendor-imports/mozilla/

<Florian> for this commit: https://github.com/Ms2ger/csswg-test/commit/1756765d0de6140245ffb4efb9887cb1f2e02e37

<Florian> do you have a list of which file is which? They are all renamed and not bitwise identical, so checking that you didn't miss anything is laborious

<Florian> Ms2ger: ^

<Ms2ger> Hrm

<Ms2ger> I think I may have made a list...

<Ms2ger> But it doesn't seem like I kept it, sorry

<Florian> oh, it looks like the names aren't that mangled, so checking is actually not that bad

<Ms2ger> css21/generated-content/before-after-display-types-001.xht for work-in-progress/mozilla/reftests/generated-content/display-types-01.xht

<Florian> right

<Ms2ger> And it seems like they just got before-after

<Florian> (and dropped a 0)

<Ms2ger> Because it shouldn't be too simple :)

<Florian> :) They're not actually identical.

<Ms2ger> Yeah, I think some -moz- things got lost?

<Florian> yeah, sorta. the moz version of display-types 001 has -moz- prefixed flexbox

<Florian> the other does not have flexbox, with or without prefix.

<Ms2ger> Yet another reason we should've got rid of those files years ago :)

<Florian> this test has no assertion, I am not sure what it is testing, and whether the addition of flexbox to it is of any interest

<Ms2ger> Possibly ":before/:after apply to all display types"?

<Ms2ger> In any case, there should not be flexbox in css21/

<Florian> no, but it isn't a css21 folder, it is work-in-progress/mozilla/reftests/generated-content/

<Florian> this new bit should be a test in the flexbox folder, not in a modified version of a css21 test, that's for sure.

<Ms2ger> Yeah

<Ms2ger> File an issue? I can probably make it happen at some point

<Florian> How would you like that issue to look like? merge the deletion commit, but create an issue saying to recreate the lost bits in a new TC, pointing to the old files?

<Ms2ger> "a standard equivalent to the lost bits", but yeah

<Florian> ARgh. Whoever did this is evil. gratuitous changes in the files making them different, even though they do the same....

<Florian> <body onload="fixupDOM()" my-attr-2="xyz"> -> <body my-attr-2="xyz" onload="fixupDOM()">

<Ms2ger> I think that was fantasai auto-translating html to xml independently from dbaron(?), who put them in w-i-p/

<Florian> Ms2ger: Merged a bunch, filled the issue, left a question for plinss in #1037 and a comment for you in #993.

<Florian> I think that'll do for today

<Ms2ger> Thanks!

<Florian> Ms2ger: Now, may I interest you in these https://github.com/w3c/csswg-test/pulls/frivoal ?

<Florian> :)

<Ms2ger> Eek, css-ui

<Florian> well, someone's gotta do it.

<Florian> Ooops, lost power for a second

<Florian> Ms2ger: what's not to love about css-ui ? :)

<Ms2ger> Having to think about it :)

<Ms2ger> Florian, updated https://github.com/w3c/csswg-test/pull/993

<Florian> Ms2ger: merged

<Ms2ger> Thanks!

<Florian> Ms2ger: css-ui isn't just weird stuff. There's thing that were in 2.1 as well. You know you want to review tests for the cursor property https://github.com/w3c/csswg-test/pull/783

<Florian> (and I'm going to bed)

<Ms2ger> Are you in an unusual timezone?

<Ms2ger> Oh, Japan

<TabAtkins> fantasai: Yo, do you wanna put the .why styling in the TR stylesheet? Just noticed it's not there when I was reading Syntax. ^_^

<TabAtkins> zcorpan: I am completely behind banning utf-16 completely, tho of course I'd have to see usage numbers. I'm happy to do as much limitation as compat allows us to.

<plinss> Ms2ger: I think gnsedders already fixed the travis issue, old PRs based on commits before c017547 will still fail, newer ones should work (or if the old ones are rebased)

<adenilson> Good morning.

<gsnedders> plinss: that should be right

<adenilson> Anyone from MS in this channel?

<gsnedders> plinss: I hope it's right.

<gsnedders> plinss: oh, it'll choke on anything after merging if it has commits that aren't a child of that :\

<gsnedders> plinss: it seems to be keeping up-to-date ultimately though

<gsnedders> maybe we should just add in an ugly hack…

<fantasai> plinss: issues-cr-2016.bsi wasn't generating for css-values-3

<fantasai> er

<fantasai> css-values

<plinss> fantasai: k, will check it out in the morning, thanks for letting me know

<fantasai> plinss: hg.csswg.org is hanging on push

<plinss> fantasai: looking

<plinss> fantasai: server looks ok from what I can see (though behind a restrictive net atm and cant ssh in to see logs)

<fantasai> okay, it's loading now. Mercurial is still hung

<plinss> it was in the middle of a hg convert to git so that may have been holding you up

<fantasai> still hung

<astearns> WebEx took quite a while to initialize for me

<dael> ScribeNick: dael

A value for image renddering to request high quality rendering

<astearns> https://lists.w3.org/Archives/Public/www-style/2016Feb/0016.html

smfr: This started when I impl image rendering in webkit
... We have a behavior where if a image is painted often it goes to a lower quality. THere's no way for the author to opt out for now. There used to be a value for optimize quality, but it's being depricated. There's no replacement to indicate do better than auto
... Amelia posted a follow-up to my message. She suggested smooth but I don't like it because it's not nec. smoothe, it's look good. I'm open to other suggestions

<TabAtkins> The original reason I left this out was because we concluded that browsers would always opt for the highest-quality rendering they could get anyway, and authors have a good chance of trying it on their own powerful laptop and going "performs great, ship it", leaving low-powered devices getting pretty pictures but terrible perf.

astearns: Does this new value mean don't do anything, or is it to improve?

smfr: It's not do special processing, it's use...anaother thing I should say this applied when the image is being scaled usually so there's a scaling facotr...it's telling the UA to use best quality algo.

hober: Becides the aestetics of the old name, is there a reason why not to un-depricate?

<TabAtkins> So I think it's a quality-of-implementation thing. If images often get booted into low-quality unexpectedly, fix that. Detect things better and use higher-quality more often.

astearns: TabAtkins said on IRC why he remembers dropping
... So do we want to have something in CSS that allows safari to avoid this image optimization when that optimization strat isn't optimized.

Rossen: How is this intesecting with source and picture and all the other abilities authors have to optimize quality and payload? isn't that what we should strive for devs to use rather than UA optimize this away?

smfr: It's diff. Those allow the author to supply assests. This is once you have the assert and scale, what algo to use.

Rossen: Gotcha.
... It's when scaling is applied...okay.
... We used to have something similar

<astearns> best-scaling?

Florian: For tab's IRC, even if there was high quality the UA could use it as a hinit. So it could still drop if there was a perf problem. Because there is a risk they could just set it everywhere.

MaRakow: smfr were you saying don't do the proposed smoothe but a different behavior?

<tantek> dael, regrets from me (Tantek) for today

smfr: I'm okay with something like smoothe, I jsut don't like the word

Rossen: We're converging to we need to revive the old prop or have something else.

TabAtkins: What was the obj to what I said? That this is quality of impl issue?

Florian: I pointed out that if we get into a place where authors use it too much, the UA can just use it as a hinit but can eventually do whatever it wants.

TabAtkins: So if you do that the value is the same as auto but if you're in resource constraing prioritize others over this..
... That doesn't seem quite what is being asked for.

Florian: It doesn't seem quite. It's a middle ground.

TabAtkins: smfr what is the opinion on deteecting better?

smfr: We would love to improve everywhere and get rid of low quality scaling. But I'm not sure...on low power we may have performance issues. There is value in the authors saying something is important enough.

TabAtkins: I see value in my headline is the prettyest, prioritize if you can. Something liike that seems valuable.

smfr: We don't havea notion of ranking images. WE just make a choice when we get to an image.

TabAtkins: If we were to add a high quality value, what happens on a low quality device that doesn't have power.

smfr: They could try high wquality and the user gets bad perf or they fallback to auto. I think it's okay for this to be a hint that can be ignored.

<astearns> image-rendering: expensive-when-possible

TabAtkins: I think that's the ssame as what I said on prioirity. I'm fine if it's explicitly said that UA can ignore and use low-quality when needed.

Rossen: I'm not sure this is giving too much. If we'rer saying please do it and there's still room for UA to ignore then this defetes the purpose. I'd rather go back to your first suggestion TabAtkins and let UAs do a better job. Don't put this in the power of users because they'll just use it everywhere. So I'm not in favor of having a property that sometimes works.

TabAtkins: That's why I was thinking prioritization. So spend your limmited resources on this image over everything. So prrioritizing every image is the same as doing none. But if you're judicious it could be useful. but if you're not impl prioritization, there's no value.

MaRakow: I think tis' somewhat interesting, but I think it would be to allow auto to be lower quality. The safe default is high quality scaling. I think being able to have a differentiator would let us improve auto, not have a new higher quality.

TabAtkins: So by default you can degrade more heavily because ahotrs have an escape.

MaRakow: We used to have MS interpolation and didn't see widespread use. So I think it's more intereesting to let us slice the auto rather than a new higher level

TabAtkins: I see that. I see why slicing the semantics of auto more could be worthwhile. Okay.
... I'm fine with accepting. Do we want to take naming to ML?

fantasai: Why don't we reuse SVG names?

TabAtkins: We can. THat's certainly a good suggestion.

fantasai: We should def. accept those names.

ChrisL: If it turns out we need others, though...we should look at those, but we may decide that they don't do enough.

<MaRakow> abuse and/or use :-P

TabAtkins: Right now optimize is mapped to auto, we map it to the new one. Is the SVG good enough that we can use it? We can move to ML

smfr: The crisp edges value here...I suspect no UA impls this and it seems to conjur px from mthin air

ChrisL: I think Batik did it. Adobe for a while did but people abused it.

TabAtkins: moz does.
... I don't know what the imipl does, but it has an effect oother than auto

MaRakow: I think the image in the spec iffrom a wikipedia page.

TabAtkins: Yeah, it's from wikipedia. pixel art scaling thing.

Values and Units

<astearns> https://drafts.csswg.org/css-values-3/issues-cr-2015#issue-1

Sub-Topic: issue 1

<astearns> https://hg.csswg.org/drafts/rev/98da29d1dabb

fantasai: TabAtkins added prose stating that angles when used as a direction must be treated as bearing angles. I wanted to check with the group that this is appropriate.
... Do we want to add this paragraph?

<fantasai> https://drafts.csswg.org/css-values-3/#angles

TabAtkins: Every usage is bearing angles, but should we require it or leave it open to be something different in the future.

Florian: I'm not sure it makes much sense forr vague future, but a note for future authorss not to do this accidently sounds fine.

TabAtkins: Sounds like not an objection, but you're also happy with a non-normative note.
... So objections to it must be bearing angles?
... bearing angles means 0deg is pointing north and positive is counter-clock.

ChrisL: Then e and n need to be in terms of coord system.

TabAtkins: Yeah.
... The few usues of angles in SVG match this, the old oral style sheets match, polar match.

ChrisL: If all existing uses match, that's fine.

TabAtkins: So objections to me requiring that across specs? Or are we okay with spec doing what they need to.

<ChrisL> require is good at this point

fantasai: I think we switch this to a note saying it's a convention in CSS and that will prevent the wrong way.

Florian: I'm not convinced it makes sense to have normative things apply to spec authors.

TabAtkins: It's the same as saying a pixel is a certain lengths. This is saying how angle is use.

fantasai: pixel is the same evrywhere, but angle is sometimes didrection, sometimes rotation, etc. I think it's not quite the same because it can be different. Transverse goes the other direction, is that not a bearing angle?

TabAtkins: So you just said we use angle units as different things. But angles as directions we can give a consistant meaning.

fantasai: It's not 100% clear what's a direction. Obvious hue is unrelated, but transforms I might think of as direction.

Florian: I won't object, but I'd prefer a note.

TabAtkins: We'll go for a note.

Sub-Topic: issue 3

<astearns> https://drafts.csswg.org/css-values-3/#calc-serialize

fantasai: TabAtkins...there was an e-mail saying that the serialization for calc() isn't defined, TabAtkins said he'd write it, he didd, but there's been no review. So would people who care about this please review.

TabAtkins: I did base it off some study, there is one bit missing where if you're going to get clamped, it doesn't go negative. That needs to happen between stpes 1 and 2 of the current algo.

fantasai: The poipnt is, please review and lets come back.

astearns: Any comments right now?

fantasai: I'd be happier publishinig this to CR if there was a positive review from someone other than me and Tab. I was planning on that this month.

sub-topic: issue 5

TabAtkins: I thought we agreed on this as a WG

fantasai: Sorry, I missed that resolution.

sub-topic: issue 10

fantasai: Does anyone impl toggle()?

<gregwhitworth> we don't

fantasai: Apple? MS?
... Do I assume no?

<Bert> (Minor remark on serialization text: The parentheses in "(Terms with a value of zero must be preserved in this summation.)" should probably be removed.)

fantasai: toggle functional notation.

Rossen: We don't impl that.
... Was the question do we or are we planning to?

fantasai: If no one impl currently I think we should push to lvl 4 and wrap up lvl 3.

Rossen: I'm in favor of that. That wouldn't slow us if we want to impl

smfr: webkit doesn't impl

fantasai: Okay. I'll remove it once we have a level 4 draft.

<dbaron> Maybe level 4 would be a delta spec for some period of time?

astearns: Anythinng else on values and units?

fantasai: nope. please review serialization

<astearns> https://lists.w3.org/Archives/Public/www-style/2016Feb/0017.html

TopicL gradient rendering & image-rendering property

astearns: This is something Amelia brought up.

smfr: this ssuggested image rendering should effect gradianets as to iif they show banding or what have you. My reaction was for webkit we don't have the knobs for endering. I'm not sure it makes sense, I'd prefer gradient looks good everywhere.

Florian: I'm not sure just looks good is the point. In different context looks good means different things.

MaRakow: I'd agree with smfr. In general we get more complints about not having support than you would expect.

TabAtkins: The only thign that justifies the switch is if you have perfectly vertical stripes and they don't aling to pixel boundries. BUt that's so low profile...if we can make gradient rendering look good in general we should do that.

Florian: That's the mai one. Also if your stripes or horz or vertical, you don't want the algo to dither your stripes completely.

TabAtkins: That can't happen. Stipes are a solid color region. Dithering is during a gradient region when you're actually ramping the color do you use alog.

ChrisL: It's dithering to avoid mach-banding.

Florian: As we get higher resolution the slightly fuzzy problem gets smaller.

smfr: One consideration, ifour graphics could do high quality but expensive to render, maybe that could be opt-in.

TabAtkins: When that happens, impl can create ridge rendering to support that.

smfr: I don't want image rendering to apply to gradients. So if you sayy pixilated do you turn off.

TabAtkins: Pixilation controls scale...no...i see it. Image rendering is sole scaling quality so technically wouldn't apply to gradients. This can be re-written to apply to image gneration. I don't think anyone can differentite. If they do later we can make the small spec change.

astearns: So the people who have an opinion hear, can you please reply to the thread? It would be good for people participating on the mailing list get that feedback. That we can't do it now and in the future it might not be as much an issue.

<astearns> https://lists.w3.org/Archives/Public/www-style/2016Feb/0034.html

layout containment and overflow

Florian: When you're applying layout containment, but not paint containment, if we do as speced it doesn't work...if you have something overflowing from layout container it can go so far out it causes a scroll bar to appear.
... That scrollbar causes layout problems. We can say layout containment is also paint containment. Or when you have layout overflow it's paint overflow and therefore doesn't have scroollbars
... Do does that sound reasonable? Do people impl this have another way out?

TabAtkins: the correct solution is stop having layout effect scrollbars, but I've been beating that drum for 5 years.

Rossen: In general I would agree layout containment should be stronger than paint continment. So if I was writing those ini priority I would consider layout first for both scrollbars and overflow effectinig other layout.
... So one way out iis to be explicit that for paint layout containment it resolves in paint containment.

Florian: It woroks, but it's not good. So if you're doing layout containment it's not clear you want shadows clipped. THere are cases where it's fine to have overflow, but there are times that it does effect containment.

Rossen: I haven't thought about this too much and we haven't impl so I can't comment.

TabAtkins: We're in the middle of impl. I'll ask our impl what he thinks on it.

Rossen: That would be great.

fantasai: If I recall correctly Moz wouldn't have a problem doing paint contain if you have layout, but I don't know if it's user friendly. It's better than clipping to contained box.

Florian: The only worry...

fantasai: So you're prop 1 is auto clip to contained box and the other is allow visable overflow, but if it overflows the parent scroller you can't see it.

Florian: Yes.

fantasai: Between those two, I'd go for showing more content. That seems to make more sense to me. You're less likely to clip thigns the user wants. And how we handle it in Moz I think that's straightforward to impl. Either would be easy to impl.

Florian: Before we conclude actioning tab to look at his impl is good

action TabAtkins ask his implementor about layout containment and overflow

<trackbot> Created ACTION-757 - Ask his implementor about layout containment and overflow [on Tab Atkins Jr. - due 2016-02-24].

-webkit-user-select

<astearns> https://lists.w3.org/Archives/Public/www-style/2016Feb/0050.html

Florian: User0select is impl all over and with the webkit prefix it's also all over.

Rossen: IE doesn't have it, Edge does.

Florian: It's being impl by other than webkit family of browsers. So a bit like we said about word-break: break-word where if it's needed for compat it sould be in a spec so I'm preposinig that it should be in CSS UI in a compat section.

fantasai: In this case I don't think we do an appendix and put it inline with an actual def. as a short hand or parse time alias. One sentence at the bottom that says UAs may impl, authors MUST NOT and at some point this may be removed. That'll call a lot less attention to it.
... The other one we needed a definition, but in this case it should be one line of normative prose. So the UAa may impl if they feel it's nec for compat, it's not guar. to stay impl.

Florian: In general when something is clearly required for web compat, I'm not sure there's value in may

fantasai: There may be CSS impl not interacting witht he web, like Prince, they have no reason to impl this. An e-book reader may not care.

Florian: This prop isn't impl without a prefix. It may shift some web content once that happens. Here I'm okay with a may

astearns: Objections?

Florian: Additional data, the whatwg is doing this too, but they are happy to drop once we have it.

astearns: I'm happy to have it in our spec. tantek mentioned in IRC that we should spec.

TabAtkins: We should spec it.

smfr: For impl with -weebkit-user-select, how compat is that with the unprefix?

TabAtkins: I don't think we have a different.

Florian: The differences are irrelevent for difference and used for none

smfr: So the spec will say only none or it's a synonim.

Florian: That was my plan.

smfr: I think we have very different behavior for user-select: all

Florian: There were differences on other values that were mentioned in spec. My assesment was this wasn't different enough for compat problems. It wouldn't cause breakage.
... Based on that people can align. If you're finding that the -webkit is different and you need to preserve both, that's something I'd like to know.

smfr: I don't have data. I seem to recall in the past people had discovered imcompatibilities.

Florian: I found differences, but not ones that caused imcompat.

smfr: So UAs other than webkit would you expect them to take all the values?

Florian: I would not. I think syntax level alias is sufficent.

smfr: I'm fine if the other vendors agree.

Florian: Draft doesn't spec webkit, jsut a behavior.

astearns: Should the draft say people may impl t his syntax level alias because webcompat is required for the none value and mention there's no need to have other impl match webkit on the other values.
... Or is that too much detail

Florian: overkill

Rossen: I'd agree.
... Ini general we're impl whatever makes the web work and we don't go into impl everything that's in a webkit prefix if no one is using it.

astearns: smfr are you okay with what's been proposed?

smfr: I guess so. It sounded liike Rossen was arguing it's not a pure syn. and it would make sense to only say the common values.

Rossen: and it would give a way to depricate them.

fantasai: We can do that. We do something simiilar with page-break where the values map to a subset of the break values. If there's only one or two on -webkit that we care about we can say only those are alias and the others invalid.

Florian: I'm not against, but I on't think that's what's being impl. I don't wnat to pend extra work writing what's not being donoe.

Rossen: So specing only the fully interop set makes sense. The perfect eexample is all gregwhitworth work with tables. It's not meant to desc new behavior, it's doc status quo.
... If you spec more you're encouraging interop gap

Florian: So I'll need to test...there's one value only on IE and Edge and I'm not sure if it's alias to -webkit

Rossen: I have to go and check.

smfr: webkit doesn't support contain. Just auto none and all

Florian: Yes, that came from MS. So do they support it thought the prefix.
... I'm in favor to just spec reality. If non-webkit jsut alias I'll spec that. if they only do the restricted set I'll do that.

RESOLUTION: spec some set of -webkit-user-select values

action Florian determine set of -webkit-user-select values to spec

<trackbot> Created ACTION-758 - Determine set of -webkit-user-select values to spec [on Florian Rivoal - due 2016-02-24].

fantasai: Florian may want to come back with his set. We have what's impl and what's needed and we're not sure which set. Rossen is what's needed and Florian is what's impl.

astearns: Even if there's a larger set impl we should only spec it if it's interop.

Florian: I dont think interop is a problem here.
... I can't evaluate if extra values are needed. I take it if other browsers impl them they are. So that's why I want to spec what the browsers do.
... If spec what they do isn't right, some one else needs to decide needed.

<gregwhitworth> sure - I'll take it

fantasai: Can Rossen figure out what's needed for webkit-user-select?

action Rossen figure out what's needed for webkit-user-select

<trackbot> Created ACTION-759 - figure out what's needed for webkit-user-select [on Grego or Rossen Atanassov - due 2016-02-24].

astearns: We are done.

<gregwhitworth> Grego? LOL

<fantasai> s/Grego/Greg/ :)