111–120 of 132 posts
Earlier quoted context omitted.
These namespaces do not merge cleanly, for example `content`.
Oh for sure, its way way too late to do it, but I don't think much of any of the modern web stack would be kept if we designed in the 90s with what we know now.
> That should be corrected if anyone invents a time machine. :P Why can't this be dealt with with CSS versioning/features where you can opt into your current-color and a lot of more substantive style behavior while leaving currentColor functional?
A lot of the behaviors should just have a toggle to turn them off. For example, there are many situations where margin collapsing is in the way and I keep wondering why there isn't simply a `margin-collapse: none`. It would also be nice to have something like `default-styles: none` that will remove all the default styling for h1/h2/etc. and em/strong/cite/etc. so I don't have to deal with browsers having differing de…
This already exists:
*, ::before, ::after { all: unset }Earlier quoted context omitted.
at least they were specific Today it's usually implicitly designed for iphone, designed for 1080p, or ipad, and you have to guess, strong correlation with whatever device the designer uses in his personal life.
...no? Today's sites use responsive design and adapt to pretty much any screen size.
Today sites certainly can and some (many) so. But some (also many) definitely don't…
A lot are locked to a maximum width, which is OK enough as l……o……n……g lines of text are unpleasant to read, but only because browsers hack the meaning of dimension settings to make text zoom work consistently.
A lot also have an effective minimum width (even if they use responsive styling to move/ minimise/hide side decoration before a certain point) that is not always convenient. Try browsing with a thin window so you can have something in the other side of your screen. Some assume no one on desktop will ever have a browser window less wide than 1280 pixels (or equivalent on a zoomed higher res screen) - not the case on my 1080p portrait screen and I sometimes want things thinner than 1280 on my 2560x1440 screen. You could say I'm just odd and they can't cater for everyone, but 1080 or a bit less wide is hardly miles away from many devices physical layout so if a design can't display nice in that can it really call itself "responsive" (I suspect any such design would fail on many mobile devices too - 1080px effective width is rather common there, as are smaller widths).
Earlier quoted context omitted.
Imagine you have something like `width / comment /: / comment2 /12px / comment3 /,`. Now you want to load your css into some kind of structured representation, rearrange it, then spit it back out again with that comment intact. The requirement to represent such comments in your structured format so you can retain them is really obnoxious. In html you can just view comments as another node in a uniform tree.
> In html you can just view comments as another node in a uniform tree. When you parse an AST with comments (or a CST), they do become "just another node in a uniform tree". Think about it - in HTML you have a tree of nodes but comments can be anywhere , which is exactly as obnoxious to deal with as a CST where comment nodes can be anywhere. This is a terrible reason to not support comments. If it was really importan…
Maybe I'm misunderstanding, but no they can't. For example the comment here is not a comment, but part of the URL:
">click me
>content
Earlier quoted context omitted.
I’ve gotten in several arguments over the years where webdevs insisted on showing tabular data using flexbox or hardcoded div widths or worse. They insisted that html tables were never ever to be used and couldn’t be persuaded.
If you try to render tables with millions of cells the browser does a really poor job and the performance is abysmal. The only solution when you need to render that many cells is to virtualize the table and only have the visible cells (plus some buffer) actually in the DOM at a time. That plus weird restrictions browsers put on certain table elements (looking at you thead) that prevent them from being "sticky" header…
I'd argue that if you have so many rows that DOM can't handle, humans won't either. Then you need search, filtering, data exports, not JS attaching a faked scrollbar to millions of rows.
Earlier quoted context omitted.
> Related: I also love when I can't paste tabular data into Excel/etc. anymore Except that’s exactly where tables should be used. So if you can’t, someone has really misunderstood CSS. Use it for tables, not for layout.
I’ve gotten in several arguments over the years where webdevs insisted on showing tabular data using flexbox or hardcoded div widths or worse. They insisted that html tables were never ever to be used and couldn’t be persuaded.
When I occasionally venture I to standards-land, I always ask "what user research have you done on this?" So many weird design choices in computing are because one person said "this seems right to me" without considering other viewpoints or consulting with the wider community. Sure, you probably dont want death by committee, but a tiny cabal engaging in groupthink often produces unhelpful results.
There was some (academic) reaserch behind early CSS concept, but the original vision for it didn't pan out ("cascading" was meant to blend style preferences of users, browsers and page authors, but all we got is selector specificity footguns).
Netscape was planning to release their own imperative styling language, and ended up shipping a buggy CSS hackjob instead.
Once IE was dominant, Microsoft didn't think they have to listen to anybody, so for a while W3C was writing CSS specs that nobody implemented. It's hard to do user research when nothing works and 90% of CSS devs' work is fighting browser bugs.
Earlier quoted context omitted.
> In html you can just view comments as another node in a uniform tree. When you parse an AST with comments (or a CST), they do become "just another node in a uniform tree". Think about it - in HTML you have a tree of nodes but comments can be anywhere , which is exactly as obnoxious to deal with as a CST where comment nodes can be anywhere. This is a terrible reason to not support comments. If it was really importan…
> in HTML you have a tree of nodes but comments can be anywhere Maybe I'm misunderstanding, but no they can't. For example the comment here is not a comment, but part of the URL: ">click me And HTML like this is simply broken: >content Maybe you meant "they can be anywhere that a Node can be in the DOM ", but I think that's more or less what the CSS "mistake" is suggesting should be true about CSS (just replace "DOM"…
h1,
/* don't forget h2! */
h2 {
color: /* I love red */ "red";
}
h1
h2
red
Earlier quoted context omitted.
> in HTML you have a tree of nodes but comments can be anywhere Maybe I'm misunderstanding, but no they can't. For example the comment here is not a comment, but part of the URL: ">click me And HTML like this is simply broken: >content Maybe you meant "they can be anywhere that a Node can be in the DOM ", but I think that's more or less what the CSS "mistake" is suggesting should be true about CSS (just replace "DOM"…
Yes, anywhere in the node tree. Imagine if CSS was specified in HTML-style. We might write this selector: h1, /* don't forget h2! */ h2 { color: /* I love red */ "red"; } Like this: h1 h2 red Which is pretty much exactly the same as what you'd get as a CST from parsing the CSS.
I will never understand the bizarre scene of the web's smug collective declaration that tables were dead and not to be used juxtaposed against the years it took to regain the ability to reliably center things. Assuming one agrees that we even did regain it. Related: I also love when I can't paste tabular data into Excel/etc. anymore For the record, I don't hate the idea of stylesheets, but...sheesh
> I will never understand I think it's fairly easy to understand if you understand what it was a backlash against. Tables today are used sensibly, for the most part, but the pre-CSS world was truly absurd in its table use. The reaction may well have been over-the-top, but it wasn't disproportionate given the state of table usage at the time. CSS's initial forays into layout seem bad today because people think of tabl…