SV_MEETING_TITLE -- 12 Nov 2013

<dbaron> ScribeNick: dbaron

Box generation and elements as regions

[projector and microphone configuration]

Alan shows http://www.theguardian.com/world?view=mobile

Alan: wanted to describe a few things we're doing with regions
... We're pushing for using regions and named flows in responsive UI designs
... I'm showing a site from the guardian, not using regions at all. Has navigation bar at top, with menu that comes out. Assuming for a landscape tablet display. As you narrow the display, the navigation elements move to the menu.
... Script is putting items that don't fit in the width and moves elements around in the DOM.
... script is a little buggy and janky
... really easy to do by defining navigation elements as belonging to a named flow, two regions: nav bar, and menu
... that's much more performant, and doesn't need script
... Similar thing ,example at http://adobe-webplatform.github.io/regions-adaptive/
... Don't want these buttons to show up on mobile, so at a certain width all the buttons get collected into a named flow and put into a slide-out.
... no script, just a media query that turns on the named flow
... just wanted to introduce these ideas to the group
... In this case it's a region chain of regions all with a particular height (viewport height) so the content is interspersed with images (http://adobe-webplatform.github.io/Demo-for-National-Geographic-Orphan-Elephants/ )
... I've been posting to www-style about how named flows work with overflow:fragments in an attempt to convince people that the issue in regions about box generation should be closed because every box generation mechanism we have defined or proposed for CSS is something regions can participate in.
... The original issue was put into the specification because people wanted to see what the page template proposal that we had only talked about would look like.
... I produced the page template proposal where we can target CSS-generated boxes with region chains.
... I assume we're going to do something similar in future work with this group. Regions works well with that.
... Introduced before and after elements, and introduced overflow:fragments which dbaron ran with and produced an interesting spec; but again, regions works well with overflow:fragments.
... you can take 2 overflow:fragments elements in your document, link with named flow, and have content flowing through elements without adding region elements to markup at all
... so the question was, do we need a box generation mechanism forregions, and I've maintained all along that we don't, and we'll use every box generation mechanism we have for CSS.
... so unless anybody has an objection I'd like to close that one particular issue

<fantasai> dbaron: I'm ok with closing 15733

<fantasai> fantasai: 16858 stays open

<fantasai> astearns: yeah

RESOLUTION: closing issue in bug 15733

Alan: I don't know that it's going to be fruitful to talk about elements today. I've been posting to list; on dbaron's todo list to look at those messages.
... If anyone wanted to discuss what we've been talking about on the list about using named flows and region chains as lower level mechanism for describing fragmentation and pagination and thinsg, but also happy continuing discussion on list.
... Anybody want to talk about that right now?
... if not, move on to next agenda item

CSS Writing modes, Tr fallback

Peter: Maybe we can close this one today?

Koji projects http://www.unicode.org/reports/tr50/

Koji: issue is Tr fallback in writing-modes
... background on discussion:
... UTR50 describes 4 values (shows Table 1). One of them is Tr. T means transform, not only about upright or rotated, but usually requires different type of transformation
... Tr means if font doesn't provide alternative glyphs it should fall back to rotated
... Tr has 2 purposes (1) for backwards compat -- but all existing fonts have alternative glyphs
... (2) example is U+3030 WAVY DASH - not only about rotation but also includes flipping

<fantasai> for backwards compat -- you can see, these characters are not transformed, just rotated, but since all fonts contain transformed glyhs that perform the rotation, want to use those glyphs

Koji: recommendation is preference for flipping in font system, but preference to fall back to rotated fonts
... in CSS writing modes, we had same definition for Tr at one point
... 1.5 years ago John proposed that implementation cost of Tr fallback is high, and # of chars affected is about 10-20 characters
... given the definition -- if font provides all alternative glyphs for these 20 codepoints, issues will go away
... John said even though UTR50 defines fallback, given implementation cost, wants CSS to define fallback to upright
... after that we had 2 different feedback from developers, saying implementation is easy, and they want their UA to display those characters correctly, even with existing fonts
... so we have a situation where 2 developers want fallback to rotated and 1 to upright
... fantasai and I discussed, considered 5-10 characters as subtle difference.
... We agreed to defined to define UA may fall back to upright or sideways, which is what we have in spec right now.
... in September John raised concern that 2 options can cause confusion to authors, and fallback to rotated is wrong or cost high
... so John wants CSS to define "must upright"
... so sylvain agreed with that; glenn disagrees and wants rotated or both options
... James Clark is ???, fantasai and Rossen are opposed too
... Eric said he agrees with john 2 weeks ago
... I talked with Eric last week during UTC, still wants upright, but ok for WG to resolve
... I think that's pretty much situation up to today
... This issue is last issue remaining for LC of css-writing-modes

<sgalineau> For Adobe, Eric Muller believes the best option is to mandate no fallback http://lists.w3.org/Archives/Public/public-i18n-cjk/2013OctDec/0036.html

SteveZ: 2 comments:
... (1) you said TR50 said "should falllback" but what said is "can fallback", though that's a nit.
... (2) second point Eric was concerned about was telling whether font had the appropriate characters. He's concerned about looking at font data because with font subsetting you may get false information about what the font is doing if you're getting a subset. So he was concerned about building that particular piece.
... (3) John's point was that whenever we have optional sorts of things, it means implementations diverge and users get unhappy

Koji: comments on those three:
... (1) As you said it's "can".
... and as Eric said this UTR50 is informative, so it's not forcing everything.
... (2) so I understand that not only it has some other issues like John pointed out, may break dlig
... argument is that can be fixed by designing fonts correctly or designing embedding correctly
... so there are challenges
... but that's not something really not possible
... (3) There may be a ??? on UTR50
... But original goal of UTR50 was to provide consistent orientation
... during development phase we figured it's not possible with existing fonts
... so our goal was to give best consistency, and complete consistency if UTR50 compatible font is used
... and there are 10 characters we are discussing for Tr
... and 20 or more that will be inconsistent anyway
... I'm working with Japanese publishers and AntennaHouse about how authors have to be careful when authoring to be careful orientation consistent across existing fonts
... I agree that allowing both options can diverge and add more burden to authors, but it's not something we can really avoid
... given the cost; development cost varies depending on architecture
... Given that we can't reach consensus I think allowing both is best option

SteveZ: concerned about something you said: fixing a rare case and fixing it at the cost of putting burden on anyone who develops font subsetting
... font subsetting seems likely to be very popular for East Asian fonts. Adding cost to that to fix this problem seems wrong way to go.

fantasai: don't see what this has to do with subsetting

SteveZ: probably not in this case... either character is there or not

Koji: let me explain: Tr defines render as upright, but if no vertical alt, fallback to rotated
... font subsetting could only subset one glyph without the vert table
... in that case using the subsetted font UA cannot determine if codepoint has vertical alternate glyph or not.

SteveZ: yes, sounds correct

Koji: the case for PDF, but for epub or html where user can override writing modes for usability/accessibility, regardless of this issue, font subsetting should include both horizontal and vertical alternate glyphs into the subsetted fonts. If they do that they also solve this problem.
... It's true that it requires additional step, but it's not only to solve this problem.
... does that answer your questions?

SteveZ: I certainly understand what you're saying; requirement for not subsetting with only one of directional things is not coming from this but coming from that user style sheets could override, so you need that capability anyway.

