Live data from Hacker News

Incomplete List of Mistakes in the Design of CSS

wiki.csswg.org

71–80 of 111 posts

Re: Incomplete List of Mistakes in the Design of CSS

#71

Earlier quoted context omitted.

Hmm... I don't see any conceptual reason why separating those things should require completely different languages, though.

Nobody bats an eye when you use Python for logic, sql for querying your database and regex for searching text. Unlike the front end, there are ample opportunities for "uniting" the backend in one language, yet nobody really seems to bother. I speculate that it's because these languages are better at certain things, just like having a non-executable language for data, helps keep the data, data only (cue angry lispers)…

> Nobody really seems to bother

I prefer writing queries using Django's ORM even though it is underpowered.

Re: Incomplete List of Mistakes in the Design of CSS

#72
If I had to pick a favorite it would be:

> descendant combinator should have been » and indirect sibling combinator should have been ++, so there's some logical relationships among the selectors' ascii art

Now, where do we stand on the omition of a parent selector?

I've seen it mentioned over the years that CSS lacks an all important parent selector, eg:

    ul 
where the html would appear thus:

    ...  

This goes against the entire idea of a cascade. But with frameworks and templates all over the web it isn't always possible to define the parent tag yourself, or assign it an ID/class.

For example, I use a framework that generates html from xml documents, I can't add a class or ID to the parent html tag, a parent element selector would be of value here. My concern would be that it is open to abuse.

Re: Incomplete List of Mistakes in the Design of CSS

#73

Earlier quoted context omitted.

Nobody bats an eye when you use Python for logic, sql for querying your database and regex for searching text. Unlike the front end, there are ample opportunities for "uniting" the backend in one language, yet nobody really seems to bother. I speculate that it's because these languages are better at certain things, just like having a non-executable language for data, helps keep the data, data only (cue angry lispers)…

> Nobody really seems to bother I prefer writing queries using Django's ORM even though it is underpowered.

Yeah, I guess I as a little hyperbolic :)

Re: Incomplete List of Mistakes in the Design of CSS

#74
post #44

When do we get to throw the whole thing out and start again?

When we implement Display PostScript in js, so we can use it for the web? HTML+CSS for publishing static, stand-alone documents isn't all that bad. It's terrible for making "applications", and it's terrible for composing more than one thing into a page (such as a header, footer, table of contents/menu). I still think Adobe's idea[1] of flowing content through boxes (aka the "desktop publishing way") makes more sense…

RinohType [1] combines a CSS-inspired style sheet system [2] with a powerful layout system based on boxes ("containers"). It currently only outputs to PDF but an SVG backend could be added without too much work...

[1] http://www.opqode.com [2] http://www.mos6581.org/rinohtype_status_update_1

(I'm RinohType's author)

Re: Incomplete List of Mistakes in the Design of CSS

#75
This is a totally crazy out-there idea, so be kind:

Rather than trying to create a layout system that can adapt to any window or screen size, as with CSS/HTML, Java, iOS, etc., what if instead we had settled on a small number of permitted aspect ratios for screens? I'm carrying the analogy from paper sizes: A4, A5, A1, etc.

So probably we would have gotten this wrong when we first defined them (see iPhone aspect changes), but presumably after a while they settle down and then we can stop testing for the old aspect ratios.

Monitors, laptops, tablets, phones, would all standardise to a set of options just like most books and magazines standardise to a given size.

I know there are downsides, but imagine how much easier this would be for designers. Cross-platform UI design would be much simpler.

Just a radical thought I had.

Re: Incomplete List of Mistakes in the Design of CSS

#76

This is a totally crazy out-there idea, so be kind: Rather than trying to create a layout system that can adapt to any window or screen size, as with CSS/HTML, Java, iOS, etc., what if instead we had settled on a small number of permitted aspect ratios for screens? I'm carrying the analogy from paper sizes: A4, A5, A1, etc. So probably we would have gotten this wrong when we first defined them (see iPhone aspect chan…

Aspect ratio isn't every thing in design. The size of the window is just as important. A 3x2 21" screen needs very different UI approach than a 3x2 3" screen. And standardizing screen sizes is not really a sensible option.

Re: Incomplete List of Mistakes in the Design of CSS

#77
post #21

This doesn't even address the fundemantal design flaw with CSS: (paraphrased badly from a quote by Casey Muratori) Layout is about the relationship between TWO THINGS. If you have a layout language that deals with only one thing at a time, then you have failed.

Can you elaborate? Why only two things?

Re: Incomplete List of Mistakes in the Design of CSS

#78
post #76

This is a totally crazy out-there idea, so be kind: Rather than trying to create a layout system that can adapt to any window or screen size, as with CSS/HTML, Java, iOS, etc., what if instead we had settled on a small number of permitted aspect ratios for screens? I'm carrying the analogy from paper sizes: A4, A5, A1, etc. So probably we would have gotten this wrong when we first defined them (see iPhone aspect chan…

Aspect ratio isn't every thing in design. The size of the window is just as important. A 3x2 21" screen needs very different UI approach than a 3x2 3" screen. And standardizing screen sizes is not really a sensible option.

> Aspect ratio isn't every thing in design. The size of the window is just as important. A 3x2 21" screen needs very different UI approach than a 3x2 3" screen.

Good point.

I was thinking more along the lines of the fact that design tools and tech that enable adapting to an arbitrary screen size are unlikely to be as easy to use and expressive as those targeted for a specific aspect ratio (for example, you could use absolute positioning).

> And standardizing screen sizes is not really a sensible option.

Suspend disbelief for a moment, or consider only from the POV a single large corporation / group (e.g. Apple or Android).

Re: Incomplete List of Mistakes in the Design of CSS

#79

> Box-sizing should be border-box by default. Didn't older versions of IE do precisely that, leading to endless frustration? I hate to say it but MS did something right for once.

What frustration? The IE box model is the superior model. It's the way graphic designers naturally think about layout: You make a box then fill inward. Easy grid based layout. It's insane to figure out the size of your inner content and grow out—always subtracting from your desired total width.

The frustration due to IE having one model and the spec and every other browser having a different model. Everyone who worked with CSS in the dark ages of IE6 felt that frustration.

Re: Incomplete List of Mistakes in the Design of CSS

#80
post #76

Earlier quoted context omitted.

Aspect ratio isn't every thing in design. The size of the window is just as important. A 3x2 21" screen needs very different UI approach than a 3x2 3" screen. And standardizing screen sizes is not really a sensible option.

> Aspect ratio isn't every thing in design. The size of the window is just as important. A 3x2 21" screen needs very different UI approach than a 3x2 3" screen. Good point. I was thinking more along the lines of the fact that design tools and tech that enable adapting to an arbitrary screen size are unlikely to be as easy to use and expressive as those targeted for a specific aspect ratio (for example, you could use…

It's really about the burden of the effort, it can either be easy for the users and a pain for the developers or it can be the other way around. We can standardize the ratios and sizes and that would make things easy for devs sure but then that would decrease the variety and innovation for the user. If there really were a handful of fixed sizes and ratios then that would make things like google glass, smart watches, galaxy edge or any other kind of unconventional device with non standard display that much more difficult to ship to the masses.

We don't know what kind of display size and aspect ratio the next contact lens display or the next building sized display will have. So I believe it's better to keep our self open to new possibilities.

Post reply on HN