Earlier quoted context omitted.
These things, while beneficial, don't owe their existence to CSS. Instead, introducing eg. CSS shapes or `content: ` (as two extreme examples) was the way of least resistance/guerilla tactics, as opposed to putting the functionality into SVG proper, or aligning the layout box model better with the DOM model, resp. Now what we're left with is a way overcomplicated mess for generations to clean up. There's a reason Moz…
I agree. Most of the HTML I write is to create structure for CSS to use. For example, a `div` is a container, but we put it on the content side. What would have been better would be a flat map identifier -> binary (or string or whatever, your choice) as the content, and then "CSS" (quotes because it wouldn't be the CSS we know now) would declare the layout/look and would read the content map for insertion into placeh…
CSS Grid – Table layout is back. Be there and be square
211–220 of 280 posts
Re: CSS Grid – Table layout is back. Be there and be square
#212Makes you wonder why HN won't budge with those tags in the source code. One day I hope to see "Table layouts are back with tags" and the HN programmers would have saved themselves so much work.
Re: CSS Grid – Table layout is back. Be there and be square
#213I don't know how to say it politely but what has been achieved by using ad-hoc syntax such as this gem (and similar complex CSS syntax): display: grid; grid-template-rows: 150px [nav-start] auto 100px [nav-end]; grid-template-columns: [header-start] minmax(200px, 3fr) 9fr [header-end]; CSS fans for some reason seem to think that its somehow better to have rendering/presentational properties in an ad-hoc language. Ori…
CSS would have been so simple if it had just adopted a plain LISP syntax. It is so difficult to memorise all the special and inconsistent syntax for every new thingamajig that browser vendors choose to introduce. Need to painfully look up a CSS reference if you haven't used that special rule in more than a week as it just doesn't seem to get retained (at-least for me) into long term memory.
Lisp for just CSS with all else same: lukewarm idea.
Re: CSS Grid – Table layout is back. Be there and be square
#214Earlier quoted context omitted.
CSS would have been so simple if it had just adopted a plain LISP syntax. It is so difficult to memorise all the special and inconsistent syntax for every new thingamajig that browser vendors choose to introduce. Need to painfully look up a CSS reference if you haven't used that special rule in more than a week as it just doesn't seem to get retained (at-least for me) into long term memory.
The syntax is pretty simple. The problem is all the available attributes and values. I don't see how lisp syntax would help.
Re: CSS Grid – Table layout is back. Be there and be square
#215Earlier quoted context omitted.
Oh I do, I do... and I agree that many of the things CSS does for you today are vastly better than the ad-hoc solutions we had in the past (if you ever have to create an HTML email - and thankfully I am able to outsource all of that sort of work to someone who actually takes a perverse pleasure in it - that's always a nice reminder of how silly HTML and CSS were in the late '90s before CSS was actually broadly usable…
> But still... some of the syntax we have now, not to mention the sheer breadth of verbiage, is insane I had somehow missed that your gripe is with the syntax - I fully agree with you on that! CSS definitely feels kludgey, especially for larger/complex apps or sites. I now think of real CSS as a target that my build system generates as I mostly write in Sass or LESS. I find those superior to vanilla CSS in maintainab…
Re: CSS Grid – Table layout is back. Be there and be square
#216I don't know how to say it politely but what has been achieved by using ad-hoc syntax such as this gem (and similar complex CSS syntax): display: grid; grid-template-rows: 150px [nav-start] auto 100px [nav-end]; grid-template-columns: [header-start] minmax(200px, 3fr) 9fr [header-end]; CSS fans for some reason seem to think that its somehow better to have rendering/presentational properties in an ad-hoc language. Ori…
I've used a lot of different layout frameworks over the years. Constraint systems are neat but hard to scale. All-code layout definitions are hard to read and reason about. Markup-level layout systems have their issues, but are easier for new programmers to learn and are the most instantly powerful out of the box. Most dewey-eyed replacements for production layout systems that I've encountered quickly founder when they try to cover all the corner cases that a mature framework would need to support. It's shockingly common to just end up with a kind of crappy version of bespoke CSS. Maybe with better syntax. Definitely with fewer features.
Alternately, if you're really complaining about the fact that you define styles in one file and markup in the other...I dunno, seems fine to me. I've seen systems that try to do all of that in one file (you can do it in HTML if you want to). They're not very readable. Splitting the styling from the basic structure is not a "clean" split, but it does simplify things enough to make your files much easier to scan. Sure, it doesn't live up to the old, pure idea about separating content from styling, but...who cares?
Re: CSS Grid – Table layout is back. Be there and be square
#217Earlier quoted context omitted.
> There's a reason Mozilla spent the better part of the decade to come up with a new web renderer. That had nothing to do with the fact that HTML and CSS are independent. Tables are way way more complicated than anything in CSS. In fact, tables are unspecified. This [1] is a work in progress draft and incomplete. You'll be forgiven if your eyes glaze over while reading it. [1]: https://dbaron.org/css/intrinsic/
This is not a tables-vs-CSS thing. Hey, I'm looking forward to servo and applaud Mozilla devs for it; but the reason they found it worthwile to invent an entire new programming language for implementing it certainly is telling about CSS's insane complexity.
CSS has its problems (I'm the first to admit that), but on balance I think it's the best layout language that has been devised for documents.
Re: CSS Grid – Table layout is back. Be there and be square
#218Earlier quoted context omitted.
Not the one you asked, and purely for historic reasons, but DSSSL, the precursor of XSLT and CSS, was Scheme: ; rule associated to document's element class (element (section header) (make paragraph font-family-name: "Helvetica" font-weight: 'bold font-posture: 'oblique (process-children) ) ) ; rule associated to a particular element uniquely identified with an id: (id ("ref34") (make paragraph font-family-name: "Helv…
And how is that making it better than CSS? It looks more complicated and still has to use all the same attributes.
Re: CSS Grid – Table layout is back. Be there and be square
#219Earlier quoted context omitted.
Could you give an example of how such a Lisp-like syntax would look, to show the improvement?
Not the one you asked, and purely for historic reasons, but DSSSL, the precursor of XSLT and CSS, was Scheme: ; rule associated to document's element class (element (section header) (make paragraph font-family-name: "Helvetica" font-weight: 'bold font-posture: 'oblique (process-children) ) ) ; rule associated to a particular element uniquely identified with an id: (id ("ref34") (make paragraph font-family-name: "Helv…
Re: CSS Grid – Table layout is back. Be there and be square
#220I don't know how to say it politely but what has been achieved by using ad-hoc syntax such as this gem (and similar complex CSS syntax): display: grid; grid-template-rows: 150px [nav-start] auto 100px [nav-end]; grid-template-columns: [header-start] minmax(200px, 3fr) 9fr [header-end]; CSS fans for some reason seem to think that its somehow better to have rendering/presentational properties in an ad-hoc language. Ori…
You say "css fans" like we have a choice in the matter :) I am a fan of building websites, and css is the only way to achieve that. Yeah it sucks, but it's all we got. Grid spec solves a LOT of problems so even if the syntax is ugly, it's existence in the world is beautiful.