Koji: this is about 10 characetrs. In John's original proposal those 10 characters will be rendered incorrectly for some existing fonts
... John and Eric think that's ok because rarely used characters ...

Sylvain: no, they think fonts will get fixed

Koji: I know there are technical differences... if it's about subtle differences why do we care so much?

SteveZ: understand last way, but applies equally way to any resolution

Koji: Thus I ask either behavior. John wants to demand single behavior, I want to know why.

Jet: the cost to every other codepoint that's not those 10
... extra conditional in code -- vs benefit to rendering those characters incorrectly

Sylvain: I posted a link to Eric Muller's post. Eric thinks no fallback is the better decision.
... That's consistent with feedback I got from other experts.
... I think issue about cost was not about absolute cost, but about cost relative to how often it's needed, since expectation is that fonts will be fixed.
... In general in standards providing optional behavior is a source of incompatibility.
... I think that makes sense.

Koji: It costs more for one option for one architecture but opposite cost for other architectures.
... So if we mandate one we have to pick one.

Sylvain: That's the point of mandating.

Koji: Costs more for some browsers and less for others.

Sylvain: I don't think having no fall back can cost more than fallback.

Koji: I disagree.
... 1.5 years ago discussion cost is sky high another developer said cost is low another developer said cost is opposite

Sylvain: You write complex fallback code that you have to test for something that will happen extremely rarely. Not sky high in terms of total amount; it's relative to the benefit.
... Mandating no fallback will lead fonts to update. (?)
... So that code will never be used

Peter: does practice of subsetting potentially break that argument?
... If alternates end up not part of the subset, not guaranteed to have them.

<SimonSapin> If we assume fonts will get fixed, can we also assume subsetting tools will get fixed?

SteveZ: Koji's point was that subsetting for CSS requires both glyphs to be there because you don't know what will be there until things arrive. You can always do it wrong, but then people will get bad results and people will stop using your system.

Rossen: What if we, instead of disallowing it, discourage it?
... We can say that behavior is not expected, but if there's an implementation that really wants to do it, it's at least not forbidden?
... authors reading spec should not expect it to be supported, but not restricted to forbid behavior

fantasai: I think another thing to consider would be font formats other than opentype.
... In OpenType a number of these characters are transformed by convention, but this might not be true in another font format might have different expectations.
... So even if we want to mandate this for OpenType I don't think it would make sense to mandate for all font formats.
... Also doesn'tmake sense ... ??? if handled at font engine level rather than text layout level.

SteveZ: Rossen, if I understood you: "if the data for the rotated form is not present, this specification does not define what should be done"?

fantasai: works for me

Rossen: That's more of the undefined case

SteveZ: I think advantage of undefined, still leaves the forcing function of getting the fonts updated, because you don't know what's going to happen.

Rossen: Would anyone not be able to live with undefined?

r12a: Would it be a question of leaving it undefined like that, or undefined plus recommend that you follow UTR50?

fantasai: wording I'd suggest is that it's undefined whether the UA is allowed to synthesize some kind of substitute glyph

dbaron: no longer Rossen's "undefined but discouraged" proposal?

(I'd prefer undefined but discouraged over simply undefined.)

SteveZ: where are we?

Rossen: I think between disallowed and undefined?
... As I understand, John wants disallowed

<sgalineau> fwiw feedback on fallback implementation cost I have heard: cheap to hack it, more expensive to do it right. too expensive for the number of cases that will exercise it

<fantasai> "UA may but is not expected to synthesize the substitute glyph"?

Rossen: If we say UAs are not expected to support rotated sideways glyph, but not required not to, then that should be a way of saying basically: don't expect it to work, but implementations might do it.

ChrisL: or in other words would be saying "you may fall back but not required to" just like TR50 says

SteveZ: That's why I'd prefer it's simply undefined, since otherwise you're back out of undefined.

[various people mumbling]

Bert: That's the wrong way round, I'd say.

Rosssen: Current spec says UA may, but not required to fall back to

Rossen: current statement is close

Bert: current statement suggest that what TR50 says is that rotating better than not
... want implementations to rotate but we still like them to do it
... I think wording should be clear that we still want them to.

<fantasai> dbaron: I think many people here disagree that we want them to

<fantasai> dbaron: ppl think we're better of expecting font to have correct data in it, instead of addign features to work around bugs in a font

<sgalineau> +1 to dbaron

Bert: That' assumes it's a bug in the font, maybe it's not.

Peter: In general I'm ok with any of these proposals.

<fantasai> I think for OpenType it would be considered a bug in the font, but for other font formats might not be...

Peter: I'm concerned that I don't want us to say "you must not do this" because if you have a font engine that does this then the UA has to undo what the font engine is doing.
... Just saying it's undefined because it is defined in UTR50
... if we're explicitly undefining it then we're just sanctioning what UTR50 says

<fantasai> +1 to Peter

<fantasai> wrt undoing font engine

Peter: so if we have an explicit preference we'd ???
... I have concerns if we're willfully violating an other spec, if it says "can do it" and we say "must not do it"

<Rossen_> "the UA is not expected to fallback..."

fantasai: Can we straw poll on wording "may, but is not expected to"?

Peter: should we reference April 1 update to RFC2119?

fantasai: ?

Rossen: what if we say UA is not expected to do fallback?

fantasai: we have to say allowed disallowed or optional
... we have to say, normatively, what is it
... saying something is expected or not expected is not really normative

SteveZ: Seems to me we have 3 possibilities:
... (1) John's "must not"
... (2) undefined
... (3) should use the font, but failing that can do fallback per TR50
... I think those are only 3 on the floor. Apperas to me at this point that easiest to eliminate is (1).
... that leaves us with 2 different ways of saying can fall back, either by not saying anything or by saying you can
... I'd propose a straw poll that would eliminate the first option
... and then we can see if there's a significant difference between other two
... Seems easier to eliminate (1) from straw poll

fantasai: 2 wordings on floor:

<fantasai> "If the vert alt glyph is not present in the font, UA may but is not expected to substitute the glyph"

<fantasai> vs

<fantasai> "If the vert alt glyph is not present in the font, behavior is undefined"

<fantasai> ??

peterl: RFC6919, "REALLY SHOULD NOT"

<sgalineau> MUST SHOULD NOT

SteveZ: I think fantasai's second option captures what we should get at

<SimonSapin> MAY WISH TO

<fantasai> fantasai: The first one is my proposal, because I don't like leaving things blanket undefined

<sgalineau> Y U FALLBACK

r12a: What happened about the straw poll to eliminate (1)?

<plinss> http://tools.ietf.org/html/rfc6919#section-3

r12a: can we resolve to eliminate option 1?

STRAW POLL:

A) "If the vert alt glyph is not present in the font, UA may but is not expected to substitute the glyph"

B) "If the vert alt glyph is not present in the font, behavior is undefined"

[2013-11-12 10:20:20 +0800] <fantasai> ??

(oops, ignore that extra line of copy/paste)

fantasai: I don't like (B) because it allows the UA to do absolutely anything it wants.

STRAW POLL:

A) "If the vert alt glyph is not present in the font, UA may, but is not expected to, substitute the glyph"

B) "If the vert alt glyph is not present in the font, behavior is undefined"

