On Wednesday, 23 April 2014 at 23:17:02 UTC, Adam D. Ruppe wrote:
> On Wednesday, 23 April 2014 at 21:55:48 UTC, John Colvin wrote:
>> If it could be put on code.dlang.org that would be awesome.
>
> http://code.dlang.org/packages/cssexpand

Nice, thanks a lot. How much effort would it be to turn this into
a full SCSS compiler?
There is also a C project to draw from.
https://github.com/hcatlin/libsass

I think it would make a great addition to our D web stack.

On 23/04/2014 5:28 PM, Dicebot wrote:
> Gosh now I finally know what researches to blame for my eyes bleeding
> upon most web site restylings (Facebook *caugh-caugh*).


Are you sure that your eyes aren't bleeding because your fonts are too small?

A...

(Argh! Accidentally emailed this to digitalmars-d@puremagic.com twice! Actually posting to NG now...)

On 4/23/2014 6:48 PM, H. S. Teoh via Digitalmars-d wrote:
>
> until sometime in the last few
> years I got so sick of JS eating up CPU, memory, causing needless
> browser slowdowns, popping up unwanted ads and nag dialogs, that now I'm
> back to JS being off by default, and only (grudgingly) enabled for a
> handful of specific sites that actually *need* it. It's amazing how much
> faster the web suddenly became, overnight.

That's why I do it! That plus the lack of modal CSS pop-in windows. (Seriously, no sooner do the browsers finally kill off popups, but then overzealous designers go replacing them with *modal* versions! And these new ones break basic browser functionality even *more*.)

The *truly* amazing thing is that many of those slow-with-JS sites are using JS/AJAX specifically *because* they actually believe it makes their site faster (I bet many of them are probably running on Node.js or PHP, too). Always, of course, based on the same half-baked, never-tested, but oft-repeated theory that reducing a few fractions of a kilobyte by doing partial page-reloads actually makes the web noticeably faster (yea right).

Shit, even in the days before 14.4 modems, let alone 56k or broadband, transferring the actual HTML was practically nothing, it was the occasional use of an image or two that slowed things down - *because those take a heck of a lot more bytes than HTML*. Even today, one gravitar image, one "share on site x" logo, or one stock photo of a model pretending to be an overjoyed IT worker, and *all* the partial-HTML savings are completely blown several times over. Not to mention all the extra CSS/HTML/JS used for rigging up a partial-reloading Web 2.0 "experience" in the first place.

And then there's sites that perform these performance "enhancing" AJAX requests *on initial page load*, which is just the definition of irony.


> And it's equally amazing how
> many links stop working without JS. It boggles the mind... doesn't HTML
> have a built-in link tag for that very purpose?!
>

Exactly. Speaking of which...

[Link Warning: Language and tone are probably NSFW, NSF-GitHub-Workers, and NSF-Humanity ;) ]

http://semitwist.com/articles/article/view/making-a-link-or-what-the-fuck-is-wrong-with-github-s-developers

> Another new fad nowadays seems to be CSS popups that need JS to make
> them go away. My usual reaction to that is to close the tab and move on.
> Or, if I'm feeling particularly tolerant that day, switch to user
> stylesheet mode (i.e., completely disregard the site's CSS and use my
> own), and just scour the raw text for the real content

I love this FF extension:

https://adblockplus.org/en/elemhidehelper

If I can't get rid of the garbage with that, the site's not worth spending another second on. I won't be bothered to even *think* about some poorly-made site's CSS, let alone touch any custom stylesheets.


> (which usually
> occupies, oh, 20% of the total text on the page -- apparently nowadays
> minimizing your S/N ratio is in, providing useful content is out).

Yup. Makes me miss "markup".

But then I go back to my own site, type <b></b> instead of <span class="something-that-implicitly-says-font-weight-bold-in-the-css"></span>, and all is well. Bonus points for me whenever <b> offends anyone's sense of "proper" HTML. :)

As if <b> hasn't always implied the semantics of "emphasis" anyway...not that anyone's ever had any real use for semantic "which text is emphasized?" for any purpose besides "Should this text be rendered in bold/italic or not?"

Funny though...I've never heard any of the semantic-web-loving, <b>/etc haters complain about things like Markdown ;)


> esp. since Google will readily give me pages upon pages of
> other places where I can get similar information! >:-)
>

