W3C home > Mailing lists > Public > www-style@w3.org > May 2012

[CSSWG] Minutes and Resolutions Hamburg F2F 2012-05-11 Part V: Line Layout, Values and Units

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 15 May 2012 20:13:18 -0700
Message-ID: <4FB31B4E.3060907@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Line Layout
-----------

   Steve discussed some indeterminate cases in baseline alignment;
   further investigation is needed.

Values and Units
----------------

   - RESOLVED: rename cycle() to toggle(), leave behavior as is
   - RESOLVED: disallow values with commas in toggle() at this level
               http://dev.w3.org/csswg/css3-values/issues-lc-2012#issue-12
   - RESOLVED: Won't fix level-skipping in this level (except we're
               renaming to toggle() because of it)
               http://dev.w3.org/csswg/css3-values/issues-lc-2012#issue-13
   - RESOLVED: Fix error the UA stylesheet rule for ul
               http://dev.w3.org/csswg/css3-values/issues-lc-2012#issue-14
   - RESOLVED: Add a note to clarify computed style comparisons better
               http://dev.w3.org/csswg/css3-values/issues-lc-2012#issue-15
   - RESOLVED: Reject deferring cycle() to L4
               http://dev.w3.org/csswg/css3-values/issues-lc-2012#issue-16

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

Line Layout
-----------

   stevez: what I'm setting out to do is determine where the baseline
           lies in the line
   stevez: need to do that because that's the thing which is a line from
           the perspective of the linegrid
   stevez: sorry, the dominant baseline
   stevez: there are at least some cases that behave strangely, and I'm
           trying to understand why
   stevez: I am continuing to work on it, just set up meeting with John
           to go over stuff by the next meeting
   stevez: apologize for not getting as far as I'd hoped, but that's all
           I wanted to talk about at this meeting
   TabAtkins: do you think that I need to interact with you wrt changes
              to flex box for this?
   stevez: yes. I want to have an offline conversation because I'm concerned
           with the differences between doing stuff in boxes and doing the
           whole line
   ACTION TabAtkins to discuss with stevez about how line layout and line
          snapping should work in flexbox
   <trackbot> Created ACTION-471

   dbaron: you said you were trying to understand why things behave strangely.
           Was that with respect to existing implementations, or specs?
   stevez: they're behaving differently to how I read the 2.1 spec, but
           every browser does the same thing
   dbaron: I might be able to help if you want to chat over the next few
           days and show me examples
   florianr: I don't think anyone at opera has a clear understanding of our
             behaviour
   florianr: e.g. we behave differently on japanese and english OSs
   stevez: I'm trying to figure out what are bugs and what are genuinely
           interoperable behaviour
   ACTION stevez to talk to dbaron about possible reasons for surprising behavior
   <trackbot> Created ACTION-472