Alan: A

rhauck: A

dirk: abstain

Bert: of these two, prefer A

zcorpan: abstain

kazutaka: A

yamamoto: A

Koji: A

Rossen: A

Israel: A

jet: A

chrisL: A

Lea: A

Sylvain: A

3 A's

Dean: abstain

fantasai: A

dbaron: A

<hober> hober: mu

SteveZ: A

Kennyluck: A

Leif: abstain

Peter: A

Bert: My question is, are we really doing what Unicode want us to do?

<TabAtkins> TabAtkins: abstain

bert: was it really a neutral choice to be doing it or not, or do we ???

fantasai: descriptions in unicode spec are informative saying what categories mean, not dictating a behavior

Bert: if they didn't want implementations to rotate, why did we write it there/
... I think we're saying opposite of UTR50.

Peter: UTR50 says can, we're saying may but not expected to

r12a: is substite the right word, or is rotate?

fantasai: synthesize the substitute glyph
... wording's a little bit off

Peter: I think "MAY WISH TO" from RFC6991
... I think "MAY WISH TO" from RFC6919
... I think we should use "MAY WISH TO" and refence RFC6919.

RESOLUTION: Accepting option A, with term "MAY WISH TO" and referencing RFC6919.

<ChrisL> http://tools.ietf.org/html/rfc6919

Peter: spec ready to advance?

<SimonSapin> "This phrase is frequently used to avoid further delay in approval of a document."

fantasai: I expect this to be the first of at least two last calls.

<SimonSapin> seems appropriate

Peter: Anything to rename?

RESOLUTION: Take CSS Writing Modes to Last Call.

Peter: break until 11am.

<fantasai> I think there's an open issue on possibly renaming text-combine-horizontal to something better/easier-to-type/less-confusing

<israelh> q

<TabAtkins> Did we not return, or is nobody minuting?

<plinss> nothing secret, just not necessary to minute

<TabAtkins> kk

<sgalineau> as far as I know we are making http://girliemac.github.io/presentation-slides/html5-mobile-approach/images/css-is-awesome.png our official logo

<fantasai> From CSSWG design that didn't get implemented -- "mood": flowing, transparent, layered, professional, informed

<SimonSapin> ScribeNick: SimonSapin

Text module

fantasai: to prepared to discuss

plinss: defer

Charter

Bert: last time we had milestones, wiki page for dates
... most people said can’t put dates
... now list specs in scope, and says we don’t have dates

<plinss> http://www.w3.org/Style/2013/css-charter

Bert: mostly same as previous charter
... same participation reqs, chairs, mailing list
... list of modules longer
... diff list of liaisons
... look if it’s complete and not too long
... about not having milestones, only a list of things we work on, without dates
... do you agree with that? Can it get past AC review?
... glazou said we have a few drafts that are requirements for other groups, we should give that higher priority
... didn’t list those, glazou sent email with the list
... we could mark those explicitly

astearns: is there a logic to the order?

Bert: no, automatic tool takes the order from the /TR page
... date is to be updated when we have review, roughly 2 years

dbaron_: guess the order is by age of WD
... there is a bunch that appear twice

Bert: that’s a bug

fantasai: suggest taking the Current Work page

dbaron_: looks like list of shortnames ever used

<dbaron_> duplication: UI, borders, CSS1 ,CSS2

Bert: someone wants to get through the list to fix?

fantasai: can you take it from Current Page?

<fantasai> http://www.w3.org/Style/CSS/current-work

Bert: some are missing

ChrisL: that’s a feature

<dbaron> We're also probably not going to work on becss.

<fantasai> Yeah, don't want to include the Abandoned drafts

plinss: any feedback on the charter? folks generally happy with it?

ChrisL: we’re looking at the suggested extensions from 1998 and slitting our wrists

plinss: update the module list before we submit?

<astearns> dauwhe_: page templates is only an editor's draft

ChrisL: looks fine, I suspect AC won’t object

ChirsL: we say we don’t have milestones because …

<astearns> dauwhe_: I believe we resolved to get simple pagination done first, before making page templates a working draft

ChirsL: and say that things needed by HTML5 are …

plinss: email to internal list when ready

