- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 15 May 2012 20:13:18 -0700
- 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 UTC