Jump to content

13.

Clients
  • 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

Posts posted by 13.

  1. 1 hour ago, bfarber said:

    The Pages application is designed to allow you an easier way to create custom pages, layouts, blocks and so on.

    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.

  2. 5 minutes ago, Fast Lane! said:

    My biggest fear with an app (and why I won't offer it to my users) is as follows:

    - it breaks the site wide experience since I have many elements of our site beyond the forums. I want them to have the full experience. Not just chat. If they used the app they would probably not use the mobile site much (which has tons of other content) and when they did click on links to those areas of the site it would be a jarring experience swapping to the browser and back. 

    - there is no way to monetize the app well.  Def not as well as the web. 

    My expectation is that I'll stick with the mobile responsive view of the site which works just fine. 

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

  3. @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.

  4. 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?
     

    19 hours ago, Matt said:

    We can definitely do more with our PWA implementation, but we decided the sensible approach was to create native apps.

    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.

  5. 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:

    Quote

    1
    2
    3
    4
    5
    6
    7
    8

    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.

  6. It would be great to use the "Expand" feature with blocks of code in the same way as with quotes.

     

    Quote

    Long quote example

    Long quote example

    Long quote example

    Long quote example

    Long quote example

    Long quote example

    Long quote example

    Long quote example

    Long quote example

    Long quote 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
    
    Long code example

     

  7. Well, it now supported in all popular browsers:

    1. all current chromium-based browsers (Chrome, Edge, Opera, Yandex, etc).
    2. 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 :smile:

  8. +1 for the night mode.

    1. 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).
    2. There must be a setting that allows changing the preference:
      1. on the account-level (manually selected preferred color scheme is stored in DB).
      2. in the cookies (for guests).

    Exactly like it works here and here.

  9. In this announce new feature called "quote collapse" was mentioned. It would be nice to have the same feature for code blocks. Thanks.

    Quote

    Quote Collapse
    We will finish with another popular feature request; the ability for long quotes to be collapsed, reducing the amount of scrolling one has to do.

    Quite simply, Invision Community collapses long quotes with an option to expand them to read the entire quote.

    quote collapse.jpg

    Thank you to all our customers who have taken the time to leave feedback. As you can see, we do listen and action your feedback.

     

  10. 37 minutes ago, Sonya* said:

    Users are also not able to edit html source.

    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).
     

     

    Example: spoilers are not available in editor on IPS website, but as they allowed in HTMLPurifier, we able to add them using HTML even when we do not have "HTML Source" mode in the CKE.

  11. 10 minutes ago, Sonya* said:

    I do not really see any security issue with those two attributes.

    1. name — no problems except it was excluded from HTML5 🙂
    2. 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.
×
×
  • Create New...