<scribe> ACTION: Bert to update the list of deliverables in the charter [recorded in http://www.w3.org/2013/11/12-css-minutes.html#action01]

<trackbot> Created ACTION-595 - Update the list of deliverables in the charter [on Bert Bos - due 2013-11-19].

plinss: anything else on charter?

Styling left vs. right pages

<dbaron> I wouldn't mind seeing us doing asynchronous decision making, but I'm not in the mood to have that discussion right now...

<sgalineau> asynch decision discussion better done asynchronously

leaverou: discussed this in private and on mailing list
... long, but no conclusion
... people write books in CSS, including design of the book
... I first designed mine in Illustrator, then many things were not possible in CSS
... no way to style elements depending on right or left pages
... we have @page, for the page itself or headers/footers, but not elements on the page
... to do sidebars in print formatters, you use "float: outside"
... to push it you use "float-offset" but that’s limited
... it’s not just the sidebar, [projecting]
... these things have different border-radius, rotate transform, margin, etc. depending on left/right page
... float: inside/outside and margin-inside/outside are not enough
... we can,t keep adding properties, need a more generic solution

<leaverou> http://lists.w3.org/Archives/Public/www-style/2013Jul/0607.html

leaverou: proposal on the list …
... @page :left, nest style rules
... syntax not doable, ambiguous with declarations
... needs infinite look-ahead, same as in Hierarchies
... proposal to use braces, at-rules, or pseudo-elements

<TabAtkins> Note, Hierarchies has been fixed.

leaverou: div::page(left)
... still limited, you want to style based on type of page (chapter, …)
... and other page selectors
... other proposal from AntennaHouse: extending Variables to inherit from @page
... but then you have different property values on different pages for the same element

TabAtkins, how?

fantasai: whatever syntax we use here should be the same as for Regions

dbaron: styling things between pages has a lot in common with between regions

<TabAtkins> SimonSapin: http://tabatkins.github.io/specs/css-nesting/Overview.html#the-nested-block

dbaron: we don’t want to allow completely arbitrary style
... we don’t want something that starts as a table, continues as a float, etc

<TabAtkins> SimonSapin: Wrap the selectors in an anonymous {} block.

<TabAtkins> Rather, the whole thing.

dbaron: there is no concept to continue the inside of a table onto the next page as something else
... so far we don’t have the ability to fragment things into completely different types
... if we have a display-inside / display-inside split, we can’t change display-inside between fragments
... we’r gonnna need implem experience

leaverou: could be limited to not allow some properties like display
... or just no style fragments, only based on the first page

dbaron: there may still be some hard cases
... hard to spec and get interop, even if easy to implement, with edge cases
... with this style fits on this page but doesn’t with other style
... also not convinced that styling based on the first page is that useful

leaverou: I realize there are use cases spawnning pages, but most I’ve seen are within one page

astearns: when you’r printing, you control pagination
... on screen, things intentended to be on one page may be split

leaverou: print formatters vendors have clients that demand features, and they will implement even without spec

dino: I agree these are all great use-cases, but who is gonna do the work?

fantasai: once we hack the syntax and model stablizes for Regions, the only thing that would different in syntax is changing the word region to page
... the hard part of the work, Alan is already working on

astearns: agree with dbaron that we’re gonna need impl experience to decide what can be styled, don’t have it yet for Region

leaverou: btw, there is already a pseudo-class for styling … In paged media or GCPM, styling fragments of an element based on what page they appear
... fragmentation problems still exist

dauwhe_: want to mention that left/right, named pages, also need to identify arbitrary pages in a sequence
... 6th page in a sequence

leaverou: another thing needed is syntax like :nth-page
... targetting pages between the 10th and the 100th
... would be useful for page number
... there is no such thing as inline-block for margin boxes…

dino: you need nested regions of pages that themselves can be styled

dauwhe_: PrinceXML has :nth-page
... discussion on www-style, but complicated to define what is a page, first of chapter vs. first of document
... whole class of issues around identifying pages

SteveZ: XSL did come up with rules to select which of the next template is used for a given page
... want a number of sources that are active, choos the template based on what kind of things are available
... which template you pick depend o which are associated with the content of that page
... this divorces the design of template with their selection, rule-based

<TabAtkins> Note my previous discussion with Hakon, that "foo:nth-page(5)" does *not* select the 5th "foo" page, but rather the 5th page if it is also a "foo" page.

SteveZ: :nth-page assumes that you know what content goes there

<TabAtkins> In other words, selectors don't modify each other.

SteveZ: as astearns says you may not know
... XSL tired to define but never succedded sync points

<dino> TabAtkins, so how do we select the 5th foo page?

<TabAtkins> :nth-match(5 of foo)

SteveZ: the notion of identifyin sync content, stream of figures / stream of text

<TabAtkins> We've already solved this problem in Selectors.

SteveZ: thing figure goes with this piece of text

<dino> TabAtkins, cool

SteveZ: as close as possible , which may not be very close, but at least being able to declare that would be useful

plinss: I agree this should be aligned with Regions

fantasai: doesn’t belong in Fragmentation

plinss: useful for multicol?

fantasai: I think less so
... track as something we need to address, note that we need this for pages, but not much to do right now

astearns: if AH or Prince wants to run with it…
... I,d be happy to put a note "this mechanism should be applied to pages"
... if there is impl interest, pages may be done before regions
... but I don’t know how Antenna House or Prince are prioritizing

plinss: is there consensus that this is a good idea?

leaverou: if the mechinism is defined in Regions, do we still need to define the syntax?

astearns: there is a syntax for Region […] all contnet that falls in this region, here are their style
... same would apply when selecting a page instead of a region
... just changing that part of the selector that says I’m styling this region

ChrisL: we still need to write this down

astearns: it will be the same for styling content in Shadow DOM

<TabAtkins> Pages use a somewhat different selection mechanism (at-rule to introduce the selector), but yeah, similar mechanics.

leaverou: the way this will be done in Regions is through pseudo-elements?

fantasai: yes

leaverou: but @page rules are more concise
... if you have a series of things that need to differ page page style, need to repeat the page selector

<TabAtkins> ".foo::region .bar" for .bars inside of the region hosted by .foo

fantasai: same problem with regions, we should solve this for all of the things

astearns: syntax for Regions has the constraint that it needs to fit in future nesting mechanisms that reduce repetion

leaverou: will this apply to all page selectors and combinations of those?

dauwhe_: I guess we just start trying things

plinss: trailing off, but not hearing any objection. Will follow the work on Regions

Bert: we have Dave editor of GCPM, I suggest we concentrate effort around Dave
... see which things are already covered in Regions

<dbaron> Why do we want to push this into GCPM?

<dbaron> [minute taker fell off IRC]

<dino> ScribeNick: dino

Bert: People should meet informally to discuss the next steps

plinss: I don't have an issue with David taking this on. Some people have suggested a page layout task force so it doesn't take up much of the group's time
... i don't want to continue dumping "all the things" into GCPM

<dbaron> +1 to plinss

dbaron: i'd be inclined that this deserves it's own module

astearns: or a new level of paged media

plinss: possible

Rossen_: what happened to the one daniel was starting in Lyon?
... sounds like the same conversation we've already had

SimonSapin: he has a proposal for the future of paged media

(on dev.w3.org)

<dbaron> http://dev.w3.org/csswg/css-page-4/

plinss: Dave, are you willing to champion the work?

dauwhe_: yes

SimonSapin: We discussed two things: one of which lea asked (styling elements based on page location), and better page selectors (which is in the paged media spec)

plinss: also need to expand on "spreads"

--- LUNCH BREAK ---

hold the lunch break

r12a: are you going to discuss CSS Text?

plinss: we deferred because fantasai needed to prepare

fantasai: i can maybe work on it during lunch
... agenda+ backgrounds and borders?

plinss: ok

dbaron: agenda+ one thing about charter?

plinss: let's do this now

Charter stuff again

dbaron: comment about async participation
... many WGs have requirements about async decision making. e.g. WebApps, a bunch of related API groups, and HTML (but that is a special snowflake)
... i don't necessarily want to force the async decision making policy here, but I would like to see us try to make async decisions more often
... async == decisions are not generally taken in a meeting like a vote. rather the chair sends the notification via email, people can object before some time period elapses.

<TabAtkins> Async decision-making will likely speed up a lot of decisions, too. No need to wait for a slot during telcon, potentially getting bumped multiple weeks.

dbaron: i often find myself unsure whether or not to object within 10s at a meeting. I think async leads to decisions made with more consideration.
... what do other people think?

ChrisLilley: on the one hand...

<astearns> TabAtkins: +1

ChrisLilley: that can be a benefit... e.g. Tab isn't here and he needs 48 hours to object..
... but i don't want to be in the situation where we're waiting for people to read the notification, stall, etc
... how is it working in other groups?

dbaron: one of the important points is that these groups are not making the decision EVER on the telcon, but everything is on the mailing list
... the forcing function is sometimes useful. i don't participate in these groups, but i've heard it is working well

steveZ: also allows people not on telcons to get involved
... the notification needs to be clear what the decision will be

israelh: in webapps, i've noticed that sometimes the decision thread doesn't really give you a clear outcome, and we still need to come together on a call to make the final final final decision. how do you figure out what the tiebreaker is?

kennyluck: it's often dependent on the type of decision: publishing a spec vs technical decisions

plinss: in general all i care about is making good decisions
... i'm ok with whatever technique we use to get to that point
... i'll note that we often do async because we know someone is not yet ready/present.

<kennyluck> My point is that I don't know who can send CfCs. Everyone?

plinss: dbaron, are you encouraging us to do it more?

dbaron: yes, do it more

krit: so will it be all decisions, or will we still need f2f meetings?

astearns: I think people will get comfortable will asking more time.

plinss: yes, to be clear, all WG members are free to ask for more time or open something if it is an error

<fantasai> plinss: we've never refused such a request

zcorpan: i think async works pretty well. but if there is a situation where we can make a decision now, that should be available, just not the common case.

krit: I'm asking for whether all decisions must be made at telcons, or if the mailing list was enough

dbaron: mailing list would be enough

sgalineau: agreed

plinss: do we want to put this in the charter?

dbaron: some other groups have it in the charter. i don't think we need it that formal, but we should move in that direction

SteveZ: should we put that it is allowed into the charter?

dbaron: maybe

SteveZ: maybe it should be listed as a process to stop people objecting to the process

astearns: there is nothing in the charter that says all decisions require a quorum, so we're not explicit

SteveZ: i would like to understand the rules

<kennyluck> +1 to SteveZ

krit: dbaron, could you send a proposal to the mailing list?

dbaron: yes

SimonSapin: good q on irc, who can ask for a decision on the mailing list?

fantasai: it should always come from the chairs

plinss: i don't think we should say that we're going to do everything this way. Some things might be better this way, others might not.
... anyone can always ask the chairs to adjust the way we work, even for a particular issue
... fear is that we'll be making decisions by defualt because people are not participating

astearns: it will be interesting to see how many bad decisions we've had to back out because no one participated

plinss: maybe it will be better if the email is clear what the decision will be
... we'll probably have to have discussion about what the proposed decision will be

<sgalineau> +1. straw polling rarely works over email. better make a call to force feedback.

dbaron: i think it works for "can we publish"

SimonSapin: i don't think this is about taking options away

plinss: agreed.

<scribe> ACTION: dbaron to send a proposal for async decisions [recorded in http://www.w3.org/2013/11/12-css-minutes.html#action02]

<trackbot> Created ACTION-596 - Send a proposal for async decisions [on David Baron - due 2013-11-19].

<sgalineau> sp the conclusion is that we'll discuss this on the mailing list….

--- REALLY LUNCH BREAK ---

<TabAtkins> When is lunch til?

<TabAtkins> 1?

<TabAtkins> Nah, that's in half an hour.

<fantasai> between 1:30 and 2

<fantasai> TabAtkins: depending on cafeteria lines

<fantasai> TabAtkins: How about I'll text you if we get back before 2?

<TabAtkins> kk

<dauwhe_> waiting for everyone to get back from lunch

<krit> https://dvcs.w3.org/hg/FXTF/raw-file/default/filters/index.html#security

<ed> http://dev.w3.org/csswg/css-transforms/

<astearns> https://dvcs.w3.org/hg/FXTF/raw-file/tip/geometry/Overview.html

<TabAtkins> zcorpan_: Yo, several of your IDL interface defs are linking back to CSSOM, which just says that they're defined in Geometry. To force Bikeshed to mark something up as a definition, add dfn-force='' to the <pre>.

<TabAtkins> Is DOMRectList actually needed, or is it just used in the existing IDL and we're keeping it?

<TabAtkins> We should try to migrate it to an Array if possible.

<slightlyoff> why the hell aren't any of these things constructable?

<slightlyoff> and why aren't they just JS arrays?

<slightlyoff> heycam`: ok, that's good, 'cause this is depressing: http://www.w3.org/TR/SVG11/coords.html#InterfaceSVGPointList

<TabAtkins> slightlyoff: Don't want Points/etc to be just arrays. The Lists, yes, that's what I (and now zcorpan) just said.

<astearns> no instances of SVGPointList in snap source

<slightlyoff> TabAtkins: yes, was referring to the lists

<slightlyoff> it'd be much better if there were an svg.* object instead of all of the SVG* prefixing = \

<TabAtkins> slightlyoff: SVG.*. Uppercase for great justice! (And better author-collision avoidance.)

<slightlyoff> TabAtkins: !?!!!?

<slightlyoff> TabAtkins: seriously...that's O_o

<dbaron> So what happened regarding the third (immutable) rect type in http://lists.w3.org/Archives/Public/public-script-coord/2013OctDec/0045.html ?

<TabAtkins> Um.

<dbaron> did that get dropped?

<TabAtkins> We always uppercase interfaces.

<slightlyoff> TabAtkins: I mean, eventually you'll want this this stuff to be an ES6 module, right?

<TabAtkins> Sure, yeah.

<slightlyoff> TabAtkins: fine for the interfaces, but putting the interfaces in a single object instead of in the global

<TabAtkins> A namespacing interace is just a shitty module.

<slightlyoff> TabAtkins: that was the "." in my "svg.*"

<TabAtkins> ...I know.

<TabAtkins> We already have window.CSS for the same thing.

<slightlyoff> TabAtkins: beats the dihereah ya'll have going on here

<TabAtkins> l2spell ^_^

<TabAtkins> +1

<TabAtkins> http://dev.w3.org/csswg/cssom-view

<slightlyoff> why are all of these things marked readonly?

<slightlyoff> http://dev.w3.org/fxtf/geometry/#DOMPoint

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

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

<slightlyoff> again, why is all of this stuff readonly?

<TabAtkins> slightlyoff: It's not readonly. There are readonly *variants* of th einterfaces, for various uses in APIs.

<TabAtkins> But they all have mutable versions too.

<slightlyoff> TabAtkins: where are those?

<TabAtkins> Right there, in the spec next to the other ones?

<slightlyoff> TabAtkins: not seeing mutable version here: http://dev.w3.org/fxtf/geometry/#DOMPoint

<slightlyoff> oooh...I see

<TabAtkins> slightlyoff: The DOMPoint interface is mutable.

<slightlyoff> what's the reason to have the readonly version at all?

<TabAtkins> Because you need readonlys for APIs at various times. Plenty of times you're exposing a point on some interface, and it's not meant to be mutable, or mutating it won't do anything.

<TabAtkins> In other words, same reason to have the "readonly" keyword in any situation?

<TabAtkins> Hanging mutable-but-useless attributes off an interfaces is a bad idea. Should either be readonly, or should be a method that returns an object, or should be mutable and live. Pick one.

<TabAtkins> (Apparently the last one is usually bad.)

<slightlyoff> TabAtkins: I'm really unsure why "mutating it wouldn't do anything" is anything other than "it wasn't defiend with an accessor pair, so c'est la vie"

<slightlyoff> TabAtkins: the idea that you should be locking things down is just odd

<TabAtkins> slightlyoff: What happens when you mutate a point on a DOMRect? It magically becomes a DOMQuad? It just starts wildly violating rect-based assumptions?

<TabAtkins> DOMRect has a mutation API - mutate x/y/width/height.

<slightlyoff> TabAtkins: it's JavaScript? You document your assumptions.

<TabAtkins> And your assumptions might be "this isn't how you mutate the object, it's just some useful info you can use. Accordingly, we're documenting it as readonly."

<TabAtkins> I'm okay with accepting the looser SVG syntax, I think.

<slightlyoff> TabAtkins: I'm really just unsure what the case for this is aside from pre-emptive invariant preservation

<slightlyoff> TabAtkins: most JS objects are mutable and the world is not, yet, on fire

<TabAtkins> slightlyoff: Again, it's identical to making literally anything else readonly. If you'd expose "readonly attribute double x; readonly attribute double y;", you can instead just expose "readonly attribute DOMPointReadonly;"

<slightlyoff> TabAtkins: that's not a case for *if* it's something you should do, which is what I'm questioning

<TabAtkins> slightlyoff: Had this dicussion on the list before. Live objects are discouraged API design (prefer mutating methods). If an object isn't live, it probably shouldn't be mutable either - better author affordance.

<slightlyoff> TabAtkins: this is alien to most JS practice

<TabAtkins> Otherwise, you mutate something, nothing happens, but now the attribute is lying.

<slightlyoff> TabAtkins: so whatever you might prefer from some other perspective, it's just not something I think these WGs should be worrying too much about

<TabAtkins> Sure, because readonly isn't easy to do in JS. Gotta screw around with getters.

<TabAtkins> Part of having an interface description language is being able to abstract some of the difficulties of the underlying implementation language, when it's useful to do so.

<slightlyoff> TabAtkins: that doesn't make this design any less alien

<slightlyoff> TabAtkins: also, you don't need that, you only need a property descriptor

<TabAtkins> slightlyoff: Property descriptors are at least as fiddly as getters. ^_^

<TabAtkins> slightlyoff: I don't think cleaving hard to the particular syntax affordances of JS is particularly important.

<dbaron> heycam: or we could go down the road of having a frozen plain object for that

<slightlyoff> +1 to what heycam` said

<TabAtkins> Yeah, more freezing.

<TabAtkins> It buys us protection from "I'm reading these values, but they're not accurate!" (because somebody mistakenly mutated them before).

<TabAtkins> dbaron: Alex is arguing against all but the mutable types.

<slightlyoff> I'm saying "just have setting the value do nothing in that case"

<TabAtkins> You can't have the object change in the background (in at least some cases). (Unless I'm misreading the minutes.)

<TabAtkins> Calling in is a giant fail.

<TabAtkins> Never worked yesterday.

<fantasai> r12a, we'll want to discuss Text soon, let us know if that works for you or you have other constraints

<fantasai> kennyluck: ^

<fantasai> starting with css3-background for now

<r12a> fantasai, ok heading down there

<TabAtkins> dbaron: Yeah, that led to the wiki page that now says "DON'T DO THIS".

<leaverou> http://lists.w3.org/Archives/Public/www-style/2013Apr/0109.html

<TabAtkins> Yeah, the "right" way to spread things is indeed to increase the radius by the amoutn of the spread. That's how you do curved borders, frex.

<sgalineau> we can mitigate the discontinuity for some range of spreads; once a spread is large enough there will always be a point where the corner looks sharp and the spread rounded...

<TabAtkins> (In reverse - the inner curve is equal to the outer curve minus the border width.)

<TabAtkins> Obviously.

<dbaron> I'm in favor of making text-align a shorthand containing text-align-last

<kennyluck> (I am not very convinced that 'text-align: justiy-all' implies that 'text-align' should be a shorthand, but I support whatever would make 'text-align: justify-all' in.))