Yea that's a big thing, too. So many designers actually believing their site is so special that people won't just move on or that being hitech-elitist won't hurt their site.


> JS rants are fun. ;-)
>

Heh, yea, it's an addiction :)

On Thursday, 24 April 2014 at 08:06:18 UTC, Alix Pexton wrote:
> On 23/04/2014 5:28 PM, Dicebot wrote:
>> Gosh now I finally know what researches to blame for my eyes bleeding
>> upon most web site restylings (Facebook *caugh-caugh*).
>
>
> Are you sure that your eyes aren't bleeding because your fonts are too small?
>
> A...

Considering the very same size 9 fonts are used as default everywhere else in my desktop system and it feels just fine.. yeah, you must be right. It must be small font and not weirdly scaled UI with 2/3 of screen space blank. Sure.

On 4/23/2014 6:19 PM, H. S. Teoh via Digitalmars-d wrote:
> On Wed, Apr 23, 2014 at 05:32:00PM -0400, Nick Sabalausky via Digitalmars-d wrote:
>> I certainly won't disagree that small fonts can be hard to read, but
>> on the other end, I've seen a lot of newer websites with gigantic
>> fonts, and I find that painful to read as well.
>
> Any examples?
>

Ugh, actually I wish I had some. I tend to run away from those sites too quickly to either remember them or bookmark for later ridicule. I should start bookmarking them though, for fun :)

Another thing I've seen that makes things literally painful to read is double-spacing. Double-spacing is needed in school so the instructor can mark comments (Assuming schools even do essays in hardcopy anymore?). Outside of school it just makes things hard to read.

Though I can't confirm, I always assumed such sites were probably trying too hard to be typographically proper. Either that or they assumed everyone was running on a 5 bazillion DPI monitor or some such.


> Usually when I run into a site with (1) microscopic fonts, (2) giant
> (often multicolored) fonts, (3) no whitespace, or (4) has more
> ads/filler than content, my fingers have an almost instinctual ctrl-W
> (close tab) response. Sometimes not even one word registers in my brain
> before I move on to the next site.
>

Incidentally, ugly rainbow text is also why I set my mail client to plaintext-only ages ago.


> In fact, I'm of the arrogant opinion that websites should not specify
> ANY font size except a relative size to the browser's default, because
> chances are, whatever size you choose will look horrible on *somebody*'s
> device. Browsers come with a default (and user-configurable!) font size
> for a reason. Web designers would be foolish to disregard that.
>

I agree. Unfortunately though, browsers haven't always has reasonable defaults, so people had to work around, so now it's all pretty much screwed.

Maybe what we need is a CSS for "sane-size-defaults: on;" which would provide a "reboot" of the whole default font sizes. That way, any pages that still assume the old broken defaults system and actively work around it won't break, but newer sites could finally start relying on sane user/browser/device-specific defaults.


>> Grey-on-white is ridiculously common and should be jailable offense.
>> I'll never understand the the reasoning behind that readability
>> destroyer.
>
> Worse yet, I've actually seen sites that use red on gray (or the other
> way round -- it's too painful to recall). Or lime on turqoise. Or any of
> various other horrible combinations. Aughh... my eyes hurt just thinking
> about it... On the bright side, most sites that pick such colors usually
> don't have any useful content to offer either, so the ctrl-W kneejerk
> (fingerjerk?) fixes the problem quite quickly.
>

From what I've seen, most of those really weird-colored ones were cases where I wouldn't necessarily expect the author to be good with styling. But grey-on-white gets used even by sites that *should* know better. GitHub was pretty bad with that a couple years ago.

Of course, I am aware that #000000/#FFFFFF can be a bit too much contrast, so you often want something that's just a really dark grey. But still, a lot of sites take the softened-contrast thing too far.

On Thursday, 24 April 2014 at 08:58:13 UTC, Nick Sabalausky wrote:
> I agree. Unfortunately though, browsers haven't always has reasonable defaults, so people had to work around, so now it's all pretty much screwed.
>
> Maybe what we need is a CSS for "sane-size-defaults: on;" which would provide a "reboot" of the whole default font sizes.

The defaults in the original browsers were set a bit large (16px), so Safari decided to set them smaller for a while. That sucked. Nowadays you can just set the scaling of the body to 87.5% of the default and get a reasonable size (14px).

What annoy me the most is non-promotional sites that set the body font-family to anything but the default sans-serif (which often happens to be pixel perfect, have good unicode support and is legible).

