Jump to content

13.

Members
 View Profile  See their activity

  • Posts

    1,233

  • Joined

  • Days Won

    6

 Content Type 

Downloads

Release Notes

IPS4 Guides

IPS4 Developer Documentation

Invision Community Blog

Development Blog

Deprecation Tracker

Providers Directory

Forums

Events

Store

Gallery

Everything posted by 13.

  1. 13.
    Don't serve content over HTTP. Use HTTPS for all resources on the page.
  2. 13.
    We know, and we don't need it all. At all 🙂 The only thing we need is a widget where we could use HTML. It has to be a core functionality. It's logical and obvious. It's a weird way to try selling the "Pages" app. It causes distrust and disappointment, not sales. 😥 Please, discuss it internally. I'm sure the Pages app will not suffer from moving such a small feature to a more logical place - the core.
  3. 13.
    +1 for moving this feature into the core. In our case, we don't need pages app at all. Just one widget is not a good reason to buy something you don't need.
  4. 13.
    Multilingual search using language identification in Elasticsearch. I hope to see the improvements described in this guide in IPS.
  5. 13.
    <meta charset="utf-8"> must be the first element in <head> in the default template in order to keep code valid even if Custom tracking code is long. Current placement causes problems with validation. Example: Community Validator Report Error: Solution is simple:
  6. 13.
    Any news on this? JFYI: I'm one of these clients who does not have it installed because there is no reason to install while IPS does not support it. Your move must be first. Also, as a step even further, it would be good to integrate the support of https://imgproxy.net/ (https://github.com/imgproxy/imgproxy)
  7. 13.
    Suggestion. I would love to see separate limits for positive and negative reactions in the IPS: Thanks.
  8. 13.
    In activity feed, how it looks now: How it could look:
  9. 13.

    Error Log Banning

    13. replied to Bluto's topic in Feedback

  10. 13.
    And both of these fears are relevant only for native applications, while PWA does not add any risks at all, but gives only benefits.
  11. 13.

    "Expand" for code blocks

    13. replied to 13.'s topic in Feedback

    @Ioannis D, this is what I'm using since IPS 4.0.0 on my communities for both quotes and code blocks, but this topic is not about it. Since 4.5 finally has an "Expand" feature, it would be great to use it with code blocks instead of this CSS-based workaround which is not that convenient.
  12. 13.
    @breatheheavy, I am sure that you understand that this is just a special case and has nothing to do with the situation as a whole.
  13. 13.
    We said it many times. We do care about Android. Apple is insignificant on the global mobile market in terms of devices number. There are a lot of IPS customers who have more than 90% of mobile users with Android. Why should they suffer and even care about crazy Apple's politics, while these incredibly useful features work great on Android and could benefit your customers and most of their users today? Wasting years to create separate apps from scratch instead of a couple of weeks to create PWA based on code which was developed and improved for years and almost ready for it... Does not sound "sensible". I understand, you hope what native app could become another source of $ when it's done, and (unfortunately) this looks like the only real reason why you don't want implement PWA. Because the argument about Apple does not look significant at all, given their real share of users. I hope you re-evaluate the amount of time it takes to develop PWA vs native applications and will finally make the right choice.
  14. 13.
    Currently, if quote height is more than 7 lines, everything after the 7th line is hidden under the "Expand" button. But it is not a good idea to use this logic for quotes where height is insignificantly more than 7. Here is the example: As you can see, using "Expand" in this case is unnecessary and only complicates the interface and adds inconvenience. Instead of hiding everything after the 7th line, even if quote height is just 8 lines, I suggest hiding the quoted content after the 7th line only if the content height is more than 12 lines.
  15. 13.
    The interface has unnecessary duplicate elements in some places. It would be great to get rid of this duplication and thereby simplify the interface and make it more clean and readable. Here is some examples:
  16. 13.
    It would be great to use the "Expand" feature with blocks of code in the same way as with quotes. Long code example Long code example Long code example Long code example Long code example Long code example Long code example Long code example Long code example Long code example Long code example Long code example
  17. 13.
    😭
  18. 13.
    Well, it now supported in all popular browsers: all current chromium-based browsers (Chrome, Edge, Opera, Yandex, etc). the future release of Firefox (75, will be released in less than a month). These browsers are covering more than 94% of traffic on my websites, so I already implemented native lazy loading on some of them. And it works just great
  19. 13.
    +1 for the night mode. It must be used by default if @media prefers-color-scheme is set to dark and the user did not override it using the site-level setting (point 2). There must be a setting that allows changing the preference: on the account-level (manually selected preferred color scheme is stored in DB). in the cookies (for guests). Exactly like it works here and here.
  20. 13.
    Yeeeeeeeeees (for any conent items, not only for messages)
  21. 13.
    Currently we can report only content items, but sometimes it would be useful to report a user, for example in cases when user account was made is only in order to leave links in it's profile and "About me" section, like this.
  22. 13.
    In this announce new feature called "quote collapse" was mentioned. It would be nice to have the same feature for code blocks. Thanks.
  23. 13.
    @Joy Rex, it's about filtering at the IPS level, not CKE.
  24. 13.
    Actually all users always are able to edit HTML (via browser's dev tools, for example), so if id attribute will be allowed in HTMLPurifier, then they could add IDs even while they don't have permission to use HTML mode in CKE. Also IDs will appear in their messages unintentionally when they copying and pasting something with IDs. For example in case when they quoting the messages from your editors, there could appear more than one ID with the same value on the page (it does not carries any significant risks but its something what we should keep in mind allowing IDs in HTMLPurifier).
  25. 13.
    name — no problems except it was excluded from HTML5 🙂 id — what if user will specify ID which already exists on the page? It could brake some JS-based functionality in cases when JS refers to this id.
Invision Community © 2024 IPS, Inc.
×
×
  • Create New...