<trackbot> Created ACTION-597 - Mail www-style with the text-align shorthand issue [on Elika Etemad - due 2013-11-19].

<kennyluck> the case is basically this <input> <input>

<dbaron> (that substitution applies to 7 and 8 lines up, but not 20 lines up!)

<TabAtkins> What's left after the break?

<astearns> scribenick: dauwhe_

<fantasai> http://lists.w3.org/Archives/Public/www-style/2013Aug/0178.html

<dbaron> dbaron: I think it's worth testing browsers before defining the behavior here; seems worth doing but doesn't have to happen in this level

<dbaron> zcorpan: I think it's defined in CSS OM; browsers tend to disagree but the definition tries to align

<zcorpan_> http://dev.w3.org/csswg/cssom/#concept-declarations-specified-order

fantasai: don't define what happens if you expand something out.

zcorpan: we need to define orders of longhands

<dbaron> fantasai: The canonical order seems to define canonical order for serialization, not of longhands

fantasai: what should I do with spec?

zcorpan: I want order defined in CSSOM.
... I can take action item to test what browsers do and document it somewhere.

fantasai: should there be a list of all properties in spec in an order?

dbaron: we should see what browsers do. I don't want to break interop.

fantasai: what does that spec look like?

dbaron: orderings might not fit with list in spec?
... might be easiest to put in propdef
... must define order resiliant to addition of new properties