Values and Units
----------------

   ACTION fantasai: update v&u with resolutions
   <trackbot> Created ACTION-473

   <fantasai> http://dev.w3.org/csswg/css3-values/issues-lc-2012
   TabAtkins: just a few issues to resolve
   TabAtkins: we skipped cycle deferred thing because dbaron proposed
              some solutions
   TabAtkins: need to look at issue 24, issue 27, issue 16

   TabAtkins: spec wasn't clear about what is a number and what is a
              dimension. We have a very clear definition that hooks
              into the parser.
   TabAtkins: expect specific tokens after stripping whitespace
   TabAtkins: done that for all the cases. Is this acceptable?
   dbaron: one of the motivations for attr() was to be able to represent
           the default HTML stylesheet using it
   TabAtkins: html has its own set of attribute parsing rules. Are they
              compatible?
   TabAtkins: HTML's number parsing is more forgiving that CSS's number
             parsing. HTML just discards junk after a number, we don't
   fantasai: another case is color.
   dbaron: how much is it a goal for attr() to be able to do that?
   TabAtkins: it is theoretically, but not as an actual goal to put it
              in the UA style sheet
   dbaron: sounds OK with me, though we may at some point want to add
           additional variant types to support HTML values. Could be
           proprietary
   TabAtkins: I think that's acceptable.
   fantasai: might even be able to tweak the parsing rules later.
   fantasai: no-one will rely on something not parsing
   TabAtkins: wouldn't be surprised if they didn't notice when something
              didn't apply
   TabAtkins: and then stuff would turn on when we changed behavior
   fantasai: I don't think many people will be using attr() by then
   TabAtkins: I would object to making the color type parse like HTML
   TabAtkins: HTML color isn't a superset of CSS color
   dbaron: could have html-color in the future if needed
   Bert: so HTML color isn't a superset of CSS color?
   dbaron: no, for legacy reasons. HTML color accepts any keywords
           and looks for hex digits within that
   Bert: so what appears in the infoset?
   fantasai: it's exactly the string that was provided
   fantasai: this isn't the parsing part, but the part that turns it
             into a color
   <dbaron> <body bgcolor="lightgoldenrod"> is interoperably light blue
   TabAtkins: so we're suggesting no change to text->info set, but a
              change to infoset->value
   TabAtkins: the HTML parser actually parses valid CSS as a completely
              different color
   TabAtkins: I don't want to have different results pulling values in
              from an attr e.g. for hsl
   Bert: you will anyway, I don't see a problem with it
   TabAtkins: yes but that's for legacy reasons. I don't think you
              understand how horrible the HTML rules are.
   Bert: I don't care how weird they are, I think we should treat strings
         from attr with our rules
   TabAtkins: that's what we're suggesting
   Bert: so no attr in UA stylesheet?
   TabAtkins: correct
   RESOLVED: Close issue 24 with no change

   fantasai: next issue is 27.
   fantasai: suggestion to have order-sensitive "one or more, in order"
             combinator
   fantasai: can write "this? that?" to make both optional, but could be
             empty. Can't have "this | that | this that" without writing
             it out in full
   fantasai: we have "this || that", which means
             "this | that | this that | that this"
   fantasai: suggestion to have a version of this with an order that matters
   fantasai: suggestions on the list: use a triple bar, use double question
             marks
   fantasai: do we want to have this and if so what should the syntax be?
   dbaron: I think we should be hesitant to add new syntax to our grammar
           lines. It's more stuff for people to learn to be able to read
           our spec
   fantasai: but it's also hard to read when grammar lines get really long
   dbaron: I also think that ?? is a disaster
   dbaron: do we want to use this syntax? Seems like it's not one to encourage.
   TabAtkins: it already exists in a few places, e.g. radial gradients.
   fantasai: and border-image
   dbaron: it's also going to be hard to read with a symbol that people
           don't know
   stevez: is * in the grammar?
   fantasai: yep
   stevez: if you use the double bar but add a character to the double bar
           that says "in this usage the order matters"
   arno: how about |&|
   (people don't like)
   TabAtkins: if we can't agree on specific syntax right now it's not a
              problem
   Liam: I like the old version
   Bert: me too.
   Liam: break out long phrases into secondary rules
   TabAtkins: we don't like doing that because it makes things harder to read
   Liam: yeah but it is harder to read anyway. I'd rather do that instead
         of introducing new syntax
   fantasai: how about &| ("and or")
   TabAtkins: oooooh, I liiiike that
   florianr: not sure it's immediately obvious, but it's easy to remember
   hober: and it kinda maps back to order (and-or)
   stevez: and usually means without order
   dbaron: difficult to know difference between this and &&. && is an
           'and' without ordering constraint, this has ordering constraint
   TabAtkins: maybe we should fix &&
   stevez: What about ||>
   stevez: this conveys the ordering
   TabAtkins: I think we should defer and keep thinking about this
   fantasai: it's an editorial change so we could splice it in during CR
   RESOLVED: defer issue 27

   TabAtkins: next issue is 16. This is based on 12-15, which are deferred.
   dbaron: I think 12-14 are easy to resolve: 12 - you can't do that,
           13 - reject proposal, 14 - fix sheet
   TabAtkins: let's look at 15.
   TabAtkins: problem is cycle relies on comparing computed value with
              each value of cycle, which is new
   dbaron: this is a comparison of computed values. Transitions start
           when a computed value changes. So transitions depend on
           knowing that 2 computed values are different
   TabAtkins: that shouldn't be a problem. The issue isn't about that,
              but about whether top left is the same as left top when
              cycling background position. Answer is for computed values:
              yes
   TabAtkins: so should we just say "like transitions", or define this
              more carefully
   dbaron: the computed value line in our specs defines an information set -
           a set of concepts that the computed values can take
   TabAtkins: so is transitions under defined?
   dbaron: I think it is, but it's not that hard to define
   dbaron: here and there there's probably a computed value line in a
           spec that isn't very clear, but the underlying definition
           is those lines
   TabAtkins: so for now we can just explicitly say we're comparing
              computed values and get implementors to tell us if they're
              ever confused so we can fix that in the spec
   plinss: I think if there's 2 specs that talk about comparing computed
           values, and one references the other, which doesn't define
           that, this is bad
   dbaron: also, a definition should be in V&U, not transitions
   fantasai: what more do we need over "compare computed values"?
   dbaron: some kind of statement about what a computed value is
   plinss: there's lots to define there, e.g. is 72 points == 1 inc?
   fantasai: yes, because they get converted to absolute values
   plinss: that should be explicit
   dbaron: it is. It's more things like pairs of values
   fantasai: we need to go and fix the computed values lines to not
             imply an order, if there are any left that do
   TabAtkins: that's not a problem because they'll still compute to
              the same thing for comparison
   dbaron: e.g. flex before it was a shorthand took 3 values in any
           order. It's computed value is the combination of the 3 values,
           not ??
   TabAtkins: so I want to say just simply compare computed values,
              with a note that gets developers to come to us if they
              think something's weird
   fantasai: yes, just a note that says these are abstract things,
             not strings
   dbaron: have to be careful about computed values with optional parts.
           Is the presence of the optional part substantive, or can it
           be replaced by its default if the optional part isn't present?
   dbaron: that text could be in values spec

   fantasai: I have a question about the HTML stylesheet code on screen
             http://lists.w3.org/Archives/Public/www-style/2012Apr/0700.html
   fantasai: is it really correct?
   dbaron: could have designed this to work differently, but it's complicated
           because having a list marker is defined by a pair of properties
   <dbaron> li > ul should be li ul
   fantasai: I want to make sure we get this right before we put it in
            the spec
   <dbaron> (display: list-item and list-style-type)
   fantasai: are we sure we want a descendant selector here, or should we
             find some way to work around it?
   TabAtkins: I think it's acceptably bad. Would love not to have descendant
              selectors in UA stylesheets, but...
   fantasai: there's other approaches, do we want to look at those?
   TabAtkins: not at this level
   fantasai: are we looking at stuff for the future?
   dbaron: we might need a new function
   TabAtkins: e.g. a function like cycle that takes several values, but
              first takes an identifier that gets resolved on the first use
   dbaron: this breaks the em use case
   TabAtkins: yes. But I think cycle is a better name for that functionality
              and we should call the current functionality toggle, because a
              lot of the common cases will just be switching between 2 values
              anyway
   TabAtkins: if we want to keep this open I'd prefer that rename
   dbaron: I'm fine with that
   florianr: not constrained by existing implementations?
   No, none exist.
   RESOLVED: rename cycle to toggle, leave it as is
   RESOLVED: issue 12: disallow values with commas at this level
   RESOLVED: issue 13: won't fix in this level (except we're renaming
                       to toggle() because of it)
   RESOLVED: issue 14: we will fix the UA stylesheet
   RESOLVED: issue 15: add a note to define computed style comparisons better
   RESOLVED: issue 16: reject
   TabAtkins: so we're at 0 LC issues. When should we do CR?
   fantasai: I think we should get the edits out and let people review
   TabAtkins: we'll be asking for CR next time we meet then

Meeting adjourned.

   <tabatkins> New UA stylesheet for ul:
               ul { list-style-type: disc; }
               ol ul, ul ul /* and the other legacy lists that you need to list here */
                 { list-style-type: toggle(disc, square, circle); }"
Received on Wednesday, 16 May 2012 03:13:50 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:54 GMT