On Wednesday, 23 April 2014 at 22:12:08 UTC, Nick Sabalausky wrote:
> SCSS has always been more interesting to me than SASS, but yea, this seems to pretty much be an independently-developed equivalent to SCSS, which is pretty cool.

The funny thing is I wrote this thing a few years ago, 2011 I think, and I've been using it on several sites too. It's just been hidden from the general public in my misc. github :P

There's also a javascript macro expander which adds foreach to that language via text macro hidden away in that html.d as well...

>> Yeah, let's have a page like Peter Norvig (http://norvig.com). It's all
>> about the content after all and if that is good the rest doesn't matter.
>
> I didn't say style was irrelevent. I only said that there should actually *be* content.

Sorry for the irony :), indeed fluffy sites without content are useless.
Reminds me of http://vimeo.com/89527215.

On Wed, Apr 23, 2014 at 06:08:52PM -0400, Nick Sabalausky via Digitalmars-d wrote: [...]
> But I have noticed a lot of the sites that use anchor links to switch to completely different pages are basically broken. Since the very *beginning* of HTML, links have always been downright trivial to implement, and have always been considerably *easier* to *not* require JS. It's pretty much the single simplest, easiest, most fundamental thing in HTML. And yet, more than a decade now after <a onclick="..."> linking inexplicably appeared, some people are *still* trying to implement links using JS. It's insane.
[...]

I'm still amazed at the number of news sites that have non-functional links the moment you disable JS. I had been running my browser with JS turned on by default for many years, 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. 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?!

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 (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). Doesn't fix the JS link issue, though, but so far, I've decided that it's not worth the bother to find out what's behind such non-working links -- esp. since Google will readily give me pages upon pages of other places where I can get similar information! >:-)


> However, you'll have to pardon that little rant. When I posted that "Apparently they can't even manage make basic links work properly", I swear it wasn't my intention to do another JS-rant. Coming from me, JS rants are pretty much redundant at this point ;)

JS rants are fun. ;-)


T

-- 
We've all heard that a million monkeys banging on a million typewriters will eventually reproduce the entire works of Shakespeare.  Now, thanks to the Internet, we know this is not true. -- Robert Wilensk

>> Maybe we can limit the SCSS dependency by checking in the rendered CSS, so only people working on the style would need a sass compiler.

> I was thinking of that too, but I used this approach on one of previous projects (both, SCSS and generated CSS files were under git) and it just gave me headache as the coworker was changing CSS and committing those changes which leaved SCSS and CSS files out of sync.

Obviously not the way to do it.

> But we could easily just agree not to do it, and state that we don't accept pull requests that have direct changes in CSS.

I think this will work out nice, css doesn't change very often.

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

On 4/23/14, 1:53 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Wednesday, 23 April 2014 at 16:13:37 UTC, Andrei Alexandrescu wrote:
>> So I'd dlang.org to foster a behavior depending on the available real
>> estate, as follows:
>>
>> * Cap cpl at e.g. 110 on very large screens.
>>
>> * As the available width decreases, reduce cpl up to 60.
>>
>> * If cpl with sidebar falls below 60, remove the sidebar and obtain
>> e.g. 80 cpl.
>>
>> * As the available width reduces further, allow reduction down to e.g.
>> 35 cpl, and then require horizontal scrolling.
>
> At some point you'll probably realize that the term "cpl" is not
> particularly meaningful in this context because:
>
> 1. you don't use a monofont and have to figure out what "cpl" is in "em"
> or "rem".

I'm talking averages.

> 2. adults detect phrases, not characters, so any measurements are done
> on the wrong unit anyway.

For a given language (English in our case), the relationship translates into average words per line.

> 3. quantitative human factors studies that go beyond your inate
> capabilites tend to be full of severe methodological flaws.

Uhm...

> Waste of time.

I doubt it.


Andrei

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

Can we have it as a library? Instead of as only an executable? Aka no main function.

On 24/04/14 00:12, Nick Sabalausky wrote:

> SCSS has always been more interesting to me than SASS, but yea, this
> seems to pretty much be an independently-developed equivalent to SCSS,
> which is pretty cool.

Technically, Sass is the name of the language. It provides two syntaxes, SASS and SCSS. SCSS seems to be the preferred one. It's used as the default for examples on the web site, Ruby on Rails uses this by default. It's also a superset of CSS.

-- 
/Jacob Carlborg

On 24/04/14 00:08, Nick Sabalausky wrote:

> They don't work.
>
> But...maybe they're only intended to be single-page-only examples? (Now
> that I think about it...)

Yes. Bootstrap won't touch your links with JavaScript, unless you tell it to.

> If so, then I must have misunderstood the examples. The fact that
> they're all pointing to different anchor links threw me off and made me
> assume they were supposed to be functional. (I'm accustomed to blank
> zero-length anchors being used to indicate "intentionally non-functional
> placeholder link".)

Yeah, I don't know why they do that.

> But I have noticed a lot of the sites that use anchor links to switch to
> completely different pages are basically broken. Since the very
> *beginning* of HTML, links have always been downright trivial to
> implement, and have always been considerably *easier* to *not* require
> JS. It's pretty much the single simplest, easiest, most fundamental
> thing in HTML. And yet, more than a decade now after <a onclick="...">
> linking inexplicably appeared, some people are *still* trying to
> implement links using JS. It's insane.

I hate that as well. Sometimes I come to a page, with JS disabled, and it's completely blank. Then my thought process goes something like this: "Hmm, is it loaded. Yes, strange. Oh right I've disabled JavaScript. What is this pieces of crap, can't they design a web site without JS".

> However, you'll have to pardon that little rant. When I posted that
> "Apparently they can't even manage make basic links work properly", I
> swear it wasn't my intention to do another JS-rant. Coming from me, JS
> rants are pretty much redundant at this point ;)

No worries :)

-- 
/Jacob Carlborg

On Wednesday, 23 April 2014 at 23:25:43 UTC, Andrei Alexandrescu wrote:
>> 1. you don't use a monofont and have to figure out what "cpl" is in "em"
>> or "rem".
>
> I'm talking averages.

It varies with the font used. :-P And if you use a webfont the rendering will be less legible than when you use a screen optimized system font. So if you want clarity, unicode coverage and performance you don't know which font you get. :-]

> For a given language (English in our case), the relationship translates into average words per line.

Not necessarily… since groupings aren't neccessarily words. Also, you don't READ prose in programming documentation like a novel, if you are a proficient programmer. You scan, backtrack, read, scan, backtrack, read…

>> 3. quantitative human factors studies that go beyond your inate
>> capabilites tend to be full of severe methodological flaws.
>
> Uhm...

Uhm what? Large sections of psychology are fundamentally flawed as a predictive science, it's primarily interpretative.

Measures are contextual. Reading is a skill, you are better at what you are used to. Besides, reading efficiency is less important than reading comfort.

If studies are off by 50% then that suggest that there are NO HOPE of significant results here.

>> Waste of time.
>
> I doubt it.

You are better off setting something reasonable, test, modify, iterate. And if needed you can always provide a stylesheet switcher (takes 15 minute to implement).