- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 08 Apr 2010 00:15:05 -0700
- To: "www-style@w3.org" <www-style@w3.org>
CSSOM
-----
- Discussed integrating CSSOM with other specs: both defining APIs and
using consistent terminology. Anne actioned to write a list of inconsistent
and missing terms.
- Terms "property value" and "component value" suggested to distinguish the
different uses of "value" in the specs. (Both can be shortened to "value"
where non-ambiguous, preserving current spec text in most places.)
- Discussed various ideas for making the CSS Values API more user-friendly
- Set up a wiki page to track CSSOM numbered constants, to help us avoid
conflicts in the specs. <http://wiki.csswg.org/spec/cssom-constants>
- Discussed CSS editor requirements for CSSOM APIs
- RESOLVED: Alex and Daniel will start a CSS Editing Task Force for discussing
issues relevant to CSS editors and defining their requirements for
an object model.
Miscellaneous
-------------
- Reviewed open issues on CSS3 color so that dbaron can close them.
- Some discussion on animating gradients
- RESOLVED: Rename 'image-fit' and 'image-position' to 'object-fit' and
'object-position' since SVGWG considers the former ill-suited
to their use.
- Tab Atkins ran a long discussion on CSS layout, some specific use cases,
and the relationships between template layout and tables, and between
flexbox and tables.
- dbaron proposes calculating available height similar to available width,
which would allow percentage heights to work even when the parent has
'auto' height. Since this would be backwards-incompatible, it seems likely
this will be used for the 'fill' keyword instead.
- RESOLVED: For CSS2.1 Issue 156, use "Once the font family's weights are
mapped onto the CSS scale, missing weights are selected as follows:"
as the introductory sentence, then add bulleted list from
http://lists.w3.org/Archives/Public/www-style/2010Mar/0538.html
- env() date values changed to 'local-date', 'local-time', and 'local-date-time'
since they are formatted according to the system locale
- 'border-clip' property moved from GCPM to css4-backgrounds
~fantasai
====== Full minutes below ======
Present:
Tab Atkins
David Baron
Bert Bos
Tantek Çelik
Beth Dakin
Arron Eicholz
Elika Etemad
Simon Fraser
Sylvain Galineau
Daniel Glazman
Brad Kemper
Håkon Wium Lie
Chris Lilley
Peter Linss
Alex Mogilevsky
David Singer
Anne van Kesteren
Sam Weinig (Apple)
Steve Zilles
Scribe: TabAtkins
CSSOM
=====
plinss: First topic this morning is CSSOM.
plinss: And impact on other specifications.
Integrating CSSOM and other specs
---------------------------------
anne: While editting the spec, I noticed a few problems.
anne: One is that there's no real data model.
anne: The CSSOM is supposed to have a represetnation of what the
stylesheet is like.
anne: But in the CSS specifications there is no clear mapping from
the syntax to the data model behind it.
anne: A clear example is the font-family property.
anne: I think most impls internally represent them as strings, but
that's not stated anywhere.
anne: So when you try to design a value API, you have to state it there.
fantasai: The font-family syntax I put up said explicitly that Computed
Value should be strings, so I agree.
anne: We need Specified Value too. Basically, what you get after parsing.
anne: Two, there is surprising lack of consistency in the interface names.
anne: Like, an interface named CSSStyleRule, that maps to a css ruleset,
but that term isn't really defined in the grammar.
anne: I'm not sure if we actually want to change the CSS spec, so this
makes sense, or what?
anne: What I'm asking is if we want to adjust the terminology so that
it's consistent between CSS and CSSOM.
anne: I'm guessing we can't change the interface, so it would be CSS
that changes in a few points.
anne: Also, CSS spec refers to a lot of things as just 'values'.
anne: But in CSSOM, that needs to be something separate, like a 'value
component', because a property can have multiple of them.
anne: The CSS spec is kind of loose with those things.
howcome: I agree, the spec shoudl change there.
ChrisL: The spec is focused on taking text into CSS, not in reverse. The
OM spec should define that.
fantasai: No, I think the spec is ambiguous in a lot of places.
Bert: There is context where we call many things values, and if we
introduce multiple terms for these it would be too confusing.
glazou: I heard the same thing when I introduced the [multiple types of
selector groupings]
dbaron: I objected to that at the time because a term was actually being
*redefined*.
anne: There are other specs where there are multiple concepts being
referred to as the same thing. And that's fine, as long as there's
a disambiguation at some point.
Bert: That disambiguation is present in the <> forms.
fantasai: I recommend 'property value' and 'component value', so they
both abbreviate as 'value'.
howcome: Agreed, we shouldn't be changing tons of terms in the spec,
but the disambiguation is needed.
ChrisL: Question about CSS color component. Is that used a lot, and is it
memory constrained?
anne: We can change it if necessary. Specifics are still mutable.
<ChrisL> would prefer to see attribute long red; instead of attribute
short red; - color bit depth is increasing now
anne: I can work around the lack of terminology, or invent my own, but
it would be nice if it matched up.
fantasai: Do you have a list of terms that you need?
anne: No.
fantasai: I think the next step is to come up with that list of terms,
so we can make sure it's defined somewhere.
anne: The grammar uses the term "statement" to refer to @ rules or
rulesets, and the CSSOM spec refers to them as "CSSRules".
fantasai: I think CSSOM should be changed there.
anne: [describes the terminology, and how it can't be changed at this point]
<ChrisL> http://en.wikipedia.org/wiki/Deep_Color
fantasai: I'm not saying change the interface name, but you can say that
"CSSRule" refers to what CSS calls "statement".
anne: I tried to do that before, but it didn't make much sense to me.
TabAtkins: I'd heard you talking before that it would be useful for specs
to define how they should be reserialized, frex how to turn a
gradient back into a string?
anne: Yeah, something in the future is for the CSS specs to be aware of
the CSSOM in their writing.
anne: Like when you serialize the margin property, do you do as few values
as possible, or write it out fully?
ChrisL: I agree with anne that specs should be aware of the CSSOM and
write things in respect to that.
Bert: I think that the CSSOM should refer to CSS, not the other way around.
anne: There are several CSS specs that include interfaces.
Bert: Yeah, I think those should be taken out.
anne: I think it would be acceptable for me to have an ever-growing OM
spec, but that isn't compatible with how the w3c does recs.
plinss: I think we agreed that specs going forward would define interfaces.
fantasai: We agreed that they would define serialization, not that they
would define interfaces
plinss: It makes sense for the OM to define interfaces that are common
across many specs, but we also shouldn't wait for a monolithic
OM to include all the specialized interfaces that a module might have.
Bert: it doesn't have to be monolithic, you can publish a separate spec
for each module's OM
plinss: We can have two conformance classes, if you support the OM you
have to support X and Y, if not you just have to support X.
arronei: It's just a few lines in the conformance section to add the
conformance requirements.
fantasai: But we have several specs in CR that don't include an OM section,
and I don't want to pull them back to add that.
fantasai: We could create new OM specs just for those.
dbaron: That's a lot of specs.
anne: I'm fine with including that stuff in CSSOM.
fantasai: Half the generic stuff isn't even defined yet, and as for me I
have *no clue* what to put in for the OM section
fantasai: If you can give me a template that I fill in to add OM stuff,
I can do it. But until then, I don't want to have to add them
to the spec.
plinss: The person editing a given module may have no clue what the OM
requires, what's a good idea, and so in that sense it may make
sense to have a separate OM module for it.
anne: For value APIs, new values, we do want interfaces.
Bert: But for new keywords or lengths or numbers, those already exist?
anne: Yes.
anne: And for backgrounds, it might be sufficient already since it's a
comma-separated list.
anne: For transforms, animations, they all introduce properties with
slightly more complex values that need new value interfaces.
plinss: Any new @ rule needs an interface. And depending on how granular
we get with the API, we may need to extend it for more things.
anne: And the Images module, it would need to define new interfaces for
the new things in there.
plinss: Any conclusions on this?
CSSOM Numbered Constants
------------------------
Bert: There was something about numbering, and them having to be unique.
Is there any way to avoid this?
anne: The pattern that is used all over most APIs is to use numbered
constants.
anne: For CSSRule we can't change the pattern. For CSSValue I suppose
we could, but we haven't discussed it yet. I think it makes sense
to keep it with the familiar way.
Bert: Does every @ rule need a new number then?
anne: If it exposed the same information as another @ rule, it can
reuse a number.
plinss: @page introduces multiple different @ rules, which would all
need a number.
anne: We have @page and friends, @font-face, @media, @import, and
stylerules, all with different numbers.
anne: So far new @ rules probably want a new number.
anne: Like all the @margin rules might share a single number.
Bert: Numbers need coordination, which I think we should try to avoid
if possible.
anne: I think we should just try to coordinate.
anne: We managed to do it pretty well for DOM Exceptions.
Bert: Who do we have to coordinate with. Just here, or do we have to
coordinate with SVG?
anne: Officially SVG has to coordinate with us, but I've reserved
some space for [something SVG-specific].
[talk about different impls stomping on numbers]
<fantasai> make the constant point to a UUID? :)
ChrisL: We need an easily referencable page where we can refer to this
and stop conflicts.
[discussion on using a wiki for coordination]
anne: There is a way with WebIDL that you can extend an interface.
Bert: You can reference a wiki as an informative reference, but not
a normative one.
anne: Yeah, sure, it can be informative. That's fine.
fantasai: So these numbers are all named constants, and people are
supposed to use the names?
anne: Theoretically.
fantasai: Can we have the named constant return something other than
a number?
anne: No, the type is a short.
anne: Same thing is done with, say, Nodes, but that doesn't chang
very often. CSS adds new things somewhat more often.
plinss: If you're implemeneting something early, like Paged Media in
webkit, should prefixed versions use the same final number?
anne: No, it says right now that the CSSWG reserves the first 1000 values.
plinss: So proprietary versions should use a number above 1000.
ChrisL: Will implementations switch from >1000 to <1000 when they get
standardized?
anne: When they drop the prefix should be fine.
plinss: Should we try to reserve blocks for individual browsers?
fantasai: Authors should just use the named constants.
smfr: Should the named constants be prefixed?
anne: Good question. If you don't prefix, there's a chance that code
would still work when it moved to standardization. But if we
changed anything, then it could break.
anne: Ideally we'd iterate fast enough that we don't run into that situation.
anne: If people want to write their thoughts to the list, it would be fine.
ACTION: anne to set up wiki page to list CSSOM constants for coordination
<fantasai> anne, http://wiki.csswg.org/spec/cssom-constants
plinss: Did we come up with a decision for how to do OM sections for new
modules?
anne: I think for specs in WD, it would make sense to have them in the
spec. But perhaps we should defer that a little and discuss the
value APIs first.
CSSOM Values APIs Part I
------------------------
anne: So currently for the value apis you get a CSSStyleDeclaration object,
with a long list of attributes that represent CSS properties.
anne: And they all return a string.
<smfr> http://dev.w3.org/csswg/cssom/#the-cssstyledeclaration-interface
anne: The initial idea we had was that instead of a string it would
return something special, that would act like a string but would
allow extensions.
anne: I brought it up on public-script-coord, where ecmascript guys
hang out, but they didn't think it was a good idea.
anne: [some examples of breakage]
anne: Based on that we have a new idea. The CSSStyleDeclaration object
would have a new property called values, which would return a
CSSStyleVales object.
anne: It would act like StyleDeclaration, but when you access a property,
it would return a CSSValue object rather than a string.
anne: The object would have a cssText attribute that lets you set a string
or get a serialization, which is equivalent to the existing API.
anne: So then the question is how to define the new value APIs on top of that.
anne: I think we want interfaces for the components.
anne: So an interface for %, for lengths, for color values
anne: And if you have a width property, that supports both lengths and %,
the object returned would implement both.
<smfr> http://dev.w3.org/csswg/cssom/#the-cssvalue-interface
anne: It would have an .px and .em accessor, but also a percentage accessor
so you could set and get %.
anne: So how far do we want to go? Each and every property, or start out
with a limited subset?
anne: And do we need a "type" like CSSRule so you can figure out what kind
of value was set?
anne: Like, ComponentValue would return a type of lengthEm, lengthPx, etc.
Would that be a short, like the other types? Or a string that could
be interned, which could be more extensible.
anne: If we did numbers, then if we start filling in spots, say if we
added a new length, it could be very separated from the other lengths.
px could be 12, and rem could be 100.
plinss: As long as people use names, the numbers wouldn't matter much anyway.
plinss: We could also reserve blocks.
szilles: So what's the downside on strings?
plinss: Performance.
anne: If they're interned, it would just be pointer comparisons.
plinss: I'm concerned more with author script stuff. Will I be doing a
thousand string comparisons, or a thousand short comparisons?
smfr: Potentially, we could have them do atomic string comparisons.
<fantasai> You might also want to answer things like "is this a length
(any kind)" or "is this a percentage"
anne: Can we define constants that are strings?
Sam Weinig: Nothing theoretically wrong with it. The strings are essentially
immutable.
anne: How do we, at the object level, distinguish between value components
and things that are separated lists of value components.
anne: Like, background-position takes two values.
anne: So how do we represent that?
plinss: I think it should return a backgroundPosition object that has two
values.
glazou: We could return an array with the components in the order they appear.
plinss: Or an object with queryable values, so it's more extensible.
anne: Also, do we want a special interface for shorthands? Like margin
should we implement a margin property or only margin-left,
margin-right, etc?
dbaron: Also there are some non-shorthand values that are rather complex,
like shadows or border-image.
plinss: We could pretend they are shorthands and expose them as such in
the object model.
anne: But then we're stuck if a property later becomes a shorthand.
fantasai: Like we're going to do with whitespace.
smfr: I think the hash-table approach would work for shorthands.
fantasai: So, for the 'margin' shorthand you'd be able to look up the
'margin-left' value and 'margin-right' value?
<dbaron> A bunch of the complex-valued properties are arbitrary-length
lists, which are hard to represent as shorthands.
glazou: If possible, harmonize things across properties, so "x" is the
same for all the values.
sam: In that case you wouldn't have named components, but rather numbered
components.
fantasai: You could have named components that are lists
plinss: We've already had things that take a single value and turned them
into lists of that value.
anne: A simple example would be background-image, which would return a
css url, but also have a way of getting a list of css urls.
dbaron: I think the single-value thing should only return the single
value if there *is* a single value, and otherwise do whatever
happens when it is being a wrong type.
glazou: Recursively nested values.
<dbaron> What's interesting with url() values is often an absolute URL
rather than a relative URL relative to the style sheet.
glazou: In the case of color, rgb returns a single color value, which
also has .r, .g, .b.
glazou: etc.
glazou: Editors will *massively* use CSSOM if it is easier to use, but
not if they have to reparse/rebuild values into a useful form
every time.
anne: I think you want interfaces for this.
CSSOM for Editors
-----------------
glazou: Another thing I want to see in the CSSOM, some things just for
editors.
glazou: Like not just the reserialized text, but the original parsed text.
glazou: Like if the @style attribute has something wrong, browsers
currently throw it away and it's hard to get at that.
glazou: Browsers don't need that, so they can just return null or whatever,
but editors are allowed to return the full thing.
sam: Is that confusing for authors?
anne: If it's not for browsers, do we need it in the spec?
glazou: Yes, if you have multiple editors you want interop.
smfr: So what if someone wants to write a javascript editor tool in a
normal browser?
TabAtkins: Like FireBug would love this.
smfr: Isn't this what UnknownRule is for?
dbaron: UnknownRule was designed by someone who doesn't understand CSS
parsing.
plinss: We could just tell browsers to *not* throw away these things.
sam: For Firebug and Web Inspector we use internal hooks, and don't
need the specced thing.
arronei: What if I'm a brand new editor for HTML and CSS? This is where
having a spec would be great.
sam: The issue is that it would slow down browsers. We can either decide
that we have it anyway, or not.
smfr: We could have a runtime switch controlled by the OM. It's weird,
but shrug.
* ChrisL bijectively
[discussion about editors and browsers throwing things away]
glazou: A live editing tool for HTML and CSS right now is impossible
because of this limitation.
<fantasai> I don't think UnknownRule or UnknownAnything is necessarily
the way to go. You should have a unified API insofar as
possible. You can have MalformedRule or something for things
that can't be parsed...
<fantasai> But if it's clearly propertyname : valueIcan'tUnderstand, you
should get an api that works the same as for color: blue;
<fantasai> and returns the propertyname and the string representation
of the value
anne: We've had this discussion before. I thinkwe might want some editing
features already, and we might want to move those upward.
anne: But I think we need a more concrete proposal for how to modify the
OM for editors.
glazou: concrete example: firebug, dragonfly, etc, from a given element,
you can climb up the cascade to find which element triggered
the current rule. But it's not standard!
glazou: We all use proprietary interfaces to do it.
anne: That's something we can definitely standardize.
anne: For changing the parsing engine we need more detailed proposals.
dbaron: CSS is harder to get right because you've got comments anywhere.
glazou: My own impl preserves comments between rules and between
declarations. But that's a big bloat for browsers.
plinss: in the early days of gecko I made something that preserved all
the information, and if it found a comment somewhere odd, it
would shove it forward to the next 'normal' point for comments.
glazou: That's not perfect, but yeah it works.
glazou: I perfectly understand the browser's concerns wrt bloat and footprint.
glazou: But adding nothing at all shuts the door to a whole class of
live applications on the web that are everywhere these days.
glazou: Wikis are everywhere, styles are everywhere, and we still can't
edit styles.
anne: We can largely edit it. Not every property, but most of them.
anne: I think most editors let you edit the text file.
ChrisL: Because the OM isn't up to the task yet.
howcome: That's what the spec is trying to fix, right?
anne: For WYSIWYG you don't need comments, so I see some conflicts.
howcome: I think Anne is trying to get this done, and you're being
aggressive to him.
glazou: I'm not aggressive, I love what you've done, I just want to see more.
smfr: You should both be able to edit the text directly, and move to
doing sliders and such, and go back. We need that for our editor.
plinss: The Web has a legacy of documents being editted by hand, and we
can't just throw that away into a non-hand-editable spec as
soon as machines touch it.
sam: I think that Anne's work doesn't impede any of this.
glazou: I think that when OM was first created, editors weren't in
anyone's mind.
plinss: Gecko actually got built to be an editor. The fact that it
turned into a browser is happenstance.
plinss: While we were designing that stuff, we saw the convergence
of editors and browsers as the web develops.
plinss: We eventually realized that the only difference between gecko
being a browser and being an editor was a stylesheet.
anne: We just need to find what the cost for benefit is. If browsers
already preserve comments, we can look into that, but we can't
put comments everywhere.
anne: And what about whitespace?
glazou: What's important is maintaining what was entered. Like for
border-radius, you can't just have everything but the
-moz-border-radius thrown away just because that's the only
one that was recognized.
anne: If someone can define what sort of string would be produced,
and browsers are okay with the footprint, we'd be okay.
fantasai: I think you would start parsing, and get the property
name as an ident.
plinss: ident, colon, stuff, semicolon.
sam: So basically we'd have something more than unknown rules, for
unknown declarations too, and a browser mode that would change that.
fantasai: For all rules too.
alexmog: Let's have a CSS editing requirement TF and come up with a
list of requirements for object model, for editors, and
other features, so we can figure out what the goals we're
trying to achieve are.
alexmog: Right now we're designing a partial object model. We can
possible change the OM into something that does what we
need, or something completely different for editors.
alexmog: [he talks to VS people twice a year about this, various requests]
RESOLVED: Alex and Daniel will start a CSS Editing TF.
anne: I think if you want it to end up in browsers you want it to
reconcile with the OM.
glazou: Yes.
alexmog: I'm not quite convinced if a high-powered editor needs to
be built on the object model.
alexmog: Like if there are only a small number of companies building
major editors, they may not need a full OM in favor of just
a more editing-friendly interface.
plinss: The same thing happened with HTML. First browsers didn't
remember anything about the HTML, and the object model got
thrown away as it was parsed. But we gradually kept around
more of the model.
plinss: So we need to extend this over CSS.
plinss: We didn't build the DOM to build an editor, it just happens
to also be useful for this.
glazou: We know there are some things that we always can't do, like
preserving comments everywhere.
<bradk> It would be nice if the various developer tools (FireBug, etc.)
preserved (and flagged somehow) properties and values that had
typos or spelling mistakes, so that they can be edited and
fix in-browser.
<dbaron> glazou, http://dbaron.org/css/timing-function-graphs
CSSOM Values API Part II
------------------------
anne: We need to have the hash-table concept for values that are
space-separated, and a list concept for values that are
comma separated?
anne: for margin, you'd return a hashtable-like interface with each property
TabAtkins: We just need to make sure that properties that later
turn into shorthands still work by themselves.
sam: My suggestion to anne was to take some of the more complex
examples of syntax, break it down into concrete proposals,
and put that on the list.
fantasai: I suggest border image.
glazou: Font stuff too.
sam: Whatever is *as hard* for anne as possible.
fantasai: shadows and the content property.
ACTION: anne to produce concrete examples of complex properties and
put it on the list
smfr: We also need to define if every property has a canonical form.
If someone specifies 'ease' in a timing function, do they get
'ease' back or a bezier function?
plinss: As much as possible we should return what the author specified.
anne: We could have a .keyword value that would return a keyword if
the value corresponds to a keyword.
glazou: Same with color - if the author says "red", do we do 'red',
'#f00', rgba(255,0,0,1), or what?
anne: Browsers try to store as little as possible right now.
plinss: For a browser, no matter what gets specified it'll be stored
as a [r,g,b] or whatnot, and I'd want back what the author
actually said sometimes if possible.
anne: We might have a bit that says if the color was originally a
keyword or whatnot.
anne: Currently there are a number of normalization rules for various
things.
plinss: I'm concerned that some of them go too far.
plinss: If you have multiple ways to pull a value back out of the OM,
that's fine, but when serialized to text it should be as close
to what the author said as possible. We can change "Red" to
"red", don't need bit-for-bit, but the spirit should be the same.
smfr: One problem I have with gradients is that there's no canonicalization.
TabAtkins: Agreed, I need to add that.
CSS3 Color Issues
=================
<dbaron> http://wiki.csswg.org/spec/css3-color
<smfr> editor's draft: http://dev.w3.org/csswg/css3-color/
dbaron: Currently the editors draft addresses most of these issues,
but I haven't yet replied to the emails with these comments.
dbaron: First is issue 5.
dbaron: At first I thought it was someone who didn't understand the
spec, but I realize now that there isn't a good description
of what rgba means.
ChrisL: And I think it should explain how it interacts with opacity
(multiplied together).
dbaron: A repeated comment we got was the gamma correction section
being out of date; I think I've addressed that.
ChrisL: Yeah, looks like it.
ChrisL: Beth will send me an email that gamma has changed between
Leopard and Snow Leopard.
dbaron: The wording of the spec in general isn't great about what
conformance requirements are, so there are some issues where
I think I can improve that relatively easily.
dbaron: Frex, it says "here is how to convert hsl to rgb", but it
doesn't say you *have* to do that.
ChrisL: yeah, that should be normative.
ChrisL: Also there was an issue about color spaces and color width
and such. All colors should be sRGB, and 0-255.
dbaron: Issue 13
dbaron: Someone suggested we remove the statement about clipping
values outside the device gamut, which makes me wonder what
to replace it with.
ChrisL: I don't think they understood the issue. Do we have a
conformance requirement to display colors you can't
physically display?
dbaron: I think that we might not quite want to clip, but might do
some special mapping near the edge.
ChrisL: [example with differing gamuts]
ChrisL: After doing gamut mapping, if I still end up with values
outside the displayable colors, it must be clipped.
dsinger: Are you modifying what you remember the user asked for,
or what you are trying to display?
ChrisL: If it's implying that what is specified goes 1-1 with
device gamut, that needs to be changed.
dbaron: Right, that's why I want to change "clipped" to "clipped
or mapped".
ChrisL: "clipped or mapped" isn't fine.
ChrisL: You need to say "values outside source gamut should be
mapped to device gamut, values outside device gamut
must be clipped".
dbaron: What's the source gamut?
ChrisL: The color space you're coming from, sRGB.
dbaron: CSS allows values outside of sRGB.
ChrisL: Yes, that's fine. If you have a printer that can do blues
outside of sRGB, that's fine, CSS lets you express that.
ChrisL: But if you're showing on a screen, you can clip to the
device's gamut.
dbaron: How is the source gamut related to things here?
ChrisL: I should have flagged 'device gamut' more. Once you've
mapped to the device gamut, *then* you need to clip
anything outside of it.
Bert: The device clips them for you, right?
ChrisL: Typically the driver clips them for you.
ChrisL: You need to introduce the term source gamut and device
gamut, and use them separately.
dbaron: What is the source gamut?
ChrisL: In here, sRGB, or any other color space if we allow more later.
dbaron: But we allow things outside of sRGB.
ChrisL: Right, nobody is talking about clipping source gamut.
ChrisL: I can take an action to give a better description here.
szilles: [suggestion for communicating this without using the term gamut]
ACTION: clilley to rewrite the paragraph in CSS color concerning
gamuts and clipping
<smfr> http://wiki.csswg.org/spec/css3-color#issue-18
<smfr> http://lists.w3.org/Archives/Public/www-style/2008Sep/0006.html
dbaron: It's one of the later messages in the thread.
ChrisL: Marbux is a troll.
glazou: We still need to respond to trolls.
glazou: Talked to AC people, they said it was no problem.
glazou: So we have an answer. It's member-only, but it's not a
technical issue, only a legal one. It probably deserves
a member-only answer.
ChrisL: So resolution is no change?
szilles: The "be" change should happen, though, right?
dbaron: That's editorial, yeah.
ChrisL: So we can say "We agree with the editorial comments from
the XSL-FO working group". It makes it clear who we're
agreeing with.
dbaron: There's a note at the bottom of the system colors section
that I think is wrong.
dbaron: It says the computed value of a system color is the keyword itself.
dbaron: First it's weird that a normative requirement is a note,
and I think it's wrong anyway.
dbaron: So system colors should compute to a color.
ChrisL: Sounds good.
ChrisL: I've seen Issue 20 come up in hypertext coordination group
before, and so we need to say what we mean by 'deprecated'.
dbaron: We mean that impls should still implement it, but new
content shouldn't use it.
ChrisL: Issue 27, we should discuss it.
ChrisL: I assume it's because we can get it out this decade?
dbaron: It doesn't have real dependencies; it can go to 2.1 just fine.
<dbaron> Sounds like people are all happy with depending on CSS 2.1
Animating Gradients Part I
--------------------------
plinss: Next topic is animation of gradients.
smfr: I think this came up because the Transitions spec said
gradients were animatable.
smfr: I think this is a mistake because gradients aren't a property,
but rather a type of image, and we don't know how to transition
images yet.
smfr: Also I think this might be something for the public-fx group
to input into as well.
ChrisL: Could you send a mail to the list about that?
ChrisL: [talks about how animating gradients in SVG is easy]
TabAtkins: I've got a goal with shepazu to unify some underlying
concepts in CSS and SVG, to make those things easier.
image-fit and image-position Part I
-----------------------------------
plinss: Next topic is image-fit and image-position
fantasai: We can't do much, since that was supposed to be for SVG coord.
fantasai: But one thing we can talk about is naming. SVG wanted new
names for things.
fantasai: We might be able to discuss that.
<fantasai> http://lists.w3.org/Archives/Public/www-style/2009Sep/0304.html
<anne> btw, http://blog.mozilla.com/security/2010/03/31/plugging-the-css-history-leak/
howcome: image-* isn't perfect for video either
fantasai: fit-aspect-ratio says that you're fitting the aspect ratio
to the box.
fantasai: As far as the most useful information you can stuff into
the property, that's fine.
ChrisL: So fit-aspect-ratio and fit-position are good?
howcome: No. What if you put it on a <p>?
fantasai: No aspect ratio, so it doesn't apply
howcome: Are there other suggestions?
Bert: Without something pointing to images or replaced content, this
sounds too general.
dbaron: What's the list of values for this?
TabAtkins: For aspect ratio: fill, cover, and contain. For position,
a bg-position.
howcome: Why isn't image good enough for SVG?
dbaron: If I hear "aspect-ratio", I expect something that looks like a ratio.
fantasai: Maybe aspect-ratio-fit, but then it's weird to combine
them into a shorthand.
smfr: content-fit, or just fit?
Bert: We had that.
TabAtkins: We had content-fit, said it was too general, and changed
it to image-fit.
<smfr> http://dev.w3.org/csswg/css3-page/#img-fit
TabAtkins: This specifically says "replaced elements", which isn't
great for SVG.
fantasai: When SVG imports it, they can tweak applicability wording
for their own purposes.
fantasai: In CSS, all values have no effect on non-replaced content.
Bert: content-* has another advantage, in that it refers back to the
content property, which can produce a replaced element.
* fantasai thinks that nobody will find 'fit-content' when they're
looking for it if it has neither aspect-ratio nor image in its name
<Bert> 'content-fit' not 'fit-content'
[naming discussions]
<bradk> 'scale-how' and 'position-how'
<Bert> (I still prefer 'image-fit', though)
<fantasai> 'aspect-ratio-fit'
<fantasai> 'fit-aspect-ratio'
<fantasai> 'content-fit'
<fantasai> 'fit-content'
<fantasai> 'fit-scaling'
<fantasai> 'scaling-fit'
<dsinger> fitting?
<dsinger> 'replaced-element-fit-behavior'?
<bradk> fitting:have(1)
<fantasai> q+ for motion to switch topics until Molly can join the discussion
<br type=lunch>
<sylvaing> image-spread
<mollydotcom> Hi all - guessing you're off for lunch?
<TabAtkins> just getting back, actually
<mjs> did you guys solve all problems with CSS yet?
<anne> we added some problems
Animating Gradients Part II
---------------------------
[continuing discussion about combining animations and gradients]
[specifically, maybe attaching animations to transitions, rather
than states?]
[dean talking about animations with implicit start and end, like
transitions do]
[if, say, you animate left when you transition a color, what's
the final value of left?]
<Bert> (If 'transition-properties' has a value foo, then foo
animates, even if the start and end values are the same.)
[discussion about new selectors to address the hover/unhover animations]
[something more analogous to mouseenter/mouseleave, rather than
mouseover like :hover is]
[or something that explicitly captures a state transition, like
:transition(:hover,:not(:hover))]
[combinatorial number of state transitions]
[event-based CSS property]
[back to keyframes for transitions?]
<anne> you could have something like :leave(:hover) or :leave(.test)
for when something stops applying...
<anne> but keyframes for transitions is prolly an easier solution
image-fit and image-position Part II
------------------------------------
plinss: Back to naming of image-fit and image-position,
sincy mollydotcom is here.
<glazou> mollydotcom, we need your expertise finding names...
<mollydotcom> I'm here to talk about that
smfr: dsinger had a suggestion that he put into irc earlier
smfr: viewing-scale : letterbox | crop | fill; viewing-position : ...
<mollydotcom> do you want me to call in or shall I just type?
Both hurt, typing less so as my throat is so swollen.
<glazou> mollydotcom: see conf call data just above
<fantasai> how about we call in, and you type?
<fantasai> that way you can hear everything
<mollydotcom> ok, I'll call in and say hi and then type
<mollydotcom> thanks
<fantasai> :)
+Molly_Holzschlag
<fantasai> http://lists.w3.org/Archives/Public/www-style/2009Sep/0304.html
mollydotcom: Elika has caught me up a little bit on the issue.
mollydotcom: We've been talking about this for a long time.
mollydotcom: If someone can pinpoint the terminology that we're
struggling with, I can help out.
fantasai: We got a message from SVGWG, prompting the discussion.
mollydotcom: Main concern with image-fit and content-fit is that
we're really not talking about images or content.
mollydotcom: It *may* be an image, but it's not traditionally
what we call 'content'.
mollydotcom: I suggest, for semantic rationale, 'object-fit'.
howcome: Steve suggested that over lunch as well. I think it
covers the things we're talking about here.
mollydotcom: Right, whether it's a video or some SVG or an image
or an applet, we can call all those 'object'.
<mjs> does 'object-fit' really add any meaning to 'fit'?
<mjs> pretty much anything can be arguably an 'object'
mollydotcom: I have a problem from an educational perspective
with using 'image'.
mollydotcom: I think 'object' does add meaning to 'fit'.
mollydotcom: I don't think it's true that *anything* can be an
object. In the markup world, that always refers
to a replaced element or similar.
fantasai: Agreed.
<mjs> in HTML there is specifically the <object> element, and
people would think the property is referring to that
smfr: That could also bring up the reference to <object>, which
would suggest an exclusion of <video> and similar.
mollydotcom: Yeah, that's possible confusion.
fantasai: I don't think anyone thinks of a paragraph as an object
<bradk> object has another meaning in JavaScript too.
<mjs> as a browser implementor, I certainly think of a paragraph
as an object
<mjs> HTMLParagraphElement to be specific
< TabAtkins>As an author, do you think of it that way?
<mjs> no idea if authors think of it that way; I would imagine
authors would do a lot of scripting would think of every
element as an object
mollydotcom: To designers, 'image-fit' would say to them that
we can't put a java applet in there.
mollydotcom: They come at us from a different perspective.
<mjs> if the intent is to capture all replaced elements, then
maybe it should be replaced-fit
smfr: What's the objection to content-fit?
mollydotcom: Too broad.
<bradk> sometimes, when I'm dealing with an element in JS
<TabAtkins> maciej, this will be more than just replaced content
when SVG imports the property.
mollydotcom: And for content authors, content refers to the text
content of the document
mollydotcom: It seems to me that 'object' is a happier medium.
<mjs> TabAtkins, what does SVG intend to apply it to? everything?
<fantasai> object-fit: fill | contain | cover
<fantasai> object-position: <bg-pos>
<fantasai> ?
mollydotcom: To me it looks good, and I think I can have that
make sense to people
mollydotcom: I think it's much harder to convey image-*
howcome: I can live with image-* too, but this is better
<mjs> I really doubt that "object" adequately distinguishes
the set of SVG, CSS and HTML constructs it applies to,
from the set of things it doesn't apply to
<TabAtkins> maciej, it seems that there *is* no single word that
does it. Everything sucks somehow.
* anne doesn't really like object either
<mjs> TabAtkins, why not just name the property "fit"? does it
need a noun?
mollydotcom: We were also talking about scaling
howcome: I think 'fit' is just too generic.
<Bert> (We had 'fit' at one point, and decided to change it.)
fantasai: It seems like it could be a shorthand for fit-position
and something else.
mollydotcom: Let's throw it in front of the SVGWG and see what
they have to say.
* TabAtkins Next public-fx telcon!
mollydotcom: We talked about fit-scaling
<bradk> I still prefer 'scaling-fit'
<mjs> random proposal: fit-rule: fill | contain | cover, fit as
a shorthand for fit-rule and fit-position
mollydotcom: Problem with me is the active word of scaling. It's
not quite actively scaling.
mollydotcom: fit-scale, alone, makes sense to designers and similar people.
mollydotcom: if I say you ahve to scale this particular object,
that makes more sense to me than saying 'fit-scaling'.
mollydotcom: In PS and you want to keep the aspect ratio, you just
click "keep aspect ratio" and just change one value,
or do it in %s.
mollydotcom: And that's a very familiar paradigm.
mollydotcom: So I think the word 'scale' is better, but there's
vaguery in all of this.
mollydotcom: We just have to pick the one that is closest and most
understandable to the most people.
<fantasai> fit-scale: fill | cover | contain
<fantasai> fit-position: <bg-pos>
howcome: So should we just list the alternatives?
<fantasai> could append <percentage> to fit-scale
<bradk> On a fit-scale of 1-10, I'm about a 5 maybe.
<fantasai> 100% would replace none
<fantasai> fit-scale: fill | cover | contain | <percentage>
mollydotcom: just giving one would preserve aspect ratio
mollydotcom: fit-scale: 100% would be the image its actual size
mollydotcom: fit-scale: 50% scales it down by 1/2
mollydotcom: Could allow 2 values would allow different scaling for different dimensions
Scribe: fantasai
howcome writes on the board
fit-scale
fit-position
<TabAtkins> howcome: Are these the two proposals we have?
---
object-fit
object-position
---
iage-fit
image-position
s/iage/image/
---
aspect-ratio-fit
fit-position
---
scaling-fit
fit-position
---
and either of last two with 'fit' in the front
howcome adds numbers
1. fit-scale / fit-position
2. object-fit / object-position
3. image-fit / image-position
4. aspect-ratio-fit (or fit-aspect-ratio) / fit-position
<mollydotcom> 2 from me
smfr: prefer 3, but 2 is ok
anne: same
steve: 1 or 2, not 3
beth: 2, fallback to 3 if it has to
sylvain: 3, then 2
alex: 3, then 2
alex: for the same reason I prefer mouse over pointer
bert: 2, 3
arron: 2, then 3
fantasai: 1, then 2
dbaron: 2 then 3
tantek: abstain
brad: 2 then 1
tab: 1 then 2
chris: 1 then 2
daniel: 2 then 1
peter: 1 then 2
dsinger: 1 then 2
howcome: 2 then 3
dbaron: 2 was first or second choice from everybody
fantasai: my one concern with 1 is that if you want to add percentage
scaling, it doesn't work with the object-fit name
anne points out that if you made a shorthand with these, the shorthand
would be called object
<mollydotcom> Anne: you do make a good point
<mollydotcom> no shorthand should be called object IMO
<mollydotcom> is there going to be a real need to do that?
smfr: object-fit-scale, object-fit-position
smfr: Could combine them and have object-fit-scale and object-fit-position
-Molly_Holzschlag
<mollydotcom> bye folks!
fantasai: smfr's suggestion would address the shorthand and make more sense
with percentages
TabAtkins: percentages would make a shorthand impossible to parse
RESOLVED: use object-fit and object-position for the properties
Advanced Layout Modules
-----------------------
TabAtkins: So, this is going to be less direct suggestions and more
my plan of action in the future about what to do
TabAtkins: I'm a Google employee now, and will soon be chrome liaison
TabAtkins: I want to take the layout drafts and turn them into something
we wnat to implement and use soon
TabAtkins: Specifically, Template, Flex, Grid, and a few others maybe
TabAtkins: I've been thinking for a while what the underlying abstractions
are in the different layout drafts
TabAtkins: and also in the different layout modesl I as an author want to do
TabAtkins: I would like to combine into one model, but don't think I can
quite do that
alexmog: Why do you want to do this?
TabAtkins: Because I as an author want to use them. Because laying out
in CSS sucks
alexmog: But you also want one or more browsers to implement
TabAtkins: I'd also hope to implement some of this myself
TabAtkins: So, the first model that layout things will be built on is
table layout
TabAtkins: turns out table layout is super useful for layouts I've done,
for doing things I didn't expect before I started playing
with it
TabAtkins: Table layout by itself is good, I like the way it lays out
as a grid
TabAtkins: the problem is that it restricts your site markup: you need
to put in containers and order things so that it lays out
TabAtkins: which can be bad for accessibility
TabAtkins: Template layout fixes this
TabAtkins: Once you look into it, it looks just like magic on top of
table layout
TabAtkins: So I want to take Template Layout, slightly change it so
that it /is/ magic on top of table layout
TabAtkins: That would basically entail setting up the properties so
set up a table grid out of pseudo eleents
TabAtkins: and hopefully discussing how content is flowed into the
pseudo elements
TabAtkins: hopefully not a significant change in the draft, just conceptual
TabAtkins: Another thing to add would be another table layout model
that's sane
TabAtkins: fixed table layout is sane
dbaron: no it's not, it's just nobody uses it so nobody knows how messed
up it is
alexmog: Even if I don't understand table layout, I can ...?
dbaron: Another problem with table layout is that putting large things
into small cells often doesn't do what you want
dbaron: eg. have one thing wider than viewport
dbaron: makes the whole table wider than the viewport
TabAtkins: might be an artifact of auto layout right now
TabAtkins: Could consider putting out a new table layout model along
with the mathching template model
TabAtkins: ...
dbaron: I removed support for * widths from Gecko because the implementation
didn't do much
dbaron: And the HTML4 description of * widths said do what browsers do for
percentage widths, and the spec for percentage widths said something
else
alexmog: WPF does use table layout internally, and it implements * widths
alexmog: The advantage is that you can put content into any slot into the
table
Bert: We could add a third algorithm to table-layout property
TabAtkins: Building off of table then lets you use auto or fixed layout
if that happens to be what you want
Bert: That new algorithm would also allow the flex property in that case
Brad: Would you bring that into the table display types, too?
TabAtkins: Yes, if we add it to table-layout
TabAtkins: the only magic in Template would be to create pseudo elements
that represent table parts and putting the content in there
TabAtkins: I'm going to start working on the drafts for these
TabAtkins: Just wanted to give everyone a heads up
howcome: You have an implementation as template layout, right?
Bert: Yes, 3 impls. One uses same syntax as the draft
<TabAtkins> from alexis deveria
Bert: The other impls are the ones from Cesar, which uses an older syntax
Bert: And there's an impl from Andrew F. which uses another variant syntax
Bert: I like the idea
howcome: We need something like this, we haven't talked about this for years
howcome: what about multicol?
TabAtkins: interact the same way as multicol and tables do now
alexmog: If you are creating a new kind of a grid, that grid could
supercede grid positioning
alexmog: you could use that grid to position floats and have them
interact with other content
Bert: My template draft has that, the grid is defined by the template grid
howcome confirms that grid units are defined in various drafts
Tantek: what's the general class of use cases that you're going for?
TabAtkins: Overall site layout
TabAtkins: I want to make sure that either this directly or this plus
other stuff is also useful for applications
TabAtkins: e.g. replace Gmail's hacky stuff
Tantek: Traditionally, grid-based layouts are really useful for
application UI
<anne> did he say he's going to base this on top of table layout?
<anne> ... also, does that mean someone is going to define table layout first?
<fantasai> yes
<fantasai> no clue, probably not
<glazou> http://glazman.org/howcome-cupertino/
<anne> ... seems somewhat important to define those primitives if we
are going to build on top of it
<anne> ... we always have long discussions on anything table related
and without a clear overall picture of how that works it's
just going to get worse
Tantek: There are a whole class of applications that are doing
ridiculous backflips to do UI
Tantek: Having a model that solves those use cases could cause a
renaissance of web applications
TabAtkins: If we can come up with necessary flexibility with grid
then building them together would be great .. (?)
Tantek: Consider the use cases together, and consider also the implementors
alexmog: I'm not against unifying the grid
alexmog: but I don't want to have super-complicated interactions
across multiple models
dbaron: I don't think gmail is that gridlike
dbaron: The layouts tend to be more about taking one piece of UI and
pushing it against the edge of the space, and then having the
rest of the area taken up by the rest of the app
dbaron: You have menus and toolbars and sidebars
dbaron: In all these cases you're taking the rectangle
dbaron: taking up one part of it with a UI element, and then filling
the remaining space
Tantek: Check out iPhone apps, they have very different UI models
howcome: We haven't really been able to exploit our table model
because it hasn't been widely implemented
howcome looks pointedly at Microsoft
...
discussion of WebKit-specific apps and table layout
Tantek: Interface builders have lots of interesting ways of laying
out UI elements. It makes sense
Tantek: snap-to-grid
Tantek: pin one object to anther object
Tantek: just spend 15 min with interface-builder
howcome: Do we consider apps to be the driving force or documents?
fantasai: Both. We need to handle both.
Tab talks about grids defined by templates and tables and grids
defined by content
alexmog: The grid I imagine is independent of content. You either
place stuff on the gridlines, or snap to them
alexmog: The only thing you need to add is size to fit
alexmog: perhaps horizontal lines should fit to content
alexmog: that switches grid from trivial to complicated
Tantek: grids aren't just for UIs either
Tantek: Things like baseline-alignment across the page is super-hard
to do today
Tantek: Grid would presumably solve that
TabAtkins: You could set up a grid with those line
TabAtkins: and then with some other mechanism tell text to line up to that
TabAtkins: You would need separate grids
TabAtkins: Whether layout grid + baseline grid is sufficient or we
need author-named grids, not sure
fantasai thinks we should have named grids
Bert: Anne asked on IRC, so do you have to write the table module first
if you are going to do this?
Anne: What does 'width' mean, what does 'height' mean
TabAtkins: Don't have to define that, can just say "do what you do currently"
TabAtkins: and build a new sane table model
alexmog would like a sane table model
Anne: I think we might get a bid of redundancy because only a few
people know what the current one covers and what algorithms
are defined that we might want to reuse
Steve: One requirement that I have is that I be able to describe
the area into which things flow separately from the stuff
that's flowing into it.
Steve: Right now table is entirely wound around the content that's
in the table. I don't want that
Steve: I want to describe whatever it is without having the content
several, supported by Template module
smfr: Can you split content up between boxes?
TabAtkins: Not currently. No non-rectangular regions and no disconnected
regions
TabAtkins: would like to add later
howcome: Did you see the very first draft from 1997?
TabAtkins: No, just seen since Advanced Layout just before it got
split into Template
<Bert> http://www.w3.org/TR/NOTE-layout
<dbaron> As far as defining table layout, http://dbaron.org/css/intrinsic/
and a spec that Markus was working on both define significant
pieces of the width calculation
<dbaron> I actually think I like the height calculation that IE6 does
more than what Gecko does.
* fantasai notes that you're probably the only one who understands
the implications of that comment :)
TabAtkins: I'm not doing box-to-box flow in order to be conservative
in level 3
TabAtkins: I think it would still be useful
... printing ...
TabAtkins: Printing does bring up other issues. It does matter.
non-rectangular layout is difficult if multiple parts have flexible height
TabAtkins: Next layout topic
TabAtkins: Also related to table layout
TabAtkins: In my current use of tables, I often want to set up a ton of
things in a grid
TabAtkins: but in my markup they're just a linear progression
TabAtkins: and I want them to fill through and automatically find the
right number of rows
TabAtkins: so like normal table layout except without set rows
TabAtkins: either by filling the width of a space, or specifying a
number of columns
howcome: Another idea is columns first
TabAtkins: also want to determine direction of cell flow
TabAtkins: When you loosen constraints on tables, then tend to become
more similar to flexbox
TabAtkins: So does anyone theoretically object to these additions to
table stuff?
* flowing cells into rows without row containers
* cell progression direction: changing direction, changing
into columns-primary
<bradk> block-progression-direction to flow vertically, possibly
dbaron: If you switching block-progression direction, you'll also
switch the width and height algorithms
dbaron: Do you mean cell-progression-direction as a subfeature of
the cell flow idea?
TabAtkins doesn't know
howcome complains about being forced to change markup to do layouts
howcome wants a property for determining whether table is column-primary
or row-primary
dbaron: One thing I liked about table height algorithms in IE6 is
that they were much more similar to the width algorithms
howcome: You also had an idea about saying which cells you want to
start a new row
TabAtkins: If you just want to fill to a specific width, then that
doesn't work
TabAtkins: but for other cases it works
TabAtkins: you can use :nth-child to do a specific number of rows
fantasai: A problem with fill to a width is that you layou out your
table, splitting into say 4 cols
fantasai: but then you find a really big cell and find you can only
fit 2 cols
fantasai: then you have to go back and relayout the whole table
fantasai: (which is already a 2-3 pass algorithm)
TabAtkins: Ok, maybe that's not a good idea then. Don't like
iterative layouts
<bradk> container has 'table-flow: rows(4)' to auto flow table-cells
vertically into 4 rows, with as many columns as it takes.
TabAtkins: you might also want to flow into multiple rows, but not
line up column-wise
TabAtkins: They flow and wrap around, and each row is height-equalized
TabAtkins: can fake it with inline-block, but doesn't handle all cases
TabAtkins: Can't justify to exactly fit the row
<Bert> (We did have a tabulation proposal some time ago. It was
dropped when leaders() could do 80% of that.)
...
Tab shows an example layout
alexmog: That's a multi-line flexbox
TabAtkins: Almost
TabAtkins: box-pack-justify and a flexbox automatically sets all
margins to be equivalent
TabAtkins: but if you want finer control voer that, you can't express
it in those terms
TabAtkins: you can't set flex on margins
TabAtkins: I think that's only place where flexbox is lacking.. it
lays out from the container's perspective but not the
children's
alexmog: that's the point
alexmog: Everywhere else in CSS every element has its own opinion on
how it wants to be laid out
alexmog: Flexbox allows introducing simple or different layout
algorithms because it doesn't interfere with anything else
in the system
* scribe missed something in the middle there
alexmog: The layout is totally governed by the container
alexmog: that's why it's a clean, easy-to-implement, easy-to-use spec
alexmog: If you let it allows margin collapsing and everything else
that happens in CSS, then you create a monster
TabAtkins: I would like to dive down and try to design with flexbox,
and then bring back anything I find that's insufficient
TabAtkins: But I'm willing to put that off and do experimentation
dbaron: I think box-pack is pretty rarely used in xul
dbaron: What's used instead is having more nested boxes
TabAtkins: I do something imilar to flexbox using table layout
TabAtkins: For a horizontal nav, I'll use auto or fixed table layout
on a <ul>
TabAtkins: to either space out the links, or the space between the links
TabAtkins: in the first case, the white space between them changes,
but their centers are spaced evenly
TabAtkins: auto layout almost equalizes the spaces in between
Steve: You might want to wrap borders around that white space
fantasai: You might want to flex the borders, or you might want to flex
the padding
TabAtkins: I handle that by either styling the <li> or the <a> inside it
Steve: There's another piece of this. If had a set of inline-blocks and
turned justification on
Steve: The only place it could put space would be in between the inline-blocks
Steve: The catch is, you really want some space on the ends to make it
look right
* fantasai likes her display: tab spec, it solves all these problems
<fantasai> http://fantasai.inkedblade.net/style/specs/tabs/
Steve: I'm asking you to think about it as justification
Steve: There may be other places you'd like justification
fantasai describes a catalog use case that should also be solved by this
mechanism
TabAtkins: One thing I want to do that I don't have much experience with
is what web apps need
TabAtkins: Because I'm experienced with web sites, but not web apps
<Bert> (There are also Media Queries to deal with different numbers of
columns.)
Tab shows an example of a site he designed
TabAtkins: Here's a bunch of questions.
TabAtkins: I'm flowing this into three rows
TabAtkins: Right now I can only do with inline-blocks, but that means I
can't equalize their heights
Steve: What's the difference between flexbox and flowing tables?
TabAtkins: Not having a grid in both directions
Steve: If I had something I could do this flowing in, having properties
that could turn it into the grid...
Steve: I guess what I'm trying to say is that I see less similarity to
tables for flowing tables than to flexbox
Steve: I would expect the flowing cells more in the flexbox world
Steve: with additional constraints
TabAtkins: That's why I said there seems to be a point where tables and
flexbox come to gether
TabAtkins: As you add more constraints to flexbox and reduce constraints
in tables they get more similar
TabAtkins: We could maybe add more possible constraints to flexbox, and
have it look more like a table
TabAtkins: instead of going from tables towards flexbox
Bert: Question about your grid of questions
Bert: I would bet that most people fill top-to-bottom, whereas you fill
horizontally first
Tab explains this is because that was the only way he could hack it up
into a grid using existing features
<anne> btw, live style sheet editing:
http://annevankesteren.nl/test/contenteditable-style.htm
Tab explains also why multicol + snap-to-grid wouldn't work: a large item
would throw off the alignment
Steve: I have a similar use case of parallel translations
howcome: That's another good use case for column-major instead of row-major
* scribe missed alex's comment
TabAtkins: You'd run into the iterative layout problem fantasai pointed out
howcome: Have you looked at line-stacking-strategy?
<howcome> http://www.w3.org/TR/css3-linebox/#LineStacking
TabAtkins: Not recently
TabAtkins: One criticism is that it doesn't apply across blocks
* sylvaing just heard howcome come up with display:clearance-or-whatever
...
TabAtkins: Can you set line-stacking-strategy on body and have it apply
to everything?
?: It's never been implemented
Steve: InDesign in Japan does that (just not in CSS)
howcome: It may not be the solution, but is something you should take
into account
TabAtkins: I think there's an interesting intersection of table,
multicol, flexbox, etc
howcome: I think it's great. Come with your youthful energy and work
on this.
Steve: Something to be said for people solving problems by not being
aware they're unsolveable
<br enthusiam="yay!" ... >
* sylvaing was sadly not informed about the hakon tweetup in time or he
would have brought stack of free MSIE EU documentation for
the grateful crowd
* anne still wants his IE t-shirt
dbaron's Auto-Percentage Heights Proposal
-----------------------------------------
dbaron: So the way widths work, you have some container
dbaron: Then you have something inside that has margin border padding,
then something inside that
dbaron: You have computation going in from the edge
determining the available width, and then when you hit a percentage you
take a percentage of that.
dbaron: What we've said in the past is that percentage heights are just
auto if the container is auto
dbaron: But people want percentage heights to just work
dbaron: There are several places where this would be more useful
dbaron: One is multicol
dbaron: You usually want to scroll horizontally off the screen instead
of vertically
dbaron: My idea is that, as we're doing layout, we keep an idea of what
the available width is
dbaron: You start with the width of the viewport, subtract out borderpadding,
and just keep subtracting in, possibly replacing with a fixed width
dbaron: If we did this for height as well, percentages could be useful
dbaron: It's not perfect, but it gives you a default in cases where you
need a good default
alexmog: another use case is block progression direction changes
dbaron: And there might be some use cases for doing this with flexbox
<TabAtkins> also text direction changes (vertical text vs horiz text)
dbaron: I'm not sure what we're doing with this, but I might try adding
it under a vendor prefix in Mozilla.
TabAtkins: Would it be possible to implement this as how actual
percentages work?
dbaron: Probably too late
TabAtkins: as a different unit or something?
dbaron: maybe
dbaron: We could use this for height: fill
dbaron: and maybe even height: content-fit
dbaron: This would only get you the effect of 100%
TabAtkins: you could expose fill through calc() and then you can get
precentages that way
dbaron: A good use case would be max-height: fill
dbaron: for columns
dbaron: So you fill the screen, and then start growing out
TabAtkins: max-height: 100vh would also solve that case, right?
dbaron: Assuming your columns are not in something overflow: scroll
people seem to like this for height: fill
CSS2.1 Issues
-------------
Topic: jd's followup to issue-156
<plinss_> http://lists.w3.org/Archives/Public/www-style/2010Mar/0538.html
discussion about the proposal
fantasai: "Once the font family's weights are mapped onto the CSS scale,
missing weights are selected as follows:"
<fantasai> use that to replace the introductory sentence, then add jd's
bulletted list
RESOLUTION: jdaggett + fantasai proposal above accepted
http://lists.w3.org/Archives/Public/www-style/2010Mar/0551.html
fantasai: Issue 107 - anonymous table boxes proposal is done, bzbarsky
has approved this proposal, and it's ready for wg discussion
fantasai: please review so we can discuss it later
<fantasai> the wrapping on that sucks
<fantasai> I will resend from a real email client when I get home
GCPM
----
<howcome> http://dev.w3.org/csswg/css3-gcpm/#setting-named-strings-the-string-set-pro
howcome: I'd like to publish another a WD
howcome: wrt env() function
howcome: There was a question of how to get the date and time in the
locale of the user
howcome: There seems to be a widely-available strftime function
dbaron: There's also JavaScript functions that have this functionality
dbaron: I'm not sure if it's exactly compatible
* fantasai hopes it is, that would be annoying otherwise
<dbaron> https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Global_Objects/Date/toLocaleFormat
is a Gecko extension, not part of ECMA
glazou: fwiw, toLocalString uses the language of the browser, not the
language of the system
dbaron disagrees
Tantek and Steve want to format date and time
howcome tries to explain that it's not the point of the feature
dbaron: Some strftime things are local-sensitive and some are not
Tantek: Your only choice in howcome's draft is to use the locale-specific
version
* dbaron thinks "2010年03月31日 16時16分40秒" is a perfectly readable date format!
Tantek: I prefer if the env() would return in ISO values
Steve: I would too, but i"m not sure it's as useful
Tantek: with hyphens
howcome: So 2010-03-30
bradk: Wasn't the point to do what the browser does now, but be able
to style it further?
Steve: I don't mind publishing as long as this is marked as an issue
Tantek: You should start with something universal and expand from there
bradk: I don't think it's bad. There's a reason why browsers print the
locale-specific version. It's not our job to educate the world
on universal time formats
fantasai: You could call it localtime so that you can add other things later
howcome: So local-time and local-date
howcome: what if I want both?
Tantek: local-date-time
<tantek> my personal preference would be for ordinal-date (YYYY-DDD)
http://en.wikipedia.org/wiki/ISO_8601#Ordinal_dates
<tantek> and on that note - I have to depart. thanks everyone!
howcome: Simon proposed to say that border-clip* should go into borders
and backgrounds
fantasai: We agreed to add this for CSS4 Backgrounds and Borders
discussion of where these features belong
fantasai volunteers to pull this into css4-backgrounds
ACTION: fantasai put border-clip into css4-backgrounds
howcome: Can we agree in principle in publishing GCPM as WD?
no objections
TabAtkins suggests removing repeat
Tab: I suggested it originally, and I think it isn't needed
TabAtkins: Also, percentages should refer to the height for vertical borders
<smfr> i also think that hyphenation should move
Peter: ok, I think we're done
Meeting closed.
Received on Thursday, 8 April 2010 07:15:41 UTC