fantasai: who's doing this?
... and in what spec?

dbaron: do we have def of canonical order in propdef?

fantasai: in CSSOM

dbaron: CSSOM uses the term canonical order, but does not define it.

fantasai: how to read propdef tables is not part of spec

<TabAtkins> Ah, I was wondering why it started in the middle of stuff.

fantasai: only def. is in CSS 2.1
... put how to read css propdef tables into snapshot?

dbaron: used to be in syntax

<dbaron> dbaron: or could be in values

<TabAtkins> I'm fine with either.

plinss: who edits these specs?

fantasai: does this need to be rec track document?

dbaron: yes

<TabAtkins> ...really?

plinss: don't feel strongly about syntax or values but should be rec track

fantasai: not convinced about rec track; it's about document conventions

astearns: it's about document conventions?

fantasai: how to read a propdef table is largely about document conventions.

<TabAtkins> Are people talkinga bout the same thing?

plinss: it's meta-normative.

fantasai: snapshot is where you want to put it

<TabAtkins> I think we're talking about the format of a propdef table. It's just a compact representation - how to expand that into the normative def doesn't need to be Rec-track, just recorded.

fantasai: did you see Tab's comment?

<TabAtkins> We don't need the property grammar in a rec-track doc either. It was just convenient to put it into Values.

<TabAtkins> I don't understand, dbaron. :/

plinss: I suggest we put it in values

<TabAtkins> But the only thing that got minuted was "Yes" from you, so shrug.

fantasai: some of it is about values
... is it inherited.

<dbaron> TabAtkins, It affects what some pretty important stuff in the spec means

astearns: I agree it should be in values.

<dbaron> TabAtkins, stuff that changes what an implementation is required to do

<dbaron> TabAtkins, it seems pretty odd to make something like that non-normative

<fantasai> glazou, interop on how to read a propdef table? Yeah, I guess so, but the implementations are people here...

<zcorpan_> i agree with dbaron

<astearns> *if it needs to be in a rec track document

<glazou> fantasai, yeah...

plinss: do we need a resolution

fantasai: we need an action

<TabAtkins> dbaron: No, the content inside of it is normative. How to read it is just descriptive. But whatever, I'm fine with it in Values or Syntax, I just don't see that it *needs* to be in one of those.

plinss: who takes the action?

