- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Mon, 28 Nov 2011 14:25:43 -0800
- To: "www-style@w3.org" <www-style@w3.org>
Unless you're correcting the minutes,
*Please respond by starting a new thread with an appropriate subject line.*
text-transform
--------------
Discussed custom text-transforms and whether to keep full-size-kana.
No consensus.
Gradients
---------
Discussed ways to make radial-gradient() more readable.
====== Full minutes below ======
http://www.w3.org/2011/10/31-css-irc#T19-46-29
http://krijnhoetmer.nl/irc-logs/css/20111101#l-1464
text-transform issue
--------------------
Scribe: TabAtkins
<florian> http://lists.w3.org/Archives/Public/www-style/2011Sep/0191.html
florian: Look at point 4.
jdaggett: The use-case for text-transform:full-size-kana is that in ruby,
small kana is mapped to full kana, because otherwise they're
too small to be readable.
jdaggett: That's really the only use-case for this transform.
jdaggett: And it's relatively small.
jdaggett: I propose that instead of doing these small use-cases, we have
an at-rule that lets you do arbitrary transformations.
jdaggett: So authors can handle these themselves rather than having to
come to us and get it included in a spec.
jdaggett: I don't think this kana transform is unworthy, but it's a
relatively small use-case.
florian: I think there are two main cases for a mechanism like this.
florian: First is the full-size-kana case. Well-defined and small.
florian: Another place where it's useful is removing accents from
letters. We can't have a generic algo for this, because it
depends on language and context.
<tantek> to remove accents?
florian: But a specific author and specific document can do this.
fantasai: Dropping accents tends to be done *per word*. It can't even
be done per documnet.
* tantek had a proposal to *add* accents:
http://lists.w3.org/Archives/Public/www-style/2003Apr/0012.html
fantasai: In Farsi, diacritics usually aren't written, but some are
preserved for disambiguation.
fantasai: you cannot solve this use case without a dictionary
florian: There are still useful cases where it's solveable.
florian: For cases that still aren't solveable, well, they're already
not solved.
florian: Another case - old-fashioned long s may want to be transformed
into a modern s. That's not something we'll probably ever care
about as a group.
jdaggett: And in Japanese you could have rules that shift from one form
of kana to another form. Tiny use-cases.
jdaggett: For i18n, it's simpler to just give people a rule. If we
find people using a particular kind consistently, we can then
standardize it.
howcome: I think this is a good idea, and is similar to @counter-style.
jdaggett: I propose then that we drop this property value and move
towards defining this transform rule and its syntax.
* tantek notes a problem report regarding text-transform:
https://twitter.com/psd/status/128565170514567168
<tantek> specifically: text-transform: uppercase turns "0.1µF" into "0.1MF"
szilles: One concern I always raise is, is this opening a security hole?
dbaron: It seems like anything you can do here, you can do with a font.
TabAtkins: or in many cases, just ordinary javascript.
dbaron: As an aside, I'm not crazy about the specific syntax being
proposed, but I won't get into that now.
stearns: I like this idea, but should the full-size-kana rule still be
added, since it seems useful?
jdaggett: Given that the use-case is only for Ruby in japanese, and only
for people who want to keep their original content that comes
with small kana, I don't think we need to.
szilles: A solution would be to use *this* transform as an example in
the spec.
fantasai: The table is non-trivial.
fantasai: And the *idea* that you can ask the UA for this sort of thing
is new and strange.
fantasai: If it's tricky and unintuitive, nobody will do it though.
jdaggett: If there's an example, or a wiki article or something, it's a
simple cut-and-paste to put it in your page.
howcome: Or an @import. That works for fonts already.
fantasai: They'll do that for fonts because it's shiny and new and cool.
howcome: We're not fighting the functionality, just the syntax.
And making it available to other languages.
howcome: For example, in typesetting my Ibsen book, he used a peculiar
form of punctuation. I had to edit a font to do that.
plinss: I hear many in favor of dropping, and one strong objection.
[three strong objections -> no consensus]
Bert: I think this is creeping transformations to CSS.
jdaggett: Do you support the keyword itself?
Bert: You said it was necessary, so yes.
<br type=lunch duration=1h>
radial-gradient() readability
-----------------------------
Scribe: Bert
[fantasai draws on whiteboard]
fantasai: Can somebody project the gradient syntax definition?
<fantasai> http://wiki.csswg.org/ideas/radial-gradients
<fantasai> http://lists.w3.org/Archives/Public/www-style/2011Oct/0859.html
fantasai: Look at bottom of wiki page.
fantasai: Not clear what is going on in these examples.
fantasai: Some colors, some percentages...
fantasai: I know there's a position and a size and some color stops there,
but it's not obvious which is which.
fantasai: So want all notations to be more obvious.
fantasai: Please look at the e-mail for some ideas.
fantasai: We're not loading arguments into numbered registers:
It's not ncecessary to have positional arguments in CSS.
jdaggett: Functional notation is usually interpreted as a function w/ params.
jdaggett: This keyword notation is going away from that.
Tab: But you can see it as going back more to how CSS properties work.
jdaggett: When I read a parentheses, I expect a function.
[Some people offering opiions]
fantasai: Inside the func. notation it is pretty much like a value notation.
fantasai: Not a function call, but a subset of the value.
PeterL: We have other things without commas.
Simon: But always commas in functions.
Molly: Most people are not computer scientists.
Molly: What is intuitive.
Molly: The original proposals were completely unitutive.
Molly: I have no context from CS. Peopel like me just need words.
Molly: Gradient "from" here "to" there.
jdaggett: But look at AppleScript. It is frustrating.
Tab: But isn't this the case for every property?
jdaggett: It's different inside functional notaitons.
Markus: Should avoid functional notation in general.
Simon: How do you know [something]?
Molly: It's the words, as long as it is logical.
jdaggett: Any kind of formal language needs to be consistent.
jdaggett In similar cases, you use similar notations.
jdaggett But this is mixing things together.
jdaggett Will lead to confusion.
Brad: I think it rather clarifies.
Brad: This is not AppleScript.
fantasai: Looking at the examples, I can kind of see what is going on.
fantasai: With the other ones, I have no idea.
fantasai: That's why I want to go here.
fantasai: Most functional notations we have so far, have commas in the
same way as in values without functional notations.
jdaggett: Do we have func. notations with keywords anywhere?
Tab: We're adding that right now.
Tab: Most functions so far are pretty trivial.
jdaggett: So this is the first time for keywords in functional notations.
<dbaron> I think keywords inside functional notation are reasonable.
Simon: Slippery slope. But other way to think about it is name-value pairs.
Howcome: OK with changing. We can also drop the just the parentheses here.
<brianman> There was a lot in e-mail. What's the current proposal?
Howcome: Programmers have traditions.
Howcome: We can do differently, as a string or something.
PeterL: Cf Python and others.
<TabAtkins> Like radial-gradient(center: 20% 20%, shape: cover ellipse,
colors: blue, red, black)?
jdaggett: But they are specific syntaxes.
PeterL: So is CSS.
* glazou sees JSON percolate into CSS syntax ? :-)
PeterL: The point is they are *not* parameters, because it is not a
*function*.
<brianman> There's at least one problem with that syntax, Tab.
<brianman> You probably want ....
radial-gradient(center: 20% 20%, shape: cover ellipse, colors: |blue, red, black|)
... but something other than the pipe character.
<dbaron> this is starting to look more like Apple's original proposal
* glazou waits for the curly braces proposal inside parenthesis
fantasai: I hear objections to commas, because that makes it different
from C. I don't hear that my example is unreadable.
<brianman> Your syntax above isn't clear on what the commas separate.
Are they separating colors or the next param pair?
jdaggett: It's not C. It's consistency with other parts of CSS.
fantasai: We don't use commas between values in CSS.
[For fantasai's idea, see e-mail linked earlier]
<brianman> [There are like 20 emails.]
<plinss> http://lists.w3.org/Archives/Public/www-style/2011Oct/0859.html
<plinss> http://wiki.csswg.org/ideas/radial-gradients
<sylvaing> glazou, Python functions also do that. It's a syntactical
orgy over here!
<brianman> Are you referring to this flavor:
radial-gradient(<shape> keyword <position> keyword <stops) ?
Rossen: fantasai's is not necessarily easier.
fantasai: Functional syntax is hiding three gradient properties. Why
do need to be in the notation, not in properties?
Tab: They are values, gradient's aren't properties.
Tab: We don't add twenty-something properties for images.
Tab: Can add @rule or point to SVG.
Tab: But gradients are right at the edge, can still be in CSS, in a funtion.
<glazou> sylvaing, let's use reverse polish notation
<sylvaing> glazou omg reverse-polish-calc() !
sylvaing: At some point we switch to SVG, you say. Then we need to inline SVG.
ErikD: the "from ... as" syntax doesn't seem natural to me.
Simon: Transform has functional notations. But all numeric.
<bradk> rect() does not require commas:
http://www.w3.org/TR/CSS2/visufx.html#value-def-shape
<dbaron> rect() is an accident from the examples and the normative prose
in CSS 2.0 mismatching
<smfr> https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/publish/Filters.html#FilterFunction
<brianman> Why is "radial-gradient(circle from center as red, blue)"
better than "radial-gradient(circle from center, red, blue)"?
In my opinion it's worse.
Tab: Filter functions shorthand in CSS looks like comma-separted now,
but will change them to look more like CSS property. Don't need the
commas. Space is enough.
Simon: Then we need to do that for trnasforms too, Consistency.
Luke: Need More general syntax system than the English word thrown here
and there.
fantasai: Shorthand and individual propeties if needed.
<sylvaing> image-values: spec(from almost-lc back-to endless, syntax, debate)
Simon: @-rule, like keyframe [...]
Simon: Use JSON :-)
<glazou> I would like to avoid "silent" tokens
<glazou> i.e. like in genetics, genes that express nothing
<glazou> if we could keep meaningful stuff only
* ed thinks JSON would make it easier to understand the syntax at first
glance anyway
<glazou> please let's do that
<brianman> Clarify, glazou?
<glazou> in that light, from and as are meaningless
<brianman> Ah.
<glazou> they help readability by humans
<glazou> don't help the syntax
<brianman> I would agree on 'as' but 'from' has some value.
Shane: Pretty strong relation to JSON idea. name:value idea.
<glazou> and also complexity parsing
<brianman> It solves the size version position problem with lengths.
Florian: That's not what was proposed here.
<smfr> gradient(shape circle, from left, as red, green)
<brianman> Useless as in that version, smfr.
<smfr> gradient(shape circle from left as red, green)
Shane: Those "silent" tokens exist in JSON, too.
Shane: Slight difference in tokens.
fantasai: Can vary order, although it looks weird with shape at the end.
<brianman> Sidenote: I think from is the wrong word. At is a better word.
<brianman> In light of offset focal point in the future.
jdaggett: May be readable, but allows syntaxes that are gibberish.
PeterL: Gibberisgh is loaded term.
peterl: comma-separated numbers are gibberish to me if I'm not intimately
familiar with the order of arguments
Shane: Is it better if it were order-independent and we say we can use
it in other situations, too?
<brianman> It can't be completely order independent. The color stops.
jdaggett: It's what an author expects.
<glazou> +1
Molly: Solve dependence on order with education.
<glazou> won't work
Molly: And a question:
Molly: What Simon just wrote is beautiful. What is the problem with it?
Simon: Complex grouping, precendence issues...
fantasai: Property values have those concerns already. Not a problem there.
<dbaron> The "shape" in what Simon wrote doesn't seem to me to add
anything useful.
<brianman> dbaron, it has usefulness here:
radial-gradient(size 25px 25px, from 25px 25px, red, green)
<dbaron> brianman, I was specifically referring to the "shape" rather
than the other keywords
<brianman> @dbaron - so you want "radial-gradient(circle...) and
"radial-gradient(size 25px 25px, ...)" ... Meaning only
a keyword in the size case?
<brianman> ... or are you saying that the from is clear enough that
the other param doesn't need it?
howcome: Need to start with "from" right?
Simon: CSS grammar doesn't restrict what goes inside (), does it?
Bert: Correct.
bert: didn't have time to look at the proposed syntax, would like to come
back and comment in a week
Florian: Should we allow ourselves the same flexibility inside () as
for other values?
howcome: Not more restrictive, just using more keywords, wich may be
more or less intuitive.
fantasai: gradients is a particularly tricky case because there are many
arguments of the same type that need to be disambiguated
?: Does't help people who speak other languages.
Tab: CSS is designed for English speakers.
PeterL: No consensus?
<TabAtkins> A current example of using keywords in functional notation:
<TabAtkins> http://dev.w3.org/csswg/css3-lists/#symbols-function
Molly: Seems less to do with keywords, more to do with notation, i.e.,
the brackets.
Molly: That means something for computer scientists.
Molly: Simon's examples in IRC make sense to me.
Molly: What is the problem with those?
Molly: Is it the notation? The limitations?
Simon: No consensus about needed the shape.
Simon: We need to think about all the things that use func. notation.
<brianman> @Bert - Color stops problem.
<brianman> 1. The color stops are different from the shape/size/location
params.
2. the color steps are a list.
<brianman> 2 - If you're trying to get order-variability support, you
need to group the color stops
<brianman> 1 - I think of the color stops as a different thing than the
params...just like for linear.
* ed agrees with brianman
<brianman> For those that didn't read the e-mail, with one slight
adjustment I could accept Elika's radial syntax.
Florian: Values in general; some have just numbers, some have extra
things to make it clearer. So far we didn't consider that
inconstsient.
Florian: Why do we think it is incosistent here?
PeterL: Transforms use a matrix, that is a tradition, makes sense to
people, no need to label it.
PeterL: What now?
Tab: Want to add a focal point later to gradients.
Tab: More general discussion about notations later.
Tab: Let's settle on radial gradients now.
Brad: Linear gradients already has "to", already uses spaces to separate
certain items, and uses commas in a way that's consistent with how
we use them in other property values
Brad: We are only putting () around them here.
<mollydotcom> from Eric Meyer "I like gradient(shape circle, from left
to bottom left, colors red, green)-makes sense, is very clear.
<brianman> @molly - sorry, your syntax confuses me terribly
<brianman> ...the middle param
Tab: Poll on gradients, and general notation discussion later.
<brianman> Isn't that the same as yesterday, Tab?
<brianman> (What's new in your poll.)
Florian: Difficult to it in that order.
Tab: It slows down gradients. We know the features, we just discssus syntax
forever.
Tab: This is a minor issue.
Shane: Let's get gradients out first.
Shane: Schedule alternative syntaxes discussion.
fantasai: That's terrible. Have to learn two syntaxes.
PeterL: Serialization issues too.
sylvaing: Who would formally object to the current comma-separated syntax?
PeterL: There's value in readability and extensibility.
plinss: A fair question would be to also ask would anyone formally object to
publishing with this syntax?
sylvaing: why should we change it?
[two many talking at the same time]
plinss: I think it's a win for readability and understandability, and a
big win for extensibility
peterL: valuable to look at this and see if it blocks something later.
howcome: What is the example?
fantasai: Radial with offset center.
<dbaron> To be clear: I really don't like "shape circle", since "circle"
is obviously a shape so "shape" is redundant -- unless we do
something more explicitly property:value-like.
Tab: circle at offset X X
jdaggett: At some point it gets easier to have an @-rule, as simon said.
howcome: I think gradients is already beyond readabilty.
Tab: Why didn't you say that earlier?
Tab: We settled on all this months ago.
jdaggett: But you also say you want to extend this.
Tab: Yes, and at some point we say let's not extend any further.
Tab: We can have that discussion in the future.
Tab: But keep open possibility to extend in current syntax.
Tab: Offset center was in the WebKit syntax, and I dropped it partly
because I couldn't get a syntax that was reasonable with it.
PeterL: I want gradients done. Don't publish and change again.
PeterL: Let's strawpoll.
[preparing strawpoll, finding examples to show on screen]
<JohnJansen> brianman, can you post what slight adjustment you need in
order to accept Elika's syntax?
<brianman> sure
Option A: radial-gradient(1em 2em, 3em 5em, red, orange, yellow)
Option B: radial-gradient(3em 5em at 1em 2em as red, orange, yellow)
Option c: radial-gradient(3em 5em at 1em 2em, red, orange, yellow)
<brianman> Yah, that about captures it
<brianman> A=WD, I prefer A but I'm fine with C. I dislike B for at
least two reasons.
Tab: Second is Elika's
Tab: 3rd is a variant, with "," instead of as
<bradk> B.2 radial-gradient(3em 5em at 1em 2em with red, orange, yellow)
Luke: Option missing is to name the first params.
Florian: Not sure this is the right set of options for the poll.
Florian: Need to eliminate.
Tab: Can give multiple votes, to all the ones you like.
D. radial-gradient(shape 3em 5em at 1em 2em as red, orange, yellow)
* ed prefers option A)
* cyril prefers option A) too, and notes that compared to SVG it's
missing the focal point position and compared to canvas it's
missing the inner circle size
<brianman> @cyril - correct on SVG, canvas
Bert: [question about ems in the notation]
howcome: Where is the "from" keyword that elika propsoed?
<brianman> good point
plinss: The word is unimportant, the concept is what we're voting on
PeterL: The exact word is not inmportant.
<dbaron> how does the ellipse/circle closest-side/closest-corner/
farthest-side/farthest-corner fit into this?
<fantasai> part of <shape>
<TabAtkins> dbaron: First argument is <shape>, which includes that.
<brianman> replace "3em 5em" with the shape keyword
<brianman> in all the options
<brianman> the <shape> keywords rather
<dbaron> (I saw that as both a shape and a size, but oh well...)
<TabAtkins> (Yes, "radial-gradient(ellipse at top left, red, blue)" is fine.)
JohnJ: A
PeterL: B, then c then A
howcome: a
koji: A
markus: a
Alan: b, c
soonbo: a
florian: b, c, a
bert: abstain
masa: abstain
EricM: b
Brad: C, then B
simon: a, d
alex: abstain
kimberley: abstain
rossen: a, c
sylvaing: a
johnD: a c
arron: b, a
tab: b, c
shane: b, c
* ed AC/DC anyone?
kimberlyblessing: a
<glazou> abstain
fantasai: b, c
luke: a, d
plinss: If you group b+c as one camp and a as a second, it's a dead tie
PeterL: This isn't showing us anything.
<dbaron> my prefs are d with the b->c substitution, c, a, if I'm
understanding correctly
fantasai: Open up to designers on csswg blog.
Tab: resolve in two weeks?
ACTION fantasai: make post with the options, just two options.
<trackbot> Created ACTION-397
<brianman> The "2" in that action is troubling.
<brianman> Either you choose to screw B or C.
[discussion about @-rule]
RESOLVED: decide in two weeks.
* sylvaing next: whether to use tabs or spaces
* glazou I want to use only one Tab, thanks
* Ms2ger one Tab, and spaces for indentation?
<glazou> :)
[agenda discussion / break]
Received on Monday, 28 November 2011 22:26:19 UTC