W3C home > Mailing lists > Public > www-style@w3.org > April 2014

[CSSWG] Minutes Telecon 2014-04-23

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 24 Apr 2014 11:37:25 -0400
Message-ID: <CADhPm3vfcS6Jm-3KRk+OuML-nyOfyKATr2LPRoCWMTXLqJAOMA@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Thursday, 24 April 2014 15:37:53 UTC