therapia.gr - content missing Topic is solved

[back2themoon]

https://www.therapia.gr/ti-einai-to-penthos/

Scroll a bit down and you will see some fairly large blank spaces. Looks like some blocks of text are not getting loaded.

Error Console:

EC.png

[Moonchild]

The text is there, but it's white-on-white. Using text selection it can be revealed.

Image1.png

it seems to be deliberate in the wp theme they use. Not sure why.

Code: Select all

                                    body.single-post > main > article section.curve:nth-of-type(even) {
                                        --color:var(--color6);
                                        --curve-top:url('https://therapia.gr/wp-content/themes/therapia-2022/assets/svg/edge-curve-color6.svg');
                                        --curve-bot:url('https://therapia.gr/wp-content/themes/therapia-2022/assets/svg/edge-curve-color6-flipped.svg');
                                        color: #FFF; /* var(--color2); */
                                    }

[back2themoon]

Yes, you are right. I'm afraid selecting invisible text isn't really a solution. Forgot to mention that there is some colour stylisation in the pages that is missing:

Style.png

[Moonchild]

aha well that would explain the text being unreadable. They swapped colours to contrast with the background, but without the background it doesn't show up in a readable fashion.
The background is being created with some gradient trickery using a ton of in-line calc() inside the gradients which we likely don't yet support.

[Goodydino]

Yes, you are right. I'm afraid selecting invisible text isn't really a solution. Forgot to mention that there is some colour stylisation in the pages that is missing:

Style.png

They do not bother setting a background colour. Since I changed the default background, I saw the white text. I dislike white backgrounds.

[Moonchild]

Yeah but setting a solid background colour as fallback and for accessibility reasons is so 2010.

[back2themoon]

They do not bother setting a background colour. Since I changed the default background, I saw the white text.

Thanks. You reminded me that both text and background colour can be quickly changed with NoSquint. This makes the website essentially fully functional. No styling but I'll survive that.

[adoxa]

Double-position color stops are not supported in linear-gradient, here's a userstyle workaround.

Code: Select all

@-moz-document domain("www.therapia.gr") {
  .curve.top {
    background:
      var(--curve-top) no-repeat left top,
      linear-gradient(to bottom,
        transparent  0.0vw,
        transparent  3.8vw,
        var(--color) 3.8vw,
        var(--color) 100%
      )
      !important;
  }
  .curve.bot {
    background:
      linear-gradient(to bottom,
        var(--color) 0.0vw,
        var(--color) calc(100% - 3.8vw),
        transparent  calc(100% - 3.8vw),
        transparent 100%
      ),
      var(--curve-bot) no-repeat left bottom
      !important;
  }
  .curve.top.bot {
    background: 
      var(--curve-top) no-repeat left top,
      linear-gradient(to bottom,
        transparent 0,
        transparent 3.8vw,
        var(--color) 3.8vw,
        var(--color) calc(100% - 3.8vw),
        transparent calc(100% - 3.8vw),
        transparent 100%
      ),
      var(--curve-bot) no-repeat left bottom
      !important
  }
}

[Moonchild]

Double-position color stops are not supported in linear-gradient

wait... what? Don't tell me they went ahead and changed a very long standing gradient standard...

EDIT: I can't even find anything related to it in BZ to see what changed and why.

[back2themoon]

Double-position color stops are not supported in linear-gradient, here's a userstyle workaround.

Thank you adoxa, works fine. I don't know how you manage to make unsupported features work but hey, I won't complain.

[adoxa]

This one was easy, since "color stop1 stop2" is just shorthand for "color stop1, color stop2" (there's an example at MDN showing just that). Although there does seem to be a transitional line in UXP that isn't present in FF, so maybe it's not quite equivalent, or there's another issue at play.

[Moonchild]

I just don't get how they changed things there. color stops aren't limited to just two. the formal syntax is (still!):

Code: Select all

<linear-gradient-syntax> = 
  [ <angle> | <zero> | to <side-or-corner> ]? , <color-stop-list>  
  
<color-stop-list> = 
  <linear-color-stop> , [ <linear-color-hint>? , <linear-color-stop> ]#?  

# = The hash mark multiplier indicates that the entity may be repeated one or more times (for example, the plus multiplier), but each occurrence is separated by a comma (',').
? = The question mark multiplier indicates that the entity is optional, and must appear zero or one time.
[] = Brackets enclose several entities, combinators, and multipliers, then transform them as a single component. They are used to group components to bypass the precedence rules.
so the syntax ("color stop1 stop2" without commas) used would be incorrect according to that syntax, because commas are mandatory.

[RealityRipple]

They redefined a single <color-stop> to allow two positions:

A color stop with two positions is equivalent to specifying two color stops with the same color, one for each position.

Note: Usually, this results in a solid-color "stripe" between the two positions, but using a longer <color-interpolation-method> will instead create a "rainbow" between the two positions.

It's poorly written, tbh, and only says "two" without saying it can't be more than two.

[Shadow]

I can't even find anything related to it in BZ to see what changed and why.

It appears to be this one.

[Moonchild]

I can't even find anything related to it in BZ to see what changed and why.

It appears to be this one.

Right. Well that's all Servo so that doesn't help us, but I already have a pretty decent idea how this can be done since it's effectively just appending another colour stop if a second position is present. It doesn't fundamentally change the way gradients are parsed.
I disagree with touching the long-established standard in the search of skim-work, though. (possibly another embrace & extend move by Google, here)
Filed Issue #2720 (UXP)

[Moonchild]

User style workaround should no longer be necessary with 33.7.0

[back2themoon]

Thanks for the fix/implementation, I did notice the release notes. Can't verify yet (SSE2) but I'm sure it is fine.