- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 24 Apr 2014 11:37:25 -0400
- To: www-style@w3.org
Backgrounds and Borders
-----------------------
- fantasai requested more attention to the change in spread-radius
including some assistance writing a document to illustrate
the changes.
Non-Element Selectors
---------------------
- RESOLVED: FPWD of Non-element Selectors
- The group expressed a desire to have a level number added to the
name, though what number it should be will decided on the
mailing list.
calc() unit algebra
-------------------
- The group inquired about the specifics of how division by
infinity would be handled
- There was also a lot of uncertainty about if the sign of 0
should be tracked.
- It was felt that since current behavior creates a parsing error,
no changes needed to be made to level 3.
- RESOLVED: Add calc() algebra to level 4 and keep an issue in
there about +0/-0 handling
Subgrid Keyword
---------------
- Conversation will stay on the mailing list.
Percentage Margins/Padding on Grid/Flexbox
------------------------------------------
- Tab expressed a desire to keep grid and flexbox consistent, no
matter the final decision.
- Rossen stated that Microsoft would have lots of backwards
compatibly issues if the handling of grid was changed at this
point.
- RESOLVED: Keep current behavior where percent vertical
padding/margins resolve against height.
Item height when max-height applied to flex container
-----------------------------------------------------
- It was felt that what the current spec said should happen was
clear, but that the alternate Blink behavior was more
desirable.
- RESOLVED: Change the spec's (flexbox) max-height implementation
to match Blink's implementation.
Box model/render tree
---------------------
- Deferred until next week
:role() selector
----------------
- There was agreement about it being interesting and/or possible
to work around the dependency issues with a pseudo-class
matching ARIA roles, but discussion will continue on the
mailing list.
The Last Grammar Combinator
---------------------------
- There wasn't certainty that the last grammar combinator was
needed, but exploration will continue.
- TabAtkins suggested a ?? combinator, which wasn't adored. Other
possibilities were brought up in IRC after the telecon ended.
====FULL MINUTES BELOW======
Present:
Glenn Adams
Rossen Atanassov
Tab Atkins
David Baron
Bert Bos
Tantek Çelik
Elika Etemad
Daniel Glazman
Koji Ishii
Dael Jackson
Taichi Kawabata
Brad Kemper
Chris Lilley
Peter Linss
Michael Miller
Edward O'Connor
Simon Pieters
Anton Prowse
Matt Rakow
Florian Rivoal
Simon Sapin
Alan Stearns
Greg Whitworth
Steve Zilles
Regrets:
Dave Cramer
Dirk Schulze
Lea Verou
ScribeNick: dael
Backgrounds and Borders
-----------------------
plinss: Let's get started.
plinss: Any additions?
fantasai: I'd like to ask about backgrounds and borders if anyone
can help with author outreach.
plinss: Go ahead.
plinss: Anything else you want to say?
fantasai: We have a LC there's a couple of comments from MaRakow.
fantasai: What I'm hesitating is we haven't gotten comments from
spread-radius change,
fantasai: To make it continuous from 0 to non-zero.
fantasai: I'd like someone to help me write an article that helps
explain it with pictures since from their prospective
it's significant.
TabAtkins: I can help.
TabAtkins: We can write it on Thursday.
fantasai: Also grid layout is looking for review with algorithms
Non-Element Selectors
---------------------
<plinss> http://dev.w3.org/csswg/selectors-nonelement/
plinss: There was a request for selectors non-element to go to FPWD
* fantasai hasn't seen it
plinss: Any objections?
glazou: Nope. I'm strongly in favor.
plinss: Okay.
<ChrisL> no objection: got a link to ED? [link above]
RESOLVED: FPWD of Non-element Selectors
* dbaron is still loading the spec
plinss: I have one request. I would like to have it add a level 1
to the title.
plinss: We lose track when specs don't advertise their level.
fantasai: I feel like it's a piece of selectors which is at level
4 now.
* ChrisL selectors 4.1
glazou: I'm glad to see this outside selectors because I don't
think browsers will want to implement this part,
glazou: At least not in the CSS engine. It won't work the same as
the rest of selectors.
plinss: I don't feel strongly about level, I just want to see some
level added to it.
glazou: It's only a proposal for the time being and if it doesn't
make progress and selectors 4 does I don't want to block
selectors.
fantasai: Oh, yeah, it shouldn't be in Selectors 4.
glazou: It's good where it is.
plinss: At some point we should see where it fits, but not on the
call.
<dbaron> I wonder if it's a problem that there's material in the
Abstract ("not intended to be used in CSS") that's not in
any other part of the document.
calc() unit algebra
-------------------
<astearns> http://lists.w3.org/Archives/Public/www-style/2014Apr/0101.html
TabAtkins: I can address this. It's proposing how to deal with
dividing by unit-ed values
TabAtkins: It works widely when we add more math operations to
calc()
TabAtkins: Right now when you divide in calc() it must be a number,
TabAtkins: Because we cannot in general case decide if a unit will
be 0 at parse time.
TabAtkins: We like making division by 0 a parse time error.
TabAtkins: This proposal is: we allow unit division and division
by 0 at parse is an error. Division by 0 not at parse
becomes an infinity and infinities propagate
TabAtkins: At the end of the expression is, if it's an infinity
it's just the largest value possible.
TabAtkins: Implementors all have a unit it doesn't go beyond.
TabAtkins: In addition a few of the units that are reciprocals
would flip themselves around.
* ChrisL proposes the NaN unit
TabAtkins: And that's basically it. It doesn't require tracking
complicated unit algebra.
TabAtkins: For example you can't multiply links together. You have
to do order so you don't stack units.
TabAtkins: The proposal seems simple to me. It doesn't seem like
it would be complex extra tracking. The largest
available size is weird, but seems legit and it's
continuous as the value approaches 0.
TabAtkins: If we get a very small number we might exceed the
largest allowed value anyway.
TabAtkins: I am totally willing to accept this into values and
units and I want implementor interest before I pull the
trigger.
<fantasai> This should go into V&U L4
<SimonSapin> q+ to say two different behaviors for division by
zero is weird.
ChrisL: You said this is a large number rather than infinity, what
happens if you divide two infinities.
TabAtkins: Just like a NaN it effects all things. If infinity
shows up in any context it becomes infinity.
TabAtkins: Technically we need to track the sign.
ChrisL: What about the reciprocal?
TabAtkins: Let's see if the proposal tracks that.
TabAtkins: Dividing by an infinity produces 0.
<ChrisL> in general its good and better than throwing an exception.
<dbaron> q+ to say that length * length / length seems like it
might be more desirable than the other aspects of unit
algebra.
florian: Do we track the sign of 0?
florian: If you do 1m - 0px from one end ...
<glenn> -0 = 0
TabAtkins: This is true. I can go either way either simply not
care about - 0 or let's be consistent and dividing by -
0 creates a negative.
florian: But we don't have it. If we have 1n-15px and your n
transitions from 5 to smaller, you're going there but
there's not a trace of where you came from.
TabAtkins: You can type -0 and it means something distinct in JS
TabAtkins: Continuity does matter. If you're going from -0 to +0
it does matter.
<glenn> thinks it should not be treated as distinct
florian: If you plan to cross yes, but if you plan to stop there
the continuity argument doesn't work.
TabAtkins: It works most of the time, but when you have a - link
fly off to infinity...
TabAtkins: In the proposal he calls that out and says we only have
one 0 and it goes to + infinity.
TabAtkins: You can get - infinity, but not from 0.
florian: It's defined but doesn't give the argument of continuity
at the end.
TabAtkins: In the case where you're approaching -infinity from one
side it doesn't work. Where you're doing + it's fine
and where you're crossing it's fine.
TabAtkins: In a rare case we lose continuity but it usually work.
<BradK> -infinity / -0 = black hole?
florian: I don't have a good grasp on use cases, but why is it
rarer?
TabAtkins: Because most values are positive. We don't have many
instances of a negative.
florian: In general that makes sense but in relation to this I'm
not sure what people would use this for. It sounds
reasonable, but I'm not sure.
TabAtkins: It's either that or adopt full floating point semantics.
<SimonSapin> Do we allow attr() on other non-literals in calc()?
What does this do? <p data-z=0 style="width: calc(
100px / attr(data-z))">
ChrisL: It probably is complex but is also probably being
implemented on to of IEEE floating point anyway.
TabAtkins: I can argue for simple, but if the complex is being
used that's fine.
TabAtkins: We can leave that open as an issue and see what people
think with more time.
SimonSapin: I like it in general, but don't like two different
behaviors for division by 0.
SimonSapin: It's not always obvious 0 division is detectable at
parse time.
TabAtkins: It is completely detectable.
plinss: When you can't detect at parse you fallback and when you
can't you don't get the fallback behavior
TabAtkins: I'm fine with making detectable division by infinity
use case as well. Unlikely that's in the wild a lot.
dbaron: I'm fine as well, but want to note TabAtkins description
is wrong. Issue isn't if it has units, but is if you have
to analyze them.
TabAtkins: The calc() spec makes the statement that producing a 0
unit isn't the same as 0. It's still united and
therefore invalid.
TabAtkins: 5px/0px breaks current parsing.
dbaron: I'm answering a question about Zach's proposal. I'm fine
with changing it so that all division by zero uses the
same rules and probably it's a good idea.
SimonSapin: I'd rather have only one behavior of division by 0.
TabAtkins: Then all division by 0 uses this semantic and we don't
have about parse time error checking.
<zcorpan> what about 0/0 ?
<zcorpan> also +infinity?
<SimonSapin> zcorpan, 0/0 is +infinity in the proposal IIRC
<zcorpan> SimonSapin: ok. that's different from JS though
???: Is this the only issue?
TabAtkins: Yes, I think that's the issue. What I'm saying is all 0
division creates infinity and remove parse time
detections.
TabAtkins: Does a resolution sound reasonable?
dbaron: So I think the, I'm concerned about limits on unit algebra
because length * length/length seems more useful and not
that hard to track.
dbaron: I'd be inclined to allow instead of forbid.
TabAtkins: What do you mean it's a bunch of integers?
dbaron: You just have to track a bunch of dimensions.
TabAtkins: You'd be okay with length * time/length - time.
TabAtkins: We were going for simplicity, but if you think it's
better I'm fine with that.
<Bert> (I agree with dbaron: a / b * c should always be a * c / b,
except, possibly, for overflow.)
<MaRakow> Some of the unit conversions look a bit off to me but
I'll catch up and respond on the mail (e.g. <number> / <
resolution> = <length>?)
florian: I think it's non-obvious if we don't do that.
TabAtkins: I have zero problems with that.
<dbaron> q+ to ask about implementor interest (Tab's original
question)
TabAtkins: In that case... Does adopting unit algebra to calc()
with an issue that we need to decide if we have to
adopt floating point work?
florian: I'm not sure if that right. Do we already have units?
TabAtkins: We're linear by nature.
<ChrisL> except for color values which are not linear
dbaron: We have time and frequency.
TabAtkins: And length and resolution
florian: So length is the only case?
TabAtkins: Correct.
florian: That makes it easier.
dbaron: One thing TabAtkins asked is is there implementor interest
and we didn't discuss that.
dbaron: I think this is interesting, but not top of our priority
list right now.
TabAtkins: Okay. I don't know how to decide if that means that's
good to add, though.
fantasai: I think that means add it to level 4.
TabAtkins: Okay. If we did that we'd need to add infinity to
current level for future compat.
??: Sounds okay to me
dbaron: What's the calc() implementation now?
TabAtkins: Blink does. It's not universal but almost. I'm not sure
about WebKit
fantasai: IE does implement.
dbaron: It sounds like if we have interop the new thing should be
in level 4
florian: Well, calc() doesn't work with MQ
fantasai: That's an implementation bug.
plinss: There's an issue with division that's small and perhaps
should be in 3 if implementors are willing to do it now,
perhaps.
fantasai: We shouldn't add new stuff to L3, because there's a
subset that's deployed and implemented and people need
to know what that is.
dbaron: Maybe, but changing it is glossing over the compatibility
problem.
TabAtkins: A moment ago you said you were fine, but now you say
you're fine but will all 0 div into infinity.
dbaron: Yes, but it's a decent chunk of work.
florian: Are you saying it's okay now or in future?
TabAtkins: Future makes compat worse. I think Blink would be okay.
fantasai: What's affected?
TabAtkins: If you're dividing by 0 or a unit that becomes 0.
fantasai: So currently that gets parsed to error so presumptively
not many people are relying on it so let's ignore that.
<BradK> It could be used as a CSS browser filter
dbaron: In general we don't worry about compat when changing
previously invalid things into valid.
fantasai: That's kinda the point.
<fantasai> of forwards-compatible parsing.
fantasai: calc(2em/5px) is also currently parsed as invalid, and
we'd be changing that, too.
TabAtkins: There is the chance you rely on it not working, but
every change may have that compat problem.
TabAtkins: So the resolution would be add calc algebra to level 4
and keep an issue in there about +0/-0 handling
TabAtkins: Does that sound good?
plinss: Any objections?
RESOLVED: Add calc() algebra to level 4 and keep an issue in there
about +0/-0 handling
plinss: What about the division behavior in level 3?
TabAtkins: We can just change that in future when we do full unit
algebra.
plinss: Is that okay? [silence] Okay.
Subgrid Keyword
---------------
fantasai: There was no mailing list discussion until last night.
fantasai: I don't think we have any consensus on mailing list.
TabAtkins: The main issue is there's not discussion because you're
the one objecting.
fantasai: Yes but we were going to discuss use cases and no one
commented on that except dbaron whose questions I
answered and SimonSapin removed his support for removing
the feature.
plinss: So one more pass for mailing list discussion?
Rossen_: Yes, let's move on.
Percentage Margins/Padding on Grid/Flexbox
------------------------------------------
<astearns> http://lists.w3.org/Archives/Public/www-style/2014Apr/0184.html
TabAtkins: This was raised by 2 people separately.
TabAtkins: They argued current behaviors of flexbox is different
than how it works in block where vertical positions are
resolved against width.
TabAtkins: They say this is inconsistent and allows certain hacks
that allow you to use % padding
TabAtkins: They argue we should revert to previous version like
Block.
TabAtkins: And where flexbox and grid should be consistent, we
should change grid too.
TabAtkins: We had done this in grid and then back imported to
flexbox.
TabAtkins: I can go either way, but I strongly think they (grid
and flexbox) should be consistent. Either works, but I
want to hear from implementors so we edit one way or
another.
TabAtkins: I think Microsoft felt okay with changing flex, but
wanted to keep grid the same. Can someone explain why
it's okay to break consistency?
<BradK> Why was grid different?
<dbaron> q+ to comment on why vertical makes sense
Rossen_: The argument for keeping same length for % resolution
kinds makes sense to me. We'd have a significant compat
hit if we changed grid at this point.
Rossen_: I'm not sure we can make such a deep change for apps
using grid.
Rossen_: So our concern is breaking compat. I hear you and
consistency is important between flex and grid.
Rossen_: I'm not sure we can make a compromise. I need to go dig
into data and see how much breakage would occur.
Rossen_: We have enough apps built on % resolution from height in
grid, but not for flex.
Rossen_: That's the reasoning.
TabAtkins: Okay.
TabAtkins: If necessary we could work around that compat issue
with a switch that's one way for legacy and another way
for the rest.
Rossen_: That's always...having the ability to take relative size
resolution from height or width...if you can choose from
height now width...
Rossen_: That would be cool if you could do it universally, but we
don't have that.
Rossen_: Are you suggesting a switch like that?
TabAtkins: It's a resolution to the problem and potentially
interesting because it would let you use vertical % on
block.
TabAtkins: I'm okay with this and if this makes everyone happy
it's good.
* fantasai is unsure what we're accepting here
Rossen_: Let us see what we can find out internally about the
badness a change to % resolution would create.
Rossen_: For now I'd say flex should go back to the rest of CSS
and we need to decide what it would do to us.
<BradK> -ms-grid-padding-percent-sizing: ??
dbaron: I think there's a good bit of logic to changing. The block
layout is based on tradition where width is input, height
is output.
dbaron: In flex and grid there isn't that big difference and
having this weird difference breaks the model that is
actually more symmetric.
dbaron: And it think it ought to be more symmetric and having the
way flex is spec'ed is a good thing.
TabAtkins: I think that's why fantasai and I saw that grid was
doing symmetric, and we switched flexbox to it.
TabAtkins: If we stay symmetric, that would address Microsoft's
concerns, it would make our implementors less happy,
but it's not a huge deal for us.
Rossen_: I was going through the mail, do they want to change it
back so it's more consistent with document centric
approach?
TabAtkins: Yes, their argument is based on expectations. You can
use % padding to control an aspect ratio, but I'd say
we can control aspect ratio directly.
TabAtkins: There's also an issue about the layout for the
containing block, but that's not big.
<fantasai> I think the use case for having both reference width
isn't aspect ratios, but rather having consistent
padding in both dimensions while having that padding
respond to space available
Rossen_: So going back to resolving width and height, I have to
think more about implementation, but I'm pretty sure it's
not a stretch to allow behavior controlled at container
level.
Rossen_: Where you have either traditional width or this and we
can argue which is default.
Rossen_: That way authors can have doc centric or more symmetric
behaviors.
TabAtkins: But if the current is the default, there's less reason
for a flag; I introduced that for compat. It would be
somewhat useful, but not worth the effort.
TabAtkins: Based on the discussion so far I think we can keep
current approach and maybe investigate a separate
property to switch.
TabAtkins: Is that okay with you dbaron?
dbaron: That's fine. I'm uneasy about switches.
TabAtkins: So I think we should resolve to keep current behavior
where % vertical padding/margins resolve against height.
TabAtkins: And as a separate action investigate if a switch is
useful.
TabAtkins: Any objections to the resolution?
plinss: Doesn't sound like it.
RESOLVED: Keep current behavior where percent vertical
padding/margins resolve against height
TabAtkins: I'll investigate the switch.
Item height when max-height applied to flex container
-----------------------------------------------------
<astearns> http://lists.w3.org/Archives/Public/www-style/2014Apr/0292.html
TabAtkins: This is a simple tweek to flex brought up by
gregwhitworth;
TabAtkins: If flex is indefinite but has a max height and the
content is bigger than max, does flex item grow to
contain or is content constrained?
<gregwhitworth> You're right
TabAtkins: Spec says item should...I forget, hang on.
TabAtkins: The flex item gets set to 150px, to size of content,
and overflows the constrained flex container.
TabAtkins: Blink is different and makes flex item stay the size of
flex container.
TabAtkins: This is same as if you set a height instead of max
height.
TabAtkins: Some people think this makes sense.
TabAtkins: Suggestion is we change spec slightly so that a max
height on flex container constrains the item.
fantasai: So how max-height should work is you layout contents and
max-height is violated, you re-layout with the max
height as height and this change seems to make sense
where violating max height doesn't work.
<antonp> +1 for encouraging consistency with the principle that
fantasai described
TabAtkins: I agree. The change would be consistent with how it
should work.
fantasai: If there's other inconsistencies we should change them.
TabAtkins: I'm not sure where, but perhaps where we have aspect
ratios, but if there's any other changes I'm happy to
bring them to the list.
TabAtkins: For now, is there any objection to changing the
algorithm to match Blink?
TabAtkins: Firefox's implementor is for that and I believe
glennadams is for it from IE too.
TabAtkins: So any objections?
RESOLVED: Change the spec's (flexbox) max-height implementation to
match Blink's implementation.
gregwhitworth: How does that compare with Firefox and Webkit?
TabAtkins: Webkit matches Blink, Firefox and IE implement the
current spec, but the implementors are for making the
change.
glenn: Okay.
Box model/render tree
---------------------
* dbaron is skeptical that we'll agree how to define the box tree
in 5 minutes
* dbaron isn't sure if that's what the agenda item is about, though
TabAtkins: It's better to move to a different topic.
plinss: Okay. We'll come back.
* fantasai thinks we should do the Last Combinator topic, it will
hopefully fit in 4 min
:role() selector
----------------
<astearns> http://lists.w3.org/Archives/Public/www-style/2013Jul/0099.html
TabAtkins: The original thread was for a pseudo-class that matched
ARIA roles
TabAtkins: That seemed acceptable to me but there was a recent
addendum to the thread that said some aren't computed
until layout, so having a pseudo would create bad
dependencies.
TabAtkins: Does anyone have insight into this?
tantek: It seems similar to the old appearance property but that
was in other direction.
TabAtkins: Yes.
<dbaron> It seems like a good idea, except for the issue you just
mentioned about ARIA roles not being computed until
layout.
TabAtkins: The ideal is it's most useful for query selector.
tantek: I'm concerned that ARIA would be affected by layout.
TabAtkins: Yes.
tantek: That's my response so we can resolve in a good way.
TabAtkins: I think we should take this to the list and ask how it
happens.
tantek: ARIA affects the semantic and not the layout and we can do
a pseudo based on that. That makes sense to me.
TabAtkins: Let's continue on the list.
The Last Grammar Combinator
---------------------------
<astearns> http://lists.w3.org/Archives/Public/www-style/2014Apr/0230.html
<fantasai> summary: need combinator for "one or more, in this
order"
<fantasai> proposal: Use ?? as combinator
<fantasai> example:
<fantasai> [left | right] |
<fantasai> [left | right]? [<length> | <percentage>]
<fantasai> becomes
<fantasai> [left | right] ?? [<length> | <percentage> ]
TabAtkins: I argue we have 6 common grammar combinations of which
we can express 5.
TabAtkins: We've talked about this before but couldn't get a good
syntax and there was general malaise about adding more
syntax.
TabAtkins: I think the use case is common. We often have a thing
with a main content and a fallback and you need to
express something, but don't care which one.
TabAtkins: In order to do that now you need to do a lot of tricks.
It's not easy and unclear and gets worse with 3 terms.
* tantek thinks this is not a 3 minute topic.
* tantek or even a 0 minute topic at this point ;)
* dbaron wonders if we should really be designing syntaxes this
complicated
* glazou neither
TabAtkins: So I propose we plug this hole so out 2x3 matrix of
combinators is complete.
TabAtkins: I propose we use ?? for the combinator. It also matches
combinator which is 0 or more which you do with
juxtapose. It put the ? between instead if on either end
TabAtkins: So any objections?
fantasai: I put an example in the IRC.
<tantek> wow ?? looks like an error
dbaron: ?? Seems odd.
<plinss> ¿?
<MaRakow> &|
* fantasai would be happy with ¿
TabAtkins: We're open to other ideas. That was just what came to
mind for me.
plinss: Any thoughts?
TabAtkins: If the idea is okay and want to talk more syntax,
that's fine. We've got a thread so please comment. I
think this would make a lot of things better and just
want good syntax.
plinss: Okay, that's the top of the hour. I'll talk to you next
week, well, I won't be here, but the week after. Have a
good week!
**After Telecon IRC Conversation**
<TabAtkins> dbaron: Saying "either A or B, or both" is not overly
complex.
<TabAtkins> It happens in lots of places for simple reasons - image
() wants "a list of urls" and/or "a fallback color".
The <picture> sizes='' attribute wants "a list of
MQ/size pairs" and/or "a fallback size".
<TabAtkins> In essence, this is the "and/or" combinator.
<TabAtkins> (I suspect that's why &| came up as a suggestion in
previous discussions of this.)
<zcorpan> &/?
<TabAtkins> Maybe just // ?
<TabAtkins> Or is that still too associated with comments?
<MaRakow> || means one or more with comma separation, right?
<MaRakow> because normally || would be the logical notation
<TabAtkins> MaRakow: No, you're thinking of multipliers.
<TabAtkins> <foo># is "one or more repetitions, with commas".
<MaRakow> o right
<TabAtkins> a || b means "a or b or both, in any order".
<TabAtkins> Sorry, my use of the terms "one or more" was ambiguous.
<TabAtkins> One or more among these choices, not one or more
repetitions.
<zcorpan> http://picture.responsiveimages.org/#valid-source-size-list
is the current spec for sizes="" which could use this
<TabAtkins> [a? b?]!
<TabAtkins> With ! meaning "can't be empty"?
<zcorpan> that looks ok to me
<zcorpan> [ <source-size>* [ , <source-size-value> ]? ]!
<TabAtkins> [ <source-size># [ , <source-size-value> ]? ]! , rather
<TabAtkins> But dammit, commas strike again!
<zcorpan> right
<TabAtkins> I think we need to just express in the grammar that
commas always implicitly must be omitted if the two
options they separate are missing.
<TabAtkins> Or if it separates the first/last from the rest in a
juxtaposed list, must be omitted if the first/last is
missing.
<TabAtkins> I'd like to say:
<TabAtkins> [ <source-size>#? , <source-size-value>? ]!
<zcorpan> that seems reasonable
<TabAtkins> I'm warming to the use of ! to mean "required".
<TabAtkins> And it means no new combinators, which is nice,
because I seriously do still have to think about what
&& means every damn time.
<TabAtkins> And regularly try to write it when I mean what we were
discussing today.
<zcorpan> i don't know if `[ <source-size>#? , <source-size-value>
? ]!` is more understandable than `<source-size>#+ [ , <
source-size-value> ]? | <source-size-value>`
<zcorpan> but the latter might become hairy if more stuff gets
added
<TabAtkins> Note that #+ is invalid.
<TabAtkins> You can't stack multipliers like that.
<zcorpan> oops. it should be just # ?
<TabAtkins> Yeah.
<TabAtkins> Meant to fix taht a while ago, but forgot.
<fantasai> I don't like []!
<fantasai> Looks like it's supposed to be a multiplier, and it's
not
<fantasai> also, too many brackets makes grammars hard to read
<fantasai> // seems reasonable, it's like || except it requires
ordering
<fantasai> and // has a directionality to it that || doesn't
<zcorpan> so what would the sizes grammar look like with // ?
<TabAtkins> Commas actually make it impossible to use a combinator
for the sizes attr. :/
<TabAtkins> Goddam commas.
<fantasai> heh
<TabAtkins> (Any separator, really.)
<zcorpan> >,>
<TabAtkins> Just allow commas between the two characters of the
combinator!
<zcorpan> that's right
<TabAtkins> I... guess I'm not too opposed to that.
Received on Thursday, 24 April 2014 15:37:52 UTC