Breakpoint Get Context 2.x about breakpoint HOT 17 CLOSED

@robwierzbowski If you'd like to take a crack at this, that'd be great. Please fork off of upstream/2.x.x and work off of that. Please issue a pull request for this feature when you're finished.

from breakpoint.

Because @canarymason is sitting next to me, doing terrible things, and guilt tripping me about it, feel free to replace the base64 encoded variable and function names with human-readable ones.

from breakpoint.

Sure, I can port this over. My question about 'or' context is should multiple values be returned in order or sorted least to greatest? Would sorting remove the need for falses?

from breakpoint.

We do not want to sort as we always want 100% parity between different contexts. nth($min-width, 2) and nth($min-height, 2) should always refer to the same feature between or clauses and sorting them would break this connection.

from breakpoint.

That makes sense. Maybe I'm missing something, but is 2.x.x setting context at all? I don't see any code that writes to the $TXkgdmFyaWFibGUhIEdvIGF3YXkh variable.

from breakpoint.

No, probably not. I don't think I've written those in because I was more focused on various other things.

On Tuesday, March 12, 2013 at 9:34 PM, Rob Wierzbowski wrote:

That makes sense. Maybe I'm missing something, but is 2.x.x setting context at all? I don't see any code that writes to the $TXkgdmFyaWFibGUhIEdvIGF3YXkh variable.

—
Reply to this email directly or view it on GitHub (https://github.com/canarymason/breakpoint/issues/38#issuecomment-14816807).

from breakpoint.

I can't port context over until we know what the structure for and/or lists is going to be. For the curious, here's the get context partial from my branch which returns context just like you are requesting.
https://github.com/robwierzbowski/breakpoint/blob/2.x.x-parens/stylesheets/breakpoint/_context.scss

from breakpoint.

We know what it's going to be, we are using the syntax in the 2.x.x branch, unless I'm misunderstanding the issue

On Mar 12, 2013, at 10:26 PM, Rob Wierzbowski [email protected] wrote:

I can't port context over until we know what the structure for and/or lists is going to be. For the curious, here's the get context partial from my branch which returns context just like you are requesting.
https://github.com/robwierzbowski/breakpoint/blob/2.x.x-parens/stylesheets/breakpoint/_context.scss

—
Reply to this email directly or view it on GitHub.

from breakpoint.

Not the breakpoint feature list structure, but the context list structure. Or query contexts need to be joined in some way.

(feature value), (feature value), (feature value) // And context list, BP1 style
feature value // Single feature context list, BP1 style
((feature value), (feature value), (feature value)), 
  ((feature value), (feature value), (feature value)) // Or context list?

Because lists can be one, two, or three deep testing for comma or space list type doesn't work to let us know if we have an or query. I added an 'or' string at the front of each or context so that I could tell without array traversal that I was dealing with an or context list, like so.

('or' (feature value), (feature value), (feature value)), 
  ('or' (feature value), (feature value), (feature value)) // Or context list

from breakpoint.

I think the easiest way to structure it so I can get the output I would like is something like the following:

$context: feature (value, value…), feature (value, value…)…

This way feature can act as a key for us to query off of easily and get all values related to that feature. We're also then able to append as needed in order for each feature, allowing us to pair up multiple value based on their position.

On Mar 13, 2013, at 8:51 AM, Rob Wierzbowski [email protected] wrote:

Not the breakpoint feature list structure, but the context list structure. Or query contexts need to be joined in some way.

(feature value), (feature value), (feature value) // And context list, BP1 style
feature value // Single feature context list, BP1 style
((feature value), (feature value), (feature value)),
((feature value), (feature value), (feature value)) // Or context list?
Because lists can be one, two, or three deep testing for comma or space list type doesn't work to let us know if we have an or query. I added an 'or' string at the front of each or context so that I could tell without array traversal that I was dealing with an or context list, like so.

('or' (feature value), (feature value), (feature value)), ('or' (feature value), (feature value), (feature value)) // Or context list
—
Reply to this email directly or view it on GitHub.

from breakpoint.

That's a clever way around the depth issue. The downside I see is extra complexity; you'd have to have logic to append falses to every existing feature not in an 'or' query, where if you keep each context list separate the get_context function can take care of returning the value if it finds the feature in the context list, and false otherwise.

from breakpoint.

Yup, that's an issue, although that complexity isn't so terrible as you can have a counter rolling to see if the length of each feature that is in there is the correct length, append false, and if a feature is getting added that doesn't already exist, you can prepend false for the number of items in your counter - 1

On Wednesday, March 13, 2013 at 9:50 AM, Rob Wierzbowski wrote:

That's a clever way around the depth issue. The downside I see is extra complexity; you'd have to have logic to append falses to every existing feature not in an 'or' query, where if you keep each context list separate the get_context function can take care of returning the value if it finds the feature in the context list, and false otherwise.

—
Reply to this email directly or view it on GitHub (https://github.com/canarymason/breakpoint/issues/38#issuecomment-14841977).

from breakpoint.

What's the progress on this? Can you give us an update please?

from breakpoint.

Did a little work on this today. There are a couple problems with the way this version is architected to make porting my version work smoothly.

I would suggest switching the parsers to building the context list, and then printing the query from that context list. This would remove the need for double setting in each parser (you can't do it the other way around, i.e., build the context list from a complete query string, because it's a string). You could then use -get-context to find your no-queries and media types for printing, removing the first/last order requirements you have right now. If you're interested in this I can put some code hours in. If you prefer to stick with the way things are currently, I'm going to bow out for now.

from breakpoint.

Hey Rob,

I'm jumping in on this issue. We need to move forward using the current architecture and I have some momentum right now.

from breakpoint.

No worries. Enjoy.

from breakpoint.

Done

from breakpoint.