[CSSWG] Minutes and Resolutions TPAC 2011-11-01 Tuesday Noonish: radial-gradient() and argument notation, text-transform

Unless you're correcting the minutes,
*Please respond by starting a new thread with an appropriate subject line.*


   Discussed custom text-transforms and whether to keep full-size-kana.
   No consensus.


   Discussed ways to make radial-gradient() more readable.

====== Full minutes below ======


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:
   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:
   <tantek> specifically: text-transform: uppercase turns "0.1F" 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
   <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:
   <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
              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
   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
   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