Another thing that kills me about the new "big picture up top,
scroll to gigantic say-nothing text below" fad....

The text below sounds like there might be some more learning to
do. So I try to click on the headers.... nothing happens. No see
more link.

Apparently "Feature rich: we have more features than anybody!" is
all they have to say. No explanation of what those features are.

<a href="this-makes-me-angry-because-it-sux">Hatred.</a>

On Thursday, 24 April 2014 at 08:17:15 UTC, Nick Sabalausky wrote:
> As if <b> hasn't always implied the semantics of "emphasis" anyway...not that anyone's ever had any real use for semantic "which text is emphasized?" for any purpose besides "Should this text be rendered in bold/italic or not?"
>
> Funny though...I've never heard any of the semantic-web-loving, <b>/etc haters complain about things like Markdown ;)

I use semantic markup for emphasis where it's supported. Can't say I used markdown a lot, though I guess its semantics is more similar to that of semantic markup than visual markup, I can say wiki markup is.

On Thursday, 24 April 2014 at 08:58:13 UTC, Nick Sabalausky wrote:
> I agree. Unfortunately though, browsers haven't always has reasonable defaults, so people had to work around, so now it's all pretty much screwed.
>
> Maybe what we need is a CSS for "sane-size-defaults: on;" which would provide a "reboot" of the whole default font sizes. That way, any pages that still assume the old broken defaults system and actively work around it won't break, but newer sites could finally start relying on sane user/browser/device-specific defaults.

I'm thinking more about some standardization of web skins, then people will choose their web skin of choice just like on desktop system, and sites will use that chosen skin to present content and layout.

On Thursday, 24 April 2014 at 07:59:20 UTC, Martin Nowak wrote:
> Nice, thanks a lot. How much effort would it be to turn this into a full SCSS compiler?

Hmm, looking at the sass webpage, I think I could do some of the features but prolly not all and with a different syntax. So it wouldn't work for a full scss compiler.

If you want that, just use that C library or the ruby original.


My thingy is really just a generic text macro system with an extension that kinda understands css syntax and simply aims to be good enough for me. I can add to it but since it is good enough for me already, I don't have a pressing desire to go all the way. (As you might have heard on irc, I started a new job a couple weeks ago tho.... and it is a Ruby on Rails thing, so who knows, maybe I'll use the sass in that and find something I like enough to spend the time cloning it, but so far I use sass as just a substitute for my own cssexpand.)


Below is my impression of the sass docs.

Looks like the two big things they offer that I don't are inheritance and math.

Inheritance might be easy, I parse it out anyway so a referencing thingy could do that, sass calls that @extend. Math is something I avoided because it isn't terribly useful IMO and getting the units right isn't easy. What's 1em / 16px? Depends on the font size... which depends on the whole dynamic cascade.

Perhaps a unit mismatch could just issue an error though, sidestepping all that. So a little dimensional analysis!

We have some different syntax details though, like their variable assignment vs my set macro and the parent selector referencing in nested things is different.

Actually, the sass way of & might be a bit better than mine. For example, in mine:

a {
  :hover { color: red; }
}

expands into:

a {}
a:hover { color: red; }

If you wanted to reference a child with a pseudoclass, you'd have to do:

a {
  *:hover { color: red; }
}

then then gets you

a *:hover { ... }



Similarly, to add a class to the parent, mine does:

a {
  \&.foo {
  }
}

expands to a.foo {}


Something sass does that mine does NOT do is:

a {
  body & {}
}

which expands into body a {} and that's potentially useful. I think I'll add that.


* * *


I've done the import thing before but I don't think it was in css.d, I think I did that in the work app's proprietary file.

I do support @media rules but only on the outer level. sass also supports them inside a nested thing. That's kinda useful.

* * *

Looping and such? Yikes. I think I actually do support looping via one of the macros, but the syntax is pretty different.

On Thursday, 24 April 2014 at 03:59:00 UTC, Rikki Cattermole wrote:
> Can we have it as a library?

css.d in there has the lib code now with my other html stuff stripped out so it has fewer dependencies. Can dub just use it without using the little main file?

Note btw that this code is *brutally* slow and should be done ahead of time or at least aggressively cached; if you regenerate the file on each request you'll be surprised by how much cpu time it wastes.

The implementation is pretty much a brute force string search in a replace loop.