- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 3 Mar 2015 14:23:47 -0500
- To: public-houdini@w3.org
Property and Value Extensions
-----------------------------
- RESOLVED: Start work on CSS Properties spec with esprehn,
gregwhitworth, TabAtkins, glazou, and Shane as editors.
- RESOLVED: New spec will be "CSS properties and values
extensions" (same set of authors as previous
resolution).
Font Metrics
------------
- RESOLVED: Start working on Font Metrics Extensions module with
SteveZ, astearns, and ChrisL as editors.
===== FULL MINUTES BELOW ======
Scribe: roc
Property and Value Extensions
=============================
Property Extensions
--------------------
TabAtkins: Custom Properties spec optimizes for variable setters.
TabAtkins: Need a variables level 2 to help us with custom
properties ... specify initial value, inheriting,
animation behavior.
TabAtkins: esprehn and Ojan have put thought into custom
properties being used to drive layout and other things.
esprehn: current shape:
esprehn: [writes "registerProperty({ name : "width", syntax :
CSSLengthSyntax"] ... syntax a function that takes a
token stream and returns an object
esprehn: "inherit: boolean; iniitalValue: new Length(0);"
esprehn: TabAtkins wants JS Value Objects here, they don't exist
yet.
glazou: In the syntax line, your function returns an object, but
your initial value is only a length?
Ojan: Syntax function needs to return an object, an object of type
Length.
esprehn: "invalidation: Paint, Layout, Style, none"
esprehn: We'd probably just make initial value a string.
TabAtkins: Thanks.
<TabAtkins> Earlier sketch for a better CSSOM API, based on Value
Objects: http://www.xanthir.com/b4UD0
<TabAtkins> I presented this to the CSSWG last year.
esprehn: Layout makes sense for custom layout, Paint could be like
Color, style means recompute style.
TabAtkins: It lets the engine know what kinds of things to update.
krit: How do you handle animations?
krit: You cannot define custom types?
shane: Yes, you can.
esprehn: "type: CSSLengthType"
Ojan: Layout just means "changes size and position"
esprehn: [writes "invalidation: geometry, paint, none"]
esprehn: There's AnimatedType, e.g. LegnthAnimatedType. There's a
resolve, which takes values and returns a fixed value,
something the engine understands.
esprehn: AnimatedType has an invalidate().
esprehn: Just keep invalidating and we'll come around and get a
different value.
shane: Can you just use Web Animations?
esprehn: That's okay as long as output type is something Web
Animations understands.
shane: Interpolation is hard, we should leverage Web Animations.
shane: We should expose an interpolator for each type.
krit: The function is supposed to register new properties. Or to
register properties already defined?
esprehn: Register new properties.
esprehn: [writes "name: x-width"]
esprehn: e.g. a width that always divides by 2.
krit: If you create custom properties, will they have -- at the
beginning?
TabAtkins: Yes.
esprehn: [writes "--width"]
esprehn: When is it safe to run script? Uses a separate Realm.
esprehn: ES6 realms. Separate scripting context. Register
properties inside of them. You can call in when it's
normally unsafe to run script.
<shane> Quick note: realms are deferred to ES7 :(
dino: When do you do that? Does registering a property re-parse
everything?
esprehn: We don't discard them. Or we could make sure you have to
register before.
dino: What if you want to override?
esprehn: I think it would be extremely powerful.
dino: We don't provide that currently.
esprehn: People will want to add new things to existing properties.
plinss: People may want to extend length so you don't have to
override everything that takes a length.
dino: I think we should address the case where the dev wants to
extend the browser support for an existing property.
esprehn: You can compose existing types together.
esprehn: The only complication not resolved is how to do
invalidation. Need to tell the engine when to reevaluate
these properties.
esprehn: We need a invalidateProp(name) API. If the inputs change,
you need to be able to invalidate all the uses of the
property.
shane: Lengths can expressed as 15em. When does that get computed?
esprehn: "syntax" is the parsing phase. "type" is the resolution
phase.
shane: Can you specify custom types?
esprehn: Yes, there are built in types and you can specify a
custom type.
shane: CSS has notions of type unioning and subclassing. Can you
capture that?
esprehn: A Syntax function can return a different type every time.
esprehn: e.g. you could return strings or lengths and handle those.
shane: Your syntax function has to return whatever type is
appropriate for each union possibility.
esprehn: You could do "union(length, string,...)"
esprehn: The syntax is a function that consumes a token stream and
emits type objects.
TabAtkins: We need some way to extend basic parsing functions, e.g.
to introduce a new fx unit that's a type of length.
everything that's a length can accept it now.
TabAtkins: Custom values will be another bit of extension to make
this super usable.
[shane takes photo]
esprehn: You can extend this pattern for things like custom @rules
... registerCustomAtRule ... parses a token stream and
gives the body to a rule parser that parses out the rules.
TabAtkins: I'd like to create CSS syntax for SVG and just parse it
out of the stylesheet.
dino: Let's do that anyway
TabAtkins: Convert SVG into CSS compatible syntax
roc: ewwww
esprehn: We just want to do strings.
esprehn: This design is nice, you can compose syntaxes and length
values.
esprehn: We expect custom properties level 2 to roughly look like
this.
TabAtkins: Thanks Elliott.
Rossen: Who's going to work on that?
Rossen: The property part.
shane: Makes sense to split it into two specs?
Rossen: Probably.
TabAtkins: Probably
Rossen: Who other than shane and Tab want to work on it?
glazou: I'd like to be a little bit involved.
gregwhitworth: me
Rossen: esprehn, gregwhitworth, TabAtkins, glazou, Shane ...
that has it pretty well covered.
Rossen: Proposed resolution. Anyone object to starting work on CSS
properties?
Many: No.
RESOLVED: Start work on CSS Properties spec with esprehn,
gregwhitworth, TabAtkins, glazou, and Shane as editors
Value Extensions
----------------
Rossen: TabAtkins, you want to talk?
TabAtkins: I have vague ideas.
glazou: Many ways to see the result of parsing a value --- a
stream of tokens , a hierarchy of tokens, a parsed object?
glazou: What kind of descriptors can extend the value space?
glazou: Either an ID coming from the registered property, or an ID
coming from a parser looking, extending the value space.
glazou: If the new property is a CSS length, provide its syntax.
glazou: If the final computed value has to be computed from a
specified value, you need a function somewhere.
glazou: Do we want to extend existing properties? How do we extend
a property that was registered from JS?
glazou: Say you wanted to add something to the width property? Do
you want to do that or add your own width property?
roc: Adding something to the width property composes better.
glazou: Yes.
glazou: This will impact the way we extend values (pointing at
property extension on board).
glazou: Notions of properties and values cannot live separately.
Rossen: Anyone have a different opinion?
Rossen: will it help to have them together?
glazou: Yes.
<franremy> A question that's worth asking: should css provide
elegant solution taken alone, or should it provide
acceptable solutions made elegant by a pre-processor
glazou: Things on the whiteboard right now will be reused.
glazou: Two documents will be synced, the editors will probably be
the same.
<franremy> I'm not sure how we can add new values to width that
wouldn't be aliases if JS can't intervene at layout
time to compute to an understood value
dbaron: With value extensions, if someone adds a new type of
length value, how do you deal with invalidation?
dbaron: A lot of what's interesting about new length values is
that they're derived from other different things.
dbaron: Something would have to drive it.
glazou: Are you extending a type of value, or are you extending a
type of value?
glazou: New length unit is different from adding "red" to width.
TabAtkins: With regards to units, we'd have a similar
"invalidateUnit()"function.
TabAtkins: It'll monitor, detect changes, call invalidate, the
engine will find out where it's used and redo it.
<franremy> TabAtkins: 'em' is local, not global.
Rossen: If we add a "gm" type, size of g letter in your font, how
would that work?
TabAtkins: That's especially hard because we don't know the font.
TabAtkins: We'll monitor for font changes and figure out when that
would be different.
TabAtkins: The types that would change based on where in the tree
you are. It requires more thought.
TabAtkins: Custom types for vw/vh would be easier, same across the
page.
TabAtkins: The tree-based ones have complexity we haven't thought
through.
shane: It's not just based on tree, but based on other style
values.
shane: Avoid chaining custom style computations to support this
kind of thing.
shane: Would be nice to avoid it.
TabAtkins: We're extending value space for existing properties.
TabAtkins: You register yourself for "display": handle things
yourself and turn it into a new display.
<franremy> I don't want to seem overly negative, but it seems
we're going into a too deep space here
<franremy> It's easier to use custom properties and your own JS to
override the style
<franremy> You write "width: 2gm", your preprocessor emit "--
width: 2gm" and your client script handles the
invalidation work and emits "width: Xpx" for affected
elements
<franremy> I don't think it's "the" option, just an easier path
forward
<franremy> ... We may reconsider better api once we know what devs
need and do use (except if you believe we have that
experience already)
<TabAtkins> franremy: That doesn't compose great.
TabAtkins: Registering new units sounds OK.
glazou: Adding new units could be level 2.
glazou: We don't close the door, but some things will take more
time than others.
esprehn: I consulted our implementor, we specify dependencies and
reevaluate when font changes.
esprehn: Besides just units, you want functions like calc().
esprehn: Otherwise people will use bitfields to encode functions.
TabAtkins: I've given it some thought but needs more ideas.
Rossen: Anything else on this?
Rossen: Any objection to adding "Values" to the CSS properties
module?
[no objections]
RESOLVED: New spec will be "CSS properties and values extensions"
(same set of authors as previous resolution).
<franremy> TabAtkins: I don't think so; at least I'm pretty sure
it would if we define a CSS Parsing API. But, ok.
<TabAtkins> franremy: What I mean is, if two things want to define
width extensions...
<franremy> TabAtkins: no, I would just move coordination on "--
width" to user land; when we understand what frameworks
do for coordination, then we try to write a standard; I
think we go backwards here because we design without
any realword experience (we can continue this on public-
houdini if you prefer)
Font Metrics
============
Rossen: The next set of topics: font metrics, input extensions
rbyers: I can do that.
shane: It would be better to wait for Ian.
rbyers: Let's wait.
Rossen: OK, font metrics.
Rossen: I'm looking at the notes. They were put forward by
astearns and SteveZ,
Rossen: And Chris.
Rossen: They rehash motivation and have an example of dropcaps.
astearns: We don't know what font is being used.
astearns: The proposal I've heard is to add something to the Range
object that gives you the first used font for any
particular range.
astearns: If you're not concerned with what each glyph is range
for the first one, make assumptions for there.
astearns: If you want, you can get all the information you want.
ChrisL: Is there never a case where a single character maps to two
glyphs from different fonts?
esprehn: Yes.
roc: No.
roc: Combining characters are different characters.
roc: Indic characters are separate characters.
astearns: Even if there's a situation where a glyph is composed
from different fonts, we can still choose the first.
ChrisL: OK thanks.
esprehn: I don't want to extend the range API.
esprehn: Ranges make the whole engine slow.
esprehn: You want some read-only representation.
esprehn: We should design something new that's not live.
johanneswilm: How does this interact with font loading? at all?
TabAtkins: I don't think so.
astearns: For a font, I want metrics for that font
astearns: The font loading API could return the same object, with
metrics.
ChrisL: Consider a stylesheet with has a font stack, upi need to
load a font off the Web, it will be slow. Suppose I'm
using a fallback font meanwhile. At that point, someone
calls the new API. What do they get?
astearns: I would hope you get the current answer.
astearns: Then, later, you get the new answer.
<dbaron> I agree with astearns.
<dino> I agree with dbaron.
astearns: Does the idea of using same font object for font loading
and this new API make sense?
TabAtkins: Yes.
TabAtkins: It needs extension to local fonts, there's an issue in
the spec for that.
astearns: I do understand the rationale for DeadRange, I'm not
sure the displayed font is sufficient justification for
it.
Ojan, esprehn: Discourage anyone from creating a range.
astearns: For a fragment tree, you return a list of ranges that a
fragment displays. So let's not do that.
SteveZ: Call it FreeRange not deadRange.
SteveZ: Another use is, if I want pseudo elements by looking at
what's inside, I'd like to look at different ranges.
SteveZ: There's a number of examples where we parse the content
when generating pseudo elements.
esprehn: Range has to be compatible in restricting ways. With
something new we can express pseudo elements. We can't
change what Range does.
esprehn: IE had a different range object that had a lot of useful
stuff. select line, select word.
Rossen: We still have it ... for the record.
dbaron: I think when we have issues with live vs dead objects,
there are disadvantages of both.
dbaron: Dead objects need copying.
dbaron: An API that didn't give you an object wouldn't have either
problem.
dbaron: A live object you need to keep it live over time.
dbaron: A dead object must copy everything you might need over
time.
esprehn: You'll need a similar circus for objects passed into
custom paint/custom layout.
esprehn: You neuter objects when a call returns.
Rossen: We're off topic of fonts and designing FreeRanges
Rossen: Should we design FreeRanges?
SteveZ: dbaron's comment is critical. The issue isn't whether it's
dead or alive, but how long the reference persists and
when you can throw away the information.
SteveZ: esprehn's suggestion of transaction-based is useful.
astearns: Should this be in fragment tree scope?
Rossen: I think so.
Rossen: I'm not sure. Could it also be its own module.
astearns: The fragment tree will likely need to use it,
astearns: Being able to access generated content.
Rossen: I wouldn't disagree
<franremy> (fwiw, I finally found the glyph image I was looking
for in the past when discussing text & font
measurements: https://i-msdn.sec.s-msft.com/dynimg/IC520421.png)
<TabAtkins> franremy: Niiiice
Rossen: Let's come back to font metrics.
astearns: The font loading API returns a font object, and the
font-getting API returns it, and this object should have
some font metrics --- cap height, baselines
astearns: It's really useful for scripts that position things
based on font information,
astearns: Should we try to be reasonably complete?
TabAtkins: We know what CSS needs today. Go for that basic list.
SteveZ: The only thing that's hard is ascender, descender
ChrisL: That's not hard. Just get in line if you don't want
typographic ascender/descender.
<ChrisL> font.ascender.osx.yosemite
<ChrisL> http://www.w3.org/TR/2008/REC-CSS2-20080411/fonts.html#ascent
SteveZ: All the definitions have some particular use.
Rossen: Does that matter?
SteveZ: Yes.
Rossen: The first font will have ascent and descent.
astearns: The font object just gives you some input data for
lineboxes. Doesn't give you everything.
astearns: We might need to add information to line boxes
themselves.
Rossen: Let's keep lineboxes and font metrics separate.
astearns: I agree.
Rossen: Line boxes have multiple boxes and fonts.
Rossen: Font objects have just one font.
SteveZ: There's four definitions of ascender/descender values, per
font. Different values depending on when fonts overflow
embox, etc
dbaron: Our font code does some fun things to figure which values
to use, trying different tables. it's not very
interoperable.
dbaron: We should try to define it in a way that allows such
variation.
SteveZ: Fine. Just a warning that it's a pitfall.
SteveZ: You need ascender/descender as well as baselines.
astearns: The spec has to say how you get these in these odd font
situations.
esprehn: We should discuss custom layout. Information needed by
line-grid, snapping etc.
ChrisL: It's not just drop caps.
esprehn: Drop caps sounds like custom layout.
SteveZ: Waiting for custom layout for drop caps is not desirable.
astearns: I need the cap height to set the size.
krit: Font metrics are also necessary for canvas.
esprehn: Canvas has measureText already.
roc: It's not much information.
SteveZ: Typographers are fussy.
<esprehn> What information is missing from
https://developer.mozilla.org/en-US/docs/Web/API/TextMetrics ?
ChrisL: We're calling for volunteers.
TabAtkins: Not me.
ChrisL: Me.
Rossen: We'll get there.
SteveZ: Information is not always available.
Rossen: Anything else?
ChrisL: I want to get this going so we can get feedback at
typography conferences.
Rossen: Who's interested in working on this?
Rossen: Besides ChrisL and astearns?
Rossen: SteveZ.
Rossen: Proposed resolution: start working on font metrics, unless
there's objection.
[no objections]
Rossen: Proposed resolution: SteveZ, Alan and ChrisL will work on
Font Metrics Extensions module
RESOLVED: Start working on font metrics with SteveZ, astearns, and
ChrisL as editors
astearns: One thing to go in fragment tree spec. When we expose
line boxes, line box needs to tell script where it's
placing the dominant baseline.
SteveZ: It needs to expose line box baseline even if there's
nothing there.
Rossen: The box tree editors will ensure that.
Rossen: Let's break for lunch
<TabAtkins> <br type=lunch dur=indefinite>
Received on Tuesday, 3 March 2015 19:24:15 UTC