<fantasai> ACTION: fantasai put something somewhere [recorded in http://www.w3.org/2013/11/12-css-minutes.html#action03]

<trackbot> Created ACTION-598 - Put something somewhere [on Elika Etemad - due 2013-11-19].

<glazou> lol

<TabAtkins> You're going to look at that later and be so confused, fantasai.

astearns: one other thing on backgrounds
... remove three-value positions?

fantasai: we'd also have to remove one-value positions, including center

astearns: we would have to remove one value that is not keyword

fantasai: not something we can fix
... what are Tab's thoughts?

<fantasai> e.g., 'center' would no longer be a valid <position>

<fantasai> so I'm less convinced this is a good idea

<TabAtkins> Why do we have to also remove 1-value?

<fantasai> when it was just 3-value syntax, well, that seemed unpopular enough to get rid of... but not 1-value

<fantasai> TabAtkins, because it's ambiguous

plinss: do we want tab to call in?

<TabAtkins> The problem with 3-value is that "left top 5px" is maybe a <position> and maybe a <position> <length>.

dbaron: if he does, would he hear us?

<TabAtkins> But "left 5px" isn't ambiguous.

<fantasai> it is

<TabAtkins> No, I won't hear anything.

<fantasai> it can be <position> <length>, too

<fantasai> or it can be <position> with 2 values

<TabAtkins> Aw man, I thought I remembered the 2-value as being either 2 lengths or 2 keywords.

<TabAtkins> Sigh, okay.

<fantasai> Close no change?

<TabAtkins> Oh.

<TabAtkins> Given that this is *not* intending to be a backwards-compatible change (we'll define the old position syntax as <legacy-position> and still use it in the older properties), what about making the 2-value change to have it only be lengths or keywords, not both?

<fantasai> I think this is getting more confusing than helpful

<TabAtkins> Then we could allow 1-value as keywords only, and no ambiguity.

<TabAtkins> I'll write it up.

astearns: this has no effect on backgrounds

<TabAtkins> Right.

astearns: for backgrounds we close no change

<TabAtkins> Yes.

fantasai: that we'd have to do anyway
... syntax that's almost but not quite the same
... that might be confusing

<TabAtkins> What we name the grammar term in bg-position isn't important anyway.

fantasai: whether it's valid in one case or the other
... don't have any cases
... where it make a significant difference
... not worth pursuing

<TabAtkins> Yeah we do - we can't use something position-like for 3d.

<TabAtkins> Because of the ambiguity.

<TabAtkins> But anyway, I'll write this up.

<fantasai> TabAtkins, then let's make transform-origin a special snowflake

<fantasai> TabAtkins: it's special in having 3 dimensions of position already

<fantasai> I'm rather less convinced that we should be altering gradients(), shapes, et al.

<fantasai> to be different from background-position

<fantasai> than altering transform-origin in that way

<TabAtkins> It probably doesn't matter much, but whatever.

fantasai: thoughts on altering transform-origin() to allow to expand to

,.. so the problem is that it only takes this length arg. that represents third dimension

scribe: so we're stuck with css1 backround positioning
... that's the problem case we have
... since this is a 3-d position
... it's less bad.

astearns: dirk has strong opinions about transform-origin
... that I can't channel

<fantasai> ACTION: fantasai write up with Tab potential changes to transform-origin to reduce/alter inconsistencies with background-position [recorded in http://www.w3.org/2013/11/12-css-minutes.html#action04]

<trackbot> Created ACTION-599 - Write up with tab potential changes to transform-origin to reduce/alter inconsistencies with background-position [on Elika Etemad - due 2013-11-19].

fantasai: anything else?
... can we make spread continuous is still an issue
... working on formula so we can have continous animation
... starting from zero
... or we can decide we won't change and publish LC

plinss: set time limit on new solution
... I don't feel strongly

fantasai: neither do I. I'll respond to mailing list.

Dean: I've proposed border-image-like slicing for backgground image
... some support on mailing list
... is this enough for a real proposal?

fantasai: we can do backgrounds 4.

<TabAtkins> I find the 9-slice function idea interesting.

dbaron: don't add to level 3

Dean: don't delay progress in level 3

dbaron: hesitant about property explosion

Dean: haven't thought through
... could be like border-image
... before the comma

Ted: what about a new function?

Dean: Tab wanted a new function.

Lea: very different

fantasai: consider for level 4 of images
... we have feature for fallbacks
... an image function
... takes comma seperated list
... lots of crazy discussion of image set
... tied to media fragments and slice
... UA's that don;t understand media fragments removing image
... people want to implement media fragments
... drop fallback
... only new functionality would be media fragments
... make it more enticing to implement

Ted: sounds good

plinss: shouldn't be issue to put fallbacks back

fantasai: put in image sets
... push to level 4

plinss: don't preclude doing something in future

<fantasai> TabAtkins, ok with that?

<TabAtkins> I don't get it. What's the value of using image() just for media fragments? You can do that in url().

plinss: other opinions?

Ted: sounds reasonable
... I'm worried that I'm not thinking of something

<TabAtkins> The point of the special image() bheavior wrt fragments was *because* you could do fallback.

Ted: I'd love to see concrete proposal

<fantasai> TabAtkins, no that was image slicing via media fragments

<fantasai> TabAtkins, talking about removing the comma-separated multiple urls funmctionality of image()

<TabAtkins> Yeah, why? The minutes above don't make sense.

dbaron: what are you proposing?

<TabAtkins> Fallback is the whoel point of image().

<fantasai> TabAtkins, well, not really. We have two features in the image() function

fantasai: there's 2 features in image function

<fantasai> one is fallback urls, so image(foo.svg, foo.png, foo.gif)

<fantasai> other is media framgents

<fantasai> image(foo.png#xywh=20,20,30,40)

<TabAtkins> No, media fragments is not a feature of image(). It's a feature of URLs. They're usable in url(), too.

<fantasai> There's much interest in the first one

<fantasai> but in the second one

<TabAtkins> We just happened to shove in a requirement that image() *must* support media frags.

<fantasai> Yeah, which is what makes it usable

<TabAtkins> Explain?

<fantasai> Also, given the desire for image-set(), would want to co-design fallback URLs with that

<dbaron> Maybe this should go to the mailing list?

<plinss> See http://drafts.csswg.org/css-images-3/#image-fragments example 4

<fantasai> If you have an old UA and you use url() with media frags, it will display the whole image

<TabAtkins> ...yes?

<fantasai> so it's not really usable atm

<dbaron> what was tab saying yes to?

<fantasai> image() makes it possible to transitioning

fantasai: fine to move to next topic

<TabAtkins> Okay, I think I understand now.

<TabAtkins> Sure, whatever, reduced implementation.

plinss: take issue to mailing list?

fantasi: tab says ok

dbaron: I think it was OK to something else

<TabAtkins> I'd like to keep the color fallback if possible at this level.

<fantasai> ah

<TabAtkins> dbaron: It was a questioning yes, like "yeah?"

plinss: mark as at risk or take out?

fantasai: take to mailing list

<TabAtkins> kk

transitions

<dbaron> http://lists.w3.org/Archives/Public/www-style/2013Nov/0192.html

dbaron: made edits we agreed on in Tokyo
... and would like review of edits, want to publish WD sooner rather than later
... hope there's nothing big left
... still need to troll mailing list
... first, are people OK with new WD for transitions
... then take both to LC soon

<dbaron> yes, trawling :-)

<TabAtkins> Hehe, I know. Near homophones.

Dean: I support publishing

<TabAtkins> +1 to publish

Dean: undecided was reversing behaviour

dbaron: 2 big edits
... reversing behaviour
... and starting of transitions, which was scarier change
... implemtations all disagreed
... that's been in spec for a few months
... shane said in Paris he'd implemented it
... and thought it worked
... if people are happy to resolve to publish that's fine

RESOLUTION: publish new working draft of CSS Transitions

CSS Shapes

astearns: i've updated spec
... some clarifations to interpolation I need to add
... add section describing box keywords
... esp. margin box
... minor changes to inset circle and ellipse to clarify
... will ask for last call

fantasai: sounds good
... would be OK with LC

astearns: interpolation stuff doesn't work

fantasai: other things?

backgrounds and borders 4

Lea: border clip property
... show only corners, etc.
... wondering about syntax and names
... border clip is confusing
... doesn't draw and then clip
... doesn't show 2/3 of a dot
... maybe call it border parts?

fantasai: couple of proposals
... border parts property
... awkward for common cases
... need length for both what is shown and what is hidden
... do we want low level syntax or easier way to handle common cases

<TabAtkins> I think common cases are sufficient, surely. Complex cases, just use border-image.

Lea: border-corner-shape

<TabAtkins> Need to show only corners, and no corners, and that's about it.

Lea: scoop, notch, bevel
... I've built a demo of that property

<leaverou> http://leaverou.github.io/border-corner-shape/

Lea: only accepts one keyword
... wondering about the name
... border-corner-shape is long
... corner shape isn't obvious that it's related with border radius
... good idea to have border radius defined the fallback
... fallback for diamond is ellipse
... bigger the corner, the more unrelated having border radius as fallback is
... you often want rounding where straight edge join shape
... maybe cubic bezier function
... instead of only four keywords

<glazou> leaverou, clean, simple, understandable at first glance by anyone, probably possible to find better keywords for values

Dean: where are these?

fantasai: ED of backgrounds and borders 4

<Bert> bg-4

Lea: according to ED it only accepts one keyword

<TabAtkins> I wanna ask implementors about cubic-bezier feasibility. Curves are already complicated/slow to implement, dunno if cubic-bezier is lots slower or about the same.

zcorpan: if you want rounded corners on bezel, would it make sense to use border-radius for that rounding?
... what are the different shapes for corner shape?

Lea: scoop which is like negative border radius
... also notch

zcorpan: you might want a little radius on corners of the shape

<glazou> TabAtkins, yes

Lea: we don't know how to do that

<TabAtkins> kk

zcorpan: you should use border radius

Lea: that seems complex

<TabAtkins> That seems *very* complex. (zcorpan's).

Lea: if you just want some rounding, do you need complexity of border radius
... like elliptical?

<TabAtkins> What if you want to bevel your notches? Use border-image.

zcorpan: you're saying too much weight in border radius? Only have one value?

Lea: could apply to one corner

zcorpan: how would it result in elliptical border radiius?

Lea: would have to apply to all three joints

fantasai: bezier function would get you everything you want?
... how do you join different colors etc.

<TabAtkins> Magic, presumably.

Bert: notch just works--it's really simple

fantasai: one other feature
... for repeat there'd be an extend keyword
... if you have gradient somewhere
... you clip it
... the color ends at the end of the gradient box
... it doesn't keep going
... fills background margin area but then stops
... if image has property of paint outside boundary, it would keep painting

<TabAtkins> "background-repeat:extend" lets you size a gradient with background-size but still have it fill the background area.

fantasai: rather than ending at the boundary of the image
... that's one of our random ideas for the spec
... does anyone have other ideas? Multiple borders?

<TabAtkins> Probably low-value, but it's been some time since I recalled why I wanted it originally.

<TabAtkins> border-colors!

Lea: I'd vote for that

<glazou> multiple borders have been in Gecko for ages

fantasai: should we work on multiple borders?

<TabAtkins> border-colors: green 1px, red 5px, yellow 3px; Something like that.

dauwhe: yes!

<TabAtkins> Would probably take some pressure off 'outline' to be a second border.

Bert: use grid and allow regions to have holes in them
... with nested regions

fantasai: that's pretty complicated

Dean: yes!

<glazou> see https://developer.mozilla.org/en-US/docs/Web/CSS/-moz-border-top-colors

dbaron: does multiple borders mean multiple colors within a border?

<dbaron> ...or multiple border styles?

<TabAtkins> Probably. Dont' see requests for mutliple border styles.

<TabAtkins> People just want some friggin rainbow borders.

<glazou> dbaron, not sure the latter is needed

Lea: make it a list

<TabAtkins> Or more seriously, 2 or 3 tone borders.

<TabAtkins> Without the limitations of using inset/outset style.

Dean: make a proposal

<glazou> TabAtkins, old iOS style buttons required 3 or 4 IIRC

Dean: lots of little dragons here

<TabAtkins> I propose we copy Moz's current behavior. ^_^

Dean: which won't happen until you try to write spec

<glazou> TabAtkins, +1

Bert: multiple everything!

<fantasai> TabAtkins, border-colors? No, you really really really don't want that

<dbaron> dbaron: no, only one border radius

Bert: what about border-clip?

<leaverou> TabAtkins: god no, that's awful

<TabAtkins> Hey hey, someone talk about *-1, *-2 longhands for every list-valued property.

<TabAtkins> Hahaha

plinss: may be interesting holes there

fantasai: action item to write up a proposal

longhand for list properties

<dbaron> just wait until we put zero-width non-breaking spaces in all the things

fantasai: if you have a list valued property, then dash-number represents that position in the list

plinss: what if you have -47 with a list of 3 items?

<TabAtkins> Need to make sure that every list has a "null" value.

fantasai: dash ones won't take comma

<TabAtkins> So unfilled values between explicitly-given ones get the null.

plinss: concerned about cascade

<TabAtkins> Why concerned about cascade? This is standard longhand expansion.

<TabAtkins> (I think most (all?) list-valued props alreayd have null values.)

plinss: going back and forth about the proposal
... not time or place for serious discussion
... let's adjourn. Thank you everyone

<TabAtkins> The list-valued shorthand expands into an infinity of indexed longhands. You only serialize up to the last explicitly-given index.

<leaverou> This solves some use cases, but not all

<TabAtkins> Never try to solve all use-cases.

<TabAtkins> Gotta keep 'em hanging on for more.

<leaverou> Quite often you don't have knowledge of all the items in the list and just want to add something in the beginning or end (sort of like a .push() in arrays)

<TabAtkins> Yeah, but that's impossible here. :/

<TabAtkins> We just don't have the structure for it.

<leaverou> so you'll end up with stuff like how people do z-index: 100000000000000000 to be at the top

<leaverou> and no solution for how to add something to the beginning (unless negative indices are allowed)

<TabAtkins> Yes.

<TabAtkins> Correct, these are limitations.

<leaverou> these are very serious limitations

<TabAtkins> "Put me at the top" is always a self-defeating desire.

<TabAtkins> As soon as two places want to be on top/bottom.

<leaverou> obviously, it's better than nothing, but I think it's worth it to try and find a solution that covers at least, I don't know, half the use cases :P

<dbaron> we should figure out additive cascading instead

<TabAtkins> Mine covers half!

<leaverou> dbaron++

<TabAtkins> dbaron: If you think that's feasible.

<leaverou> TabAtkins: Obviously it's difficult to prove that, but I doubt it even covers 1/3

<TabAtkins> leaverou: While we're throwing around arbitrary numbers, I'll assert that it covers at least 4/5

<TabAtkins> Which hits the 80/20 rule and means we don't have to try any more.

<leaverou> you just pulled that number out of your bum, just like I did :P

<fantasai> then you'll need variables for the position of the thing of interest

<fantasai> so property-name-variables

<TabAtkins> leaverou: I thought that's what we were doing!

<TabAtkins> fantasai: Nah, only if you want readability.

<fantasai> SimonSapin: ping

- DRAFT -

SV_MEETING_TITLE

12 Nov 2013

Attendees

Contents

Box generation and elements as regions

CSS Writing modes, Tr fallback

Text module

Charter

Styling left vs. right pages

Charter stuff again

transitions

CSS Shapes

backgrounds and borders 4

longhand for list properties

Summary of Action Items

Scribe.perl diagnostic output