Constraint CSS(gridstylesheets.org)
gridstylesheets.org
Constraint CSS
http://gridstylesheets.org/guides/ccss/
56 comments
And here's a GSS screencast [1] that accompanied a tutorial in most recent issue of Net Magazine [2]
[1]: https://vimeo.com/99873002 [2]: http://www.creativebloq.com/net-magazine
[1]: https://vimeo.com/99873002 [2]: http://www.creativebloq.com/net-magazine
Thanks for the link. It did help cement some of the concepts presented on the website, but the presenter did a really poor job of selling some of it: "This... [points to screen] ... I don't know, it's crazy. [next slide]". How does that in any way convey the value of this thing?
Also, his answer to the question "How do we debug GSS styles?" was pretty worrisome: "Just add and remove constraints, and see what breaks it". That sounds to me like what a lot or people are doing with CSS right now, and the idea is horrifying. It's tough to imagine embracing a nondeterministic system where there's no telling what rules you've given it will be obeyed, and which will be ignored - at least in CSS, it's pretty clear when something will be overridden.
Also, his answer to the question "How do we debug GSS styles?" was pretty worrisome: "Just add and remove constraints, and see what breaks it". That sounds to me like what a lot or people are doing with CSS right now, and the idea is horrifying. It's tough to imagine embracing a nondeterministic system where there's no telling what rules you've given it will be obeyed, and which will be ignored - at least in CSS, it's pretty clear when something will be overridden.
Performance would always be my key concern with something like a general-purpose constraint solver. I know that LP is a field in its own right, but I don't have a ton of experience there -- do you think there's a practical path to bringing the performance up to a necessary level (i.e. real-time, <10ms calculation times for complex pages)?
Perf is surprisingly good, suitable for modern web apps. The bottleneck is DOM & CSS selector resolution, not the constraint solver - Cassowary is a beast!
We're working on a lib for pre-computing GSS layouts server-side, but it's significantly more hardcore than traditional pre-processing.
What we really need is browser vendors to offer deeper API hooks into layout lifecycle, painting, etc
We're working on a lib for pre-computing GSS layouts server-side, but it's significantly more hardcore than traditional pre-processing.
What we really need is browser vendors to offer deeper API hooks into layout lifecycle, painting, etc
Did you or someone else ever try combining it with React? Because of the virtual DOM, it'll probably mean that you won't need CSS selector resolution at all. Not sure here - I don't know how the solver gets its input (e.g. how you compute which elements impact which ones - do you read existing offsets and sizes from the browser DOM, or do you do something different?). But somehow I feel that the constraints story and React's render-only pipeline should somehow be able to work together really well.
Does anyone have any real-world examples of GSS? I like the idea, but I'm struggling to imagine what this would look like in an actual system. Maybe I'm nuts but I don't feel constrained by CSS too often. Everything I need, I get from CSS + a decent preprocessor (usually LESS these days). Maybe this is a symptom of using CSS, but I rarely even encounter people describing layouts in the way GSS appears to want me to code them.
I don't have much experience with constraint-based layout systems in general, but from what I read it looks like it's a common practice when developing native solutions. This gives me the impression that systems like GSS are just "CSS for people who are used to building native apps and don't grok CSS".
I don't mean to say that CSS isn't without more than it's fair share of flaws, but I take issue with the statement that doing laying out views on the web is in any way difficult.
I don't have much experience with constraint-based layout systems in general, but from what I read it looks like it's a common practice when developing native solutions. This gives me the impression that systems like GSS are just "CSS for people who are used to building native apps and don't grok CSS".
I don't mean to say that CSS isn't without more than it's fair share of flaws, but I take issue with the statement that doing laying out views on the web is in any way difficult.
> I rarely even encounter people describing layouts in the way GSS appears to want me to code them.
I don't think that's the case… think of how when you're dragging elements around in Keynote or Powerpoint, how you get guidelines that snap in relationships between elements.
This is centered in that, these things have the same width, the space between these two things is 10, the left edges of these things align.
Those relationships are what's expressed. When someone is designing a layout, those are the terms they're going to be thinking in.
I don't think that's the case… think of how when you're dragging elements around in Keynote or Powerpoint, how you get guidelines that snap in relationships between elements.
This is centered in that, these things have the same width, the space between these two things is 10, the left edges of these things align.
Those relationships are what's expressed. When someone is designing a layout, those are the terms they're going to be thinking in.
You're right, for some reason this wasn't apparent to me when I was reading about it. Thanks for pointing that out.
I spend quite a bit of time on both sides of this issue: both doing design work and implementing it.
The appeal of GSS definitely lies in how similar it is to how I conceive of layouts functioning. As a designer I want the grid to be based on divisions of the page, and every piece of software I work on appears in many different "page" sizes depending on the device, resolution, &c.
It's not just that I want my grid fields to proportionally resize themselves, but that the elements themselves need to reorganize themselves to suit different grid conditions.
All of that is really just to say that I also want to see answers to your first question. GSS seems like a reasonably good way to think about this, but I want to see more examples of it in the wild, esp. in production.
The appeal of GSS definitely lies in how similar it is to how I conceive of layouts functioning. As a designer I want the grid to be based on divisions of the page, and every piece of software I work on appears in many different "page" sizes depending on the device, resolution, &c.
It's not just that I want my grid fields to proportionally resize themselves, but that the elements themselves need to reorganize themselves to suit different grid conditions.
All of that is really just to say that I also want to see answers to your first question. GSS seems like a reasonably good way to think about this, but I want to see more examples of it in the wild, esp. in production.
The homepage does a better job of explaining it—minus the syntax-shock to those accustomed to CSS—with examples like this: http://cl.ly/image/3U02110W2w22
http://gridstylesheets.org/
http://gridstylesheets.org/
There is an article about this in the most recent net Magazine issue. The example given made sense but was just edge-casey enough that I came away thinking that normal CSS was probably good enough for me. Plus GSS usage seemed like a bear given the minor advantages.
>>Everything I need, I get from CSS + a decent preprocessor (usually LESS these days). Maybe this is a symptom of using CSS, but I rarely even encounter people describing layouts in the way GSS appears to want me to code them.
I'm not sure how you could possibly know whether or not CSS is good enough without knowing what else may be possible. It sounds like you work with CSS professionally, so it isn't going to bother you if something takes an hour -- that's a perfectly good, billable hour.
Supposedly, people in the past did not know that horses are slow. For my part, I hate CSS. I can't quite imagine what this new system will be like, but it's wonderful to think that progress may be coming.
I'm not sure how you could possibly know whether or not CSS is good enough without knowing what else may be possible. It sounds like you work with CSS professionally, so it isn't going to bother you if something takes an hour -- that's a perfectly good, billable hour.
Supposedly, people in the past did not know that horses are slow. For my part, I hate CSS. I can't quite imagine what this new system will be like, but it's wonderful to think that progress may be coming.
I do a lot of CSS at work, yes.
> it isn't going to bother you if something takes an hour -- that's a perfectly good, billable hour.
I don't particularly care for the implication that I find working slowly to be acceptable. My company rewards developers well for finishing fixed-bid (i.e. almost all) projects early, since it directly results in more revenue for the company - thus, it's in my direct best interest to get any work done (styling or otherwise) as quickly as possible. Plus, I like anything that makes me more efficient / makes things easier for me.
> I'm not sure how you could possibly know whether or not CSS is good enough without knowing what else may be possible.
You've made an error in your reasoning. It would not be possible for me to know that CSS is the best, but it's certainly possible to know that CSS is good enough. There's a certain, explicit bar for "good enough" and that is being able to complete a project in a number of hours that is less than or equal to the amount we quoted our client. I'm able to meet or exceed that bar with regularity - thus, I can conclude that my toolchain as a whole is "good enough".
> Supposedly, people in the past did not know that horses are slow.
My mind is definitely open to a better alternative - however, I feel entitled to a healthy degree of skepticism, given that I'm already doing better than "good enough".
> it isn't going to bother you if something takes an hour -- that's a perfectly good, billable hour.
I don't particularly care for the implication that I find working slowly to be acceptable. My company rewards developers well for finishing fixed-bid (i.e. almost all) projects early, since it directly results in more revenue for the company - thus, it's in my direct best interest to get any work done (styling or otherwise) as quickly as possible. Plus, I like anything that makes me more efficient / makes things easier for me.
> I'm not sure how you could possibly know whether or not CSS is good enough without knowing what else may be possible.
You've made an error in your reasoning. It would not be possible for me to know that CSS is the best, but it's certainly possible to know that CSS is good enough. There's a certain, explicit bar for "good enough" and that is being able to complete a project in a number of hours that is less than or equal to the amount we quoted our client. I'm able to meet or exceed that bar with regularity - thus, I can conclude that my toolchain as a whole is "good enough".
> Supposedly, people in the past did not know that horses are slow.
My mind is definitely open to a better alternative - however, I feel entitled to a healthy degree of skepticism, given that I'm already doing better than "good enough".
I didn't mean to suggest that you would work slowly. Your clients expect you to work with CSS, because it's the accepted solution, and anything else would be reckless. Within those constraints, CSS is a good solution -- circularly, though, because CSS is required by the constraints.
I work in web development, myself, though I haven't been doing it consistently through the years. It seems to be somewhat of a low-margin business, and the day-to-day challenges are mostly around producing reliable results within a budget. In that context, complaining about CSS is beside the point, because the day-to-day concern is doing CSS quickly and well, not replacing CSS with something entirely different. If styling became 5x faster overnight, it wouldn't necessarily be a good thing for practitioners; just like it probably wasn't good for horse-related businesses when cars came along.*
*I'm not taking that analogy too seriously. I will not believe this new styling is a revolution until I see it.
I work in web development, myself, though I haven't been doing it consistently through the years. It seems to be somewhat of a low-margin business, and the day-to-day challenges are mostly around producing reliable results within a budget. In that context, complaining about CSS is beside the point, because the day-to-day concern is doing CSS quickly and well, not replacing CSS with something entirely different. If styling became 5x faster overnight, it wouldn't necessarily be a good thing for practitioners; just like it probably wasn't good for horse-related businesses when cars came along.*
*I'm not taking that analogy too seriously. I will not believe this new styling is a revolution until I see it.
> [...] the day-to-day concern is doing CSS quickly and well, not replacing CSS with something entirely different.
This exactly. I don't think we're ever actually going to get rid of CSS (probably not during my career at least), so I'm very interested in technologies like GSS that ultimately don't try to change the behavior of the browser - just the behavior of the developers.
> If styling became 5x faster overnight, it wouldn't necessarily be a good thing for practitioners
I personally would love for styling to get 5x faster. There's be no reason for me to charge any less for the work, so that'd basically be 5x more dollars for the styling portion of any given project - however, styling already makes up a pretty low percentage of our projects' total spent time, so once again I'm pretty skeptical of anything that could reduce that.
Furthermore, I rarely do layout-related CSS to begin with: Bootstrap handles that pretty well, and most layout work beyond that is well within the capabilities of any intermediate developer.
I think that's the crux of the issue, really. Even though CSS is a subpar tool for doing layouts, the abstractions available today pretty much remove that pain: and CSS is quite good at the non-layout side of styling.
This exactly. I don't think we're ever actually going to get rid of CSS (probably not during my career at least), so I'm very interested in technologies like GSS that ultimately don't try to change the behavior of the browser - just the behavior of the developers.
> If styling became 5x faster overnight, it wouldn't necessarily be a good thing for practitioners
I personally would love for styling to get 5x faster. There's be no reason for me to charge any less for the work, so that'd basically be 5x more dollars for the styling portion of any given project - however, styling already makes up a pretty low percentage of our projects' total spent time, so once again I'm pretty skeptical of anything that could reduce that.
Furthermore, I rarely do layout-related CSS to begin with: Bootstrap handles that pretty well, and most layout work beyond that is well within the capabilities of any intermediate developer.
I think that's the crux of the issue, really. Even though CSS is a subpar tool for doing layouts, the abstractions available today pretty much remove that pain: and CSS is quite good at the non-layout side of styling.
>>I'm very interested in technologies like GSS that ultimately don't try to change the behavior of the browser - just the behavior of the developers
To me, it's not fully clear exactly what parts of the process GSS is trying to change and what the full consequences of it would be. Even if I knew what it was _trying_ to change, I wouldn't necessarily make the assumption that the intended change would be the only change, or even the most salient change, that we as practitioners would actually have to live with. I have to look at something like this from every possible angle before I would trust any such claim, because, well... that's just what I do.
>>I personally would love for styling to get 5x faster. There's be no reason for me to charge any less for the work, so that'd basically be 5x more dollars for the styling portion of any given project
That would be great as long as it lasted, I'm sure. But, I expect that sooner or later, the secret will get out that websites just got faster and easier to develop, and your clients will start to expect to either pay less or get more for the same money. Even if your company doesn't charge by the hour, there's little doubt that some of your competitors are hourly. However it played out, economics is going to prevail, eventually.
I've been feeling some pain from CSS lately, which is definitely at least partly because there are newer tools and techniques available now that I still need to catch up on. My company has a guy who basically does nothing but handle the look of sites, and he ends up putting in some amount of time on practically every project we do. I have always thought of myself as a backend developer first and foremost, but CSS is hard to completely avoid.
>>and CSS is quite good at the non-layout side of styling
I don't know that I've heard it split into layout and non-layout before, but I'm assuming that non-layout is things like attaching colors and fonts to text, etc. CSS isn't bad for non-layout things, but, as far as I can tell, that is all of the easy stuff where there was no real engineering-type problem CSS had to solve, so, to screw that up, CSS would have needed to really work very, very hard at doing some inexplicably weird thing in order to have gotten that part wrong.
To me, it's not fully clear exactly what parts of the process GSS is trying to change and what the full consequences of it would be. Even if I knew what it was _trying_ to change, I wouldn't necessarily make the assumption that the intended change would be the only change, or even the most salient change, that we as practitioners would actually have to live with. I have to look at something like this from every possible angle before I would trust any such claim, because, well... that's just what I do.
>>I personally would love for styling to get 5x faster. There's be no reason for me to charge any less for the work, so that'd basically be 5x more dollars for the styling portion of any given project
That would be great as long as it lasted, I'm sure. But, I expect that sooner or later, the secret will get out that websites just got faster and easier to develop, and your clients will start to expect to either pay less or get more for the same money. Even if your company doesn't charge by the hour, there's little doubt that some of your competitors are hourly. However it played out, economics is going to prevail, eventually.
I've been feeling some pain from CSS lately, which is definitely at least partly because there are newer tools and techniques available now that I still need to catch up on. My company has a guy who basically does nothing but handle the look of sites, and he ends up putting in some amount of time on practically every project we do. I have always thought of myself as a backend developer first and foremost, but CSS is hard to completely avoid.
>>and CSS is quite good at the non-layout side of styling
I don't know that I've heard it split into layout and non-layout before, but I'm assuming that non-layout is things like attaching colors and fonts to text, etc. CSS isn't bad for non-layout things, but, as far as I can tell, that is all of the easy stuff where there was no real engineering-type problem CSS had to solve, so, to screw that up, CSS would have needed to really work very, very hard at doing some inexplicably weird thing in order to have gotten that part wrong.
I totally hear what you're saying abut the horse analogy: I don't know what I don't know.
What I DO know is that as an interaction designer working with CSS for about 8 years, I can say with some personal conviction that CSS is NOT my bottleneck when it comes to building great software. It has limitations and quirks, like anything else that is reality-based, but it's REALLY powerful for layout in terms of variety and depth of interaction. Add SASS or LESS to your workflow and CSS becomes the bee's knee's so to speak with all the power of functions, variables, arrays, etc...
Everything can be improved, I suppose. However, I've seen poor knowledge of programming concepts in business leadership or toxic office politics dash months of work in an instant. As opposed to fiddly fluid layout issues in CSS. Which any skilled coder can do away with in a few minutes.
What I DO know is that as an interaction designer working with CSS for about 8 years, I can say with some personal conviction that CSS is NOT my bottleneck when it comes to building great software. It has limitations and quirks, like anything else that is reality-based, but it's REALLY powerful for layout in terms of variety and depth of interaction. Add SASS or LESS to your workflow and CSS becomes the bee's knee's so to speak with all the power of functions, variables, arrays, etc...
Everything can be improved, I suppose. However, I've seen poor knowledge of programming concepts in business leadership or toxic office politics dash months of work in an instant. As opposed to fiddly fluid layout issues in CSS. Which any skilled coder can do away with in a few minutes.
Thanks for expressing exactly how I feel about CSS. Especially for mentioning preprocessors - a child comment mentions that CSS lacks abstraction, but in a world with Sass/LESS/etc, and tools like Gulp that make these preprocessors pretty much effortless to use, that's really not a concern any more. Hasn't been for years.
There are things I would like (computed properties like attr()), but things like this don't exactly trip me up: a solution is never more than a few lines of Javascript away.
Also, even if you're not a "skilled coder", there's always Google if you get stumped. The likelihood of you being the first person to have trouble doing [supposedly difficult thing] is close to 0.
There are things I would like (computed properties like attr()), but things like this don't exactly trip me up: a solution is never more than a few lines of Javascript away.
Also, even if you're not a "skilled coder", there's always Google if you get stumped. The likelihood of you being the first person to have trouble doing [supposedly difficult thing] is close to 0.
CSS is fundamentally broken -- it lacks a property which is pretty basic to all systems, namely abstraction. I think Paul Chiusano put it way better than I could: http://pchiusano.github.io/2014-07-02/css-is-unnecessary.htm...
Try using a preprocessor.
Needing a preprocessor to be usable doesn't argue for CSS not being broken. On the contrary.
It would take some pretty interesting circumstances for me to argue that using raw CSS is a good idea. As I've said before, the language has plenty of flaws, and using plain CSS without a preprocessor would be, in the majority of cases, irresponsible. Sorry for any confusion.
Thanks to CSS not having that from the start, it led to the situation we have today, where there are at least two different preprocessors to choose from: Sass and Less
Having two solutions is worse than having one solution, and we can credit CSS for creating this situation by not having its own.
Having two solutions is worse than having one solution, and we can credit CSS for creating this situation by not having its own.
>>Which any skilled coder can do away with in a few minutes.
I think the skill you're talking about must be skill with CSS. General programming knowledge doesn't help much in a CSS trainwreck scenario -- at least, it doesn't seem to help me.
Basically what you've said is that CSS can be efficient and powerful when in the hands of an experienced CSS expert. That's not an especially good reflection on the design of CSS itself.
I think the skill you're talking about must be skill with CSS. General programming knowledge doesn't help much in a CSS trainwreck scenario -- at least, it doesn't seem to help me.
Basically what you've said is that CSS can be efficient and powerful when in the hands of an experienced CSS expert. That's not an especially good reflection on the design of CSS itself.
The output from PEG.js for this is... intense:
https://github.com/the-gss/engine/blob/master/dist/gss.js#L1...
(scroll down a few thousand lines to see what I mean)
https://github.com/the-gss/engine/blob/master/dist/gss.js#L1...
This holy if statement from the gods..
This holy if statement from the gods..
LOL. Currently gss.js includes the generated PEG parsers with this madness. When the CLI tools come out, will include a build without the parsers, as it should be...
With new layout modes coming to CSS, including flex and grid, I don't think the statement "float-based & table-based layouts that have remained unimproved to this day" is fair.
Flexbox is a step forward, Grid Layout is awesome but is starting to look like CSS Vars, another spec lost in years of limbo
The myriad of incompatible CSS layout modes, present & coming, are evidence of the lack of a holistic & future-proof foundation. The Constraint CSS primitives can be used to implement Flexbox & Grid Layout in total, not true the other way around. And, such implementations would be fully compatible with each other. BTW, a Grid Layout implementation in GSS is well on its way.
The 2 fundamental layout features lacking in future CSS specs is 1) relative positioning & sizing & 2) true source order independence. Less this is addressed, layout will be tightly coupled with the DOM & good luck centering things
The myriad of incompatible CSS layout modes, present & coming, are evidence of the lack of a holistic & future-proof foundation. The Constraint CSS primitives can be used to implement Flexbox & Grid Layout in total, not true the other way around. And, such implementations would be fully compatible with each other. BTW, a Grid Layout implementation in GSS is well on its way.
The 2 fundamental layout features lacking in future CSS specs is 1) relative positioning & sizing & 2) true source order independence. Less this is addressed, layout will be tightly coupled with the DOM & good luck centering things
I'm all for improving what we have, and the new GSS system does look interesting and could possibly influence CSS. But I think you're reacting too strongly to CSS. AFAIK the normal, flex, and grid layout modes are compatible (in the sense that you can mix them in one page and have things like flex inside grid elements and vice versa). Being a lurker on some standardisation email lists some of the best engineers in the world are on there taking everything very seriously, including future-proofing since everyone is well aware anything they add now will basically have to be supported forever.
I'm not sure I understand your two complaints (isn't there already position: relative and percentage sizes?), but I think good engineering is always about making tradeoffs, and while I don't understand GSS enough to criticise it I feel it's unlikely to be a silver bullet that magically fixes everything in itself, and will likely have its own quirks and pitfalls as well.
I'm not sure I understand your two complaints (isn't there already position: relative and percentage sizes?), but I think good engineering is always about making tradeoffs, and while I don't understand GSS enough to criticise it I feel it's unlikely to be a silver bullet that magically fixes everything in itself, and will likely have its own quirks and pitfalls as well.
How does this work with changing style from Javascript? Can I change constraints at runtime and have the entire page be recalculated? I'm not familiar with the Cassowary solver, can it do partial invalidation? or would it need to recalculate the entire layout if only a minor part changes?
It keeps things up to date with DOM changes using Mutation Observers & it does so intelligently so it won't redisplay whole page.
Cassowary is an incremental solver & is optimized for adjusting constraints in runtime.
Cassowary is an incremental solver & is optimized for adjusting constraints in runtime.
Awesome, that's what I hoped to hear. I'll definitely be trying it out then, anything over CSS :p
Some of the layouts that CCSS would solve can be done with the new 'display: flex;' [1] tools. This can now be used in all browsers including IE10 [2].
[1]: http://css-tricks.com/snippets/css/a-guide-to-flexbox/
[2]: http://caniuse.com/flexbox
[1]: http://css-tricks.com/snippets/css/a-guide-to-flexbox/
[2]: http://caniuse.com/flexbox
I'm a bit jealous of anyone that doesn't have to support IE8. Thankfully we just moved our standard lowest-supported-version of IE to 9, but we still have plenty of projects from when we supported IE8 (even a few from the IE7 days), so it's far from a past problem.
IMHO single most important new CSS tech web badly needs is ShadowDOM - this will make web dev suck less compared to native toolkits development
[edit added below]
...since we will be able to componentize web apps.
Thinking in terms of components is much easier than trying to manage div soup. Please don't by shy and say why I'm wrong instead of downvote.
[edit added below]
...since we will be able to componentize web apps.
Thinking in terms of components is much easier than trying to manage div soup. Please don't by shy and say why I'm wrong instead of downvote.
ShadowDOM isn't that much needed and I have concern as to how good this is going to be. ShadowDOM IS a div soup. It's just hidden from you.
From a developer standpoint, the DOM still need to be handled. Moreover, I haven't seen any discussion with regards to strings in shadowDOM that needs to be pluralized/genderized.
Also, ShadowDOM is outside the scope of the article. This is probably why you got downvoted.
From a developer standpoint, the DOM still need to be handled. Moreover, I haven't seen any discussion with regards to strings in shadowDOM that needs to be pluralized/genderized.
Also, ShadowDOM is outside the scope of the article. This is probably why you got downvoted.
1. "shadowDOM isn't that much needed"
I gave you an argument why I think it's (components) - you just say your opinion - it' not an argument
2. "I have concern as to how good this is going to be"
It IS WORKING already in Chrome. You can try it out [1].
"ShadowDOM IS a div soup." - no it's not. Web component tags are tags like any other HTML tag. You don't get the idea. Div's are like thinking about computer program in terms of electrical signals whereas web components is thinking in terms of program logic. See example video [2] with Google maps component. It just hides unnecessary complexity.
" I haven't seen any discussion with regards to strings in shadowDOM that needs to be pluralized/genderized."
Sorry. Don't get what do you mean. Could you please evaluate ?
"Also, ShadowDOM is outside the scope of the article" well I just express my opinion that there are bigger unsolved issues in webdev than those solved by Constraint CSS
[1] http://www.polymer-project.org/
[2] http://youtu.be/8OJ7ih8EE7s?t=28m26s
I gave you an argument why I think it's (components) - you just say your opinion - it' not an argument
2. "I have concern as to how good this is going to be"
It IS WORKING already in Chrome. You can try it out [1].
"ShadowDOM IS a div soup." - no it's not. Web component tags are tags like any other HTML tag. You don't get the idea. Div's are like thinking about computer program in terms of electrical signals whereas web components is thinking in terms of program logic. See example video [2] with Google maps component. It just hides unnecessary complexity.
" I haven't seen any discussion with regards to strings in shadowDOM that needs to be pluralized/genderized."
Sorry. Don't get what do you mean. Could you please evaluate ?
"Also, ShadowDOM is outside the scope of the article" well I just express my opinion that there are bigger unsolved issues in webdev than those solved by Constraint CSS
[1] http://www.polymer-project.org/
[2] http://youtu.be/8OJ7ih8EE7s?t=28m26s
> I gave you an argument why I think it's (components)
No you did not. "it sucks less" is not an argument (and it's pretty faint praises), it's just your opinion.
> "ShadowDOM IS a div soup." - no it's not. Web component tags are tags like any other HTML tag.
And what do you think lives inside the tags, pray tell?
> It just hides unnecessary complexity.
That's the point, the complexity is still there, just hidden.
> "Also, ShadowDOM is outside the scope of the article" well I just express my opinion that there are bigger unsolved issues in webdev than those solved by Constraint CSS
That's not a very on-topic opinion to express in a thread dedicated specifically to discussing layout in CSS.
It's also wrong, web components make it somewhat easier to reason about the existing mess, they don't actually fix issues. Actually having layouting tools in CSS fixes issues, namely the issue that layouting in CSS is currently intractably brittle.
No you did not. "it sucks less" is not an argument (and it's pretty faint praises), it's just your opinion.
> "ShadowDOM IS a div soup." - no it's not. Web component tags are tags like any other HTML tag.
And what do you think lives inside the tags, pray tell?
> It just hides unnecessary complexity.
That's the point, the complexity is still there, just hidden.
> "Also, ShadowDOM is outside the scope of the article" well I just express my opinion that there are bigger unsolved issues in webdev than those solved by Constraint CSS
That's not a very on-topic opinion to express in a thread dedicated specifically to discussing layout in CSS.
It's also wrong, web components make it somewhat easier to reason about the existing mess, they don't actually fix issues. Actually having layouting tools in CSS fixes issues, namely the issue that layouting in CSS is currently intractably brittle.
>"it sucks less" is not an argument
Yes it's not an argument. It's conventional wisdom that it's easier and faster to create app in native toolkit than in HTML/CSS.
I refereed to my components argument not to "suck less".
>>tags are tags like any other HTML tag. >And what do you think lives inside the tags, pray tell?
You don't have to think about it (you just import the component) as you don't have to think what's current CPU pin state. You just use attributes to communicate with the component.
>"That's the point, the complexity is still there, just hidden."
And there is a value in this. Higher level langs hide complexity as well (eg. C# vs C) and that makes them usable.
>It's also wrong, web components make it somewhat easier to reason about the existing mess, they don't actually fix issues
I don't agree. In my entire web dev career single biggest pain in the ass was more or less like "what CSS rule is breaking my div style".
Since ShadowDOM brings CSS fence between components as you probably know (do you?), ShadowDOM makes it way easier to create HTML/CSS ui simply because it's hard to make CSS rules breaking whole app view.
I do agree layouting is an issue - it's just not that important at least for me - joe average web dev
[edit added what gives us Shadow DOM CSS boundry]
[edit2 - hell yea! no arguments? just downvote!]
Yes it's not an argument. It's conventional wisdom that it's easier and faster to create app in native toolkit than in HTML/CSS.
I refereed to my components argument not to "suck less".
>>tags are tags like any other HTML tag. >And what do you think lives inside the tags, pray tell?
You don't have to think about it (you just import the component) as you don't have to think what's current CPU pin state. You just use attributes to communicate with the component.
>"That's the point, the complexity is still there, just hidden."
And there is a value in this. Higher level langs hide complexity as well (eg. C# vs C) and that makes them usable.
>It's also wrong, web components make it somewhat easier to reason about the existing mess, they don't actually fix issues
I don't agree. In my entire web dev career single biggest pain in the ass was more or less like "what CSS rule is breaking my div style".
Since ShadowDOM brings CSS fence between components as you probably know (do you?), ShadowDOM makes it way easier to create HTML/CSS ui simply because it's hard to make CSS rules breaking whole app view.
I do agree layouting is an issue - it's just not that important at least for me - joe average web dev
[edit added what gives us Shadow DOM CSS boundry]
[edit2 - hell yea! no arguments? just downvote!]
> It's conventional wisdom that it's easier and faster to create app in native toolkit than in HTML/CSS.
Because native toolkit provide tools which let you actually lay out your screens.
> I refereed to my components argument
I found no such thing, hence my response.
> And there is a value in this.
I didn't claim there was no value to it.
> In my entire web dev career single biggest pain in the ass was more or less like "what CSS rule is breaking my div style".
Well we apparently have very different experiences of web development.
> Since ShadowDOM brings CSS fence between components as you probably know (do you?), ShadowDOM makes it way easier to create HTML/CSS ui simply because it's hard to make CSS rules breaking whole app view.
Again, I didn't claim there was no value to shadow dom, you're strawmanning here.
> it's just not that important at least for me
I'd kinda understood that at this point.
> joe average web dev
Yeah… no.
Because native toolkit provide tools which let you actually lay out your screens.
> I refereed to my components argument
I found no such thing, hence my response.
> And there is a value in this.
I didn't claim there was no value to it.
> In my entire web dev career single biggest pain in the ass was more or less like "what CSS rule is breaking my div style".
Well we apparently have very different experiences of web development.
> Since ShadowDOM brings CSS fence between components as you probably know (do you?), ShadowDOM makes it way easier to create HTML/CSS ui simply because it's hard to make CSS rules breaking whole app view.
Again, I didn't claim there was no value to shadow dom, you're strawmanning here.
> it's just not that important at least for me
I'd kinda understood that at this point.
> joe average web dev
Yeah… no.
You must have never done any kind of development outside the web if you think for one second that native toolkit development is faster/easier than HTML/CSS.
You have absolutely no idea what you are talking about. Please stop talking.
You have absolutely no idea what you are talking about. Please stop talking.
>You must have never done any kind of development outside the web
Well actually I started as a Windows.Forms Silverlight/WPF .NET dev
>if you think for one second that native toolkit development is faster/easier than HTML/CSS.
With MS tooling and/or paid e.g Devexpress controls average .NET dev is way faster building LOB apps than average web dev and you don't have to test on multiple browsers.
Additionally if you have to support older browsers you will get extra penalty
Do I have to add how much JS sucks compared to C# ?
There is a trade-off - you can't skin your app as much as you can with CSS.
>You have absolutely no idea what you are talking about. Please stop talking.
Native toolkits are usually easier to dev once you know them.
It's a conventional wisdom - at least one other person in this thread seems to agree with me on this.
Well actually I started as a Windows.Forms Silverlight/WPF .NET dev
>if you think for one second that native toolkit development is faster/easier than HTML/CSS.
With MS tooling and/or paid e.g Devexpress controls average .NET dev is way faster building LOB apps than average web dev and you don't have to test on multiple browsers.
Additionally if you have to support older browsers you will get extra penalty
Do I have to add how much JS sucks compared to C# ?
There is a trade-off - you can't skin your app as much as you can with CSS.
>You have absolutely no idea what you are talking about. Please stop talking.
Native toolkits are usually easier to dev once you know them.
It's a conventional wisdom - at least one other person in this thread seems to agree with me on this.
Shadow DOM is no solution to the issue pointed out by OP, which is CSS-based layouting. Flexbox[0] or grid[1]? Sure, they exist specifically to (finally) add actual layouting abilities to CSS.
> Thinking in terms of components is much easier than trying to manage div soup.
It still does not solve the issue at hand.
[0] http://caniuse.com/flexbox
[1] http://caniuse.com/css-grid
> Thinking in terms of components is much easier than trying to manage div soup.
It still does not solve the issue at hand.
[0] http://caniuse.com/flexbox
[1] http://caniuse.com/css-grid
yea - sure you are right. I just say - there are bigger issues with HTML/CSS than that.
> I just say - there are bigger issues with HTML/CSS than that.
Yeah… no, not really. That there still is no way to correctly and reliably layout on the web is a much bigger issue than modularity.
Yeah… no, not really. That there still is no way to correctly and reliably layout on the web is a much bigger issue than modularity.
Do you actually do web dev ?
How many times you struggled with mingled CSS ?
Since there is no ShadowDOM CSS boundry - it's hard to make sure some top level CSS rule is not breaking your very special div style.
Now compare this number with number of times you struggled with layouting your page ? I bet first one is far more common and costly task.
Now compare this number with number of times you struggled with layouting your page ? I bet first one is far more common and costly task.
> Do you actually do web dev ?
Yes.
> How many times you struggled with mingled CSS ?
Not enough times that I'd get blood pressure issues over it.
> I bet first one is far more common and costly task.
You lost your bet. Which was idiotic, I wouldn't argue web layouting to be a bigger issue if I didn't find it to be.
Yes.
> How many times you struggled with mingled CSS ?
Not enough times that I'd get blood pressure issues over it.
> I bet first one is far more common and costly task.
You lost your bet. Which was idiotic, I wouldn't argue web layouting to be a bigger issue if I didn't find it to be.
It's hard to believe. Do you use CSS frameworks like TB derivatives ?
It seems your comment regarding ShadowDOM not helping layouting issues is not entirely true.
Take a look on:
polymer-grid-layout polymer-flex-layout polymer-layout
http://www.polymer-project.org/docs/elements/polymer-element...
It seems your comment regarding ShadowDOM not helping layouting issues is not entirely true.
Take a look on:
polymer-grid-layout polymer-flex-layout polymer-layout
http://www.polymer-project.org/docs/elements/polymer-element...
It seems to need some browser compatibility work:
https://www.dropbox.com/s/5ipil0xd12z7a54/Screenshot%202014-...
https://www.dropbox.com/s/5ipil0xd12z7a54/Screenshot%202014-...
[deleted]
Of note, this project goes a fair bit deeper into advanced layout possibilities than the flexbox and grid modules included in the current CSS spec/drafts. Flexbox, for instance, prescribes a very particular pattern to the layouts that it affords. You must be rather methodical in how you break your layout into nested rows and columns. This focus on rows and columns causes quite a bit of visual shoehorning, or forces you to resort to hacks, at which point you've lost most of the benefit of using flexbox at all. Though for simple- to medium-complexity layouts where the visual arrangement is composed of nested rectangles following simple rules (as most of the web seems to be), flexbox is wonderful once you get the hang of it.
I'm very fond of constraint-based layout systems (and rule systems in general), having written a few of them myself. I feel that while this GSS project isn't a complete realization of the promise they offer, it is a nice step in that direction. I worry about the performance and complexity burdens this project seems to impose, though I say that only looking at the docs, the generated code, and the discussions that emerged the last time this was posted to HN. I will be using it for an in-house dev-facing tool in the near future, and about that I am quite excited.
[1]: https://vimeo.com/91393694