Stylish for Chrome 1.3.0b3



  • See the first bullet item in the first post.
  • Default Browser
    sweet, installed new version from first post, this is what i want for a while ago, thank you!
  • I know you guys are working on some cool new features in your spare time, but is there any chance we can get a packed version with the iframe bug fix in the interim?
  • Is there ever going to be a preview option like in firefox?
  • argharhhrrr gief update pretty please D:

    Stylish on Chrome is a butt when it keeps on flashing or if you for instance have set start-up site which uses a style then the style wont apply until you refresh the page (not sure if it's fixed in this release) but that is fine! the flicker-fix you added is super nice and more than I would ever want...

    hmm... you're not by any chance trying to time it exactly to the last time you released an update to the addon which is soon exactly a year ago? :d

    That's... well, I'm fine with that too considering it's tomorrow.
  • Kyo said:

    Is there ever going to be a preview option like in firefox?
  • Released b2, see first post for details.
  • Did some translations for you, hope they'll be useful.
  • Thanks to JasonBarnabe, tophf and hideheader for vastly improving Stylish for Chrome. I do have a couple of questions. Is there a functional search or "find" option that I'm not seeing? The Chrome "find" function still seems useless. The detached editor is one of the best new features. Would it be possible to have a toggle for "always on top"?
  • edited March 2015 Chrome

    anagrammar, Ctrl-F displays a prompt in the "Code" section here and searches it fine. As for always-on-top Chrome only allows it for panels (or rather they are created with this flag enabled by default and apparently no other window types support this flag), but those haven't yet graduated from experimental stuff enabled via chrome://flags. BTW I'm using a convert-window-to-panel extension and haven't seen a panel bigger than 1/6 of screen yet, but anyway I'd like to have such mode in Stylish.

  • Did Ctrl-F always work and I was just oblivious? I tried that extension and it's so close to being great. If it remembered which tabs to open as panels and also remembered tab size preferences, it would be sweet. As it is it's pretty cool, but a little clunky.
  • Global Ctrl-F is a b2 feature.

    b2 also remembers the size and position of a detached editor window here when it's closed. However it's one size for all, so indeed remembering the sizes based on window url is a nice idea.

  • The detached editor size preference is pretty adequate, I was referring to the panels created by the extension you linked. With Ctrl-F is there a way to skip from the first to last instance consecutively like the "find" function?
  • edited March 2015 Chrome

    It's F3 in the 'sublime' keymap. Also Shift-F3. There are other hotkeys defined by the keymap, I use Ctrl-Shift-D frequently to duplicate a line. It'd be nice to have a hotkey cheatsheet link in the editor...

  • Thanks. BTW are tophf & wOxxOm like Bruce Wayne & Batman or am I way off?
  • edited March 2015 Chrome

    lol, kind of.
    idk which one is batman though.

  • Whichever has the deepest voice.
  • There's a new feature not mentioned in the change log: Chrome hotkeys to open Manage styles and toggle DisableAllStyles, to customize go to Chrome Settings -> Extensions -> "Keyboard shortcuts" on the bottom.

  • edited April 2015 Firefox
    I have a request.
    Could you put "Insert Section" button on edit page of the individual styles? (e.g. next to "Add Section" button)
    To be able to insert a new section between sections.
    I think it would make editing of styles more efficient.
  • @seyron, it's already implemented in the beta.

  • Really?
    I'm sorry. Please just forget it xD
  • edited April 2015 Chrome
    Some issues with 1.3.0b2:
    1. The "Back to manage" hotspot is much wider than the "Back to manage" button; they should coincide. The problem stems from this odd construction [fig.1]
      <a href="manage.html">
        <button id="cancel-button">Back to manage</button>
    2. section#actions is irregular, making it very awkward to style. Three buttons, three completely different constructions [fig.1].
    3. Editor boxes should be highlighted when they're focused like other input controls. In Chrome, that's
      :focus {
      outline: -webkit-focus-ring-color auto 5px;
      input:focus, textarea:focus, keygen:focus, select:focus {
      outline-offset: -2px;
    4. Editor sometimes says that code is unchanged when it has changed, and that it's changed when it hasn't.
      1. Edit an existing style.
      2. Type "/*anything*/" to modify the style - asterisk appears, indicating that the text has changed.
      3. Save the style (ctrl+s) - the style is now unmodified, and the asterisk disappears.
      4. Undo what was typed (ctrl+z) - the style has been modified, but the editor indicates that the style is still unchanged.
      5. Redo the change (ctrl+y) - the style is once again unmodified, but the editor indicates that it isn't.
      6. Reload the page (F5) - the (unmodified) style doesn't change, but the editor state changes to indicate an unmodified style.
    5. Code errors are reported where there is no error. This for example:
      .\. {color: red}
    6. No warning for @import, which works locally but will prevent a style from being uploaded. Could be, should be, but isn't.

      Popup menu

    7. The menu items should be vertically aligned, with an optional checkbox in the left gutter. Compare the menu in Chrome with that in Firefox [fig.2] (or almost any other desktop app you've used in the last 20 years).
    8. Graying out of disabled menu entries is inconsistent. All styles are grayed out when all styles are disabled, but individual styles that are disabled are not grayed out.
    9. The toolbar icon should change when no styles are enabled, as in Firefox.
    10. "Edit" and particularly "Delete" shouldn't be so near the "Enable" checkbox. support

    11. There is still no support for chrome-extension: URLs at Styles that match that protocol with url() or url-prefix() can't be uploaded, and "Find more styles" returns the undifferentiated "Top themes and skins" page.
    And what happened to code highlighting on You were hot to do it three weeks ago.
    628 x 359 - 28K
    333 x 321 - 9K
  • edited April 2015 Chrome

    @hideheader, I agree with one small amendment: "disable all styles" should probably simply set styleElement.disabled = true.

  • 1, 2, 4: Done with no additional comments.

    3: Done, and filed

    5: I've looked at the CSS spec, and I don't think that's valid, though seemingly supported by browsers. At the very least, it's in the realm of "you're doing something weird, feel free to ignore the error icon".

    6: @import is really only a problem in Firefox. I don't want to annoy Chrome users (or even Firefox users for their personal styles) with the issue.

    7: Assuming you mean "horizontally", done.

    8: Switched to a strike-through. Part of the idea behind "turn all styles off" is that you can enable and disable styles without them taking effect. Showing them as disabled is misleading.

    9:, not going to be in this release.

    10: Gave you 2px of wiggle room.

    11 and unnumbered comment: Those are both filed issues. I've been on vacation and doing things you don't care about recently.

  • 5: I've looked at the CSS spec, and I don't think that's valid, though seemingly supported by browsers.

    The selector is valid, but that grammar has errors. According to the spec, .\. is valid but #\. is not. The grammar has it reversed. This
    ident     [-]?{nmstart}{nmchar}*
    name {nmchar}+

    "#"{name} return HASH;
    class : '.' IDENT ;
    should instead be this
    ident     [-]?{nmstart}{nmchar}*
    name {nmchar}+

    "#"{ident} return HASH;
    class : '.' NAME ;
    to be consistent with the spec. The browsers are true to the spec, but CSSLint evidently followed the grammar, despite W3C's caveat. That's a bug.

    6: @import is really only a problem in Firefox.

    No. @import fails 100% of the time when uploading to, so it's really a problem in Chrome, too. Its presence shouldn't be an error because it's valid CSS everywhere else, but it should raise a warning because the style will be blocked when its uploaded. And how annoying is that, eh? (More annoying than revisiting those little squiggles that plagued you so? Definitely.)

    8: Switched to a strike-through.

    Yikes! But if users believe that a grayed-out entry with a check mark is disabled, won't they also believe that an entry without a check mark is enabled because it isn't grayed-out?

    10: Gave you 2px of wiggle room.

    Well, that's 2px more than you usually give me. Is it enough for those users who won't be restyling the menu, though?

    [1] The class attribute

    Every HTML element may have a class attribute specified.

    The attribute, if specified, must have a value that is a set of space-separated tokens representing the various classes that the element belongs to.

    The classes that an HTML element has assigned to it consists of all the classes returned when the value of the class attribute is split on spaces. (Duplicates are ignored.)

    There are no additional restrictions on the tokens authors can use in the class attribute...

    6.3.1. Attribute presence and value selectors
    CSS2 introduced four attribute selectors:
    [att~=val]Represents an element with the att attribute whose value is a whitespace-separated list of words, one of which is exactly "val". If "val" contains whitespace, it will never represent anything (since the words are separated by spaces). Also if "val" is the empty string, it will never represent anything.

    Attribute values must be CSS identifiers or strings. [CSS21] The case-sensitivity of attribute names and values in selectors depends on the document language.

    6.4. Class selectors
    Working with HTML, authors may use the "period" notation as an alternative to the ~= notation when representing the class attribute. Thus, for HTML, div.value and div[class~=value] have the same meaning. The attribute value must immediately follow the full stop (.).

  • myfmyf
    edited April 2015 Chrome
    Tangentially related: recently I've found, that according w3c CSS validator (and, erm, specs) for example #\.{} is really a valid selector (as hideheader suggested), and that it actually matches <p id="."> (in browsers I checked: Chrome, Firefox, as Jason also noted) even though it is obviously invalid ID value.

    This led me to funny conclusion that we can abuse negation pseudoclass to construct highly specific 'anything' selector: *:not(#\0):not(#\0){} (weighting two IDs, in this case) that cannot collide with any real ID value, provided it is not possible to enter 'null' control character in HTML. Quite evil, isn't it? :]
  • edited April 2015 Firefox

    The selector is valid, but that grammar has errors.

    In any case, if you want pursue it, you can talk to the CSSLint (and CSS spec!) people. I'm not convinced, and I don't care enough anyway.

    No. @import fails 100% of the time when uploading to, so it's really a problem in Chrome, too. Its presence shouldn't be an error because it's valid CSS everywhere else, but it should raise a warning because the style will be blocked when its uploaded.

    No, I don't think so. There's other things that I don't allow on but you can run locally without issue. If it's an issue for upload, you will be notified at upload.

    if users believe that a grayed-out entry with a check mark is disabled, won't they also believe that an entry without a check mark is enabled because it isn't grayed-out?

    The control is enabled, regardless of whether the style is. I just want something super-noticable saying "hey, something's up!".

    Well, that's 2px more than you usually give me. Is it enough for those users who won't be restyling the menu, though?

    Can't say I've ever accidentally deleted a style this way, with the confirmation and all, so yes.
  • b3 is out, see first post for details.
  • edited April 2015 Chrome

    Available here.

    Translation is now on Transifex

    Changes since 1.3.0b2

    • Styles applied to Stylish internal pages are applied more quickly.
    • Styles for domains are now applied when on non-standard ports.
    • Style changes are now immediately applied to the Stylish pop-up.
    • Fixes an editor bug related to undoing and unsaved changes.
    • Various tweaks to the layout of the pop-up and editor.

    Changes since 1.3.0b1

    Thanks to @tophf and @hideheader who have submitted numerous pull requests in this version.

    • Many changes to the UI, mostly the editor
    • Turn on/off all styles feature
    • Improved application of styles to iframes
    • Added Dutch translation

    Changes since 1.2.2

    • Stylish now applies styles earlier, greatly reducing or eliminating "flicker".
    • Styles are now applied as late in the document as possible. This provides more consistency and better compatibility with Firefox.
    • Stylish can now affect some dynamically generated iframes. (It's kind of flaky.)
    • Stylish can now affect file: URIs. You must enable this from the Extensions page.
    • Stylish can now affect its own pages - chrome-extension://fkcllfpkdjkihkdjkaihobkbbebkcdlf/manage.html, chrome-extension://fkcllfpkdjkihkdjkaihobkbbebkcdlf/popup.html, and chrome-extension://fkcllfpkdjkihkdjkaihobkbbebkcdlf/edit.html. It still can't affect other chrome-extension: URIs.
    • Updated display of toolbar pop-up, including links for creating a new style for the current site.
    • Updated CodeMirror (code editor) - long code no longer gets cut off when pasting.
    • Styles are now sorted alphabetically in manage page.
    • Detach an edit tab and then all edit pages will open in new windows. Reattach and they'll go back to opening in tabs.
    • Don't show styles with two @namespaces as global.

    tophf said:

    I am kinda late but.....

    Thanks all of you for getting this version to affect its own pages. Now I can get back to working on my styles with the editor window height further down the page.

    I stopped using stylish because chrome protection extension crap stopped me from editing the core files and the other solutions for a temp fix wasn't really what I wanted.

    This is nice. The help of CTRL S to save was a habit on Notepad ++ and now I can do it on stylish is amazing. Thanks for your time in this wonderful version. Really. Happy coding guys :)

    Thanks a mill.
  • edited April 2015 Chrome
    Some issues with 1.3.0b3:

    1. There's excess space below "Turn all styles off" [fig.1]
    2. There's no space below "Write style for ...". It's particularly noticeable when the actions precede the styles [fig.2].


    3. F3 behaves inconsistently if F3 isn't in the keymap. When the cursor is in an editor box, F3 opens Chrome's "Find" bar. When the cursor is not in an editor box, F3 opens CodeMirror's "Find" bar in a random editor box. Chrome's "Find" should never open in an editor page, and only keys bound to the find, findNext, findPrev, and replace commands should open CodeMirror's "Find".

      Shift+F3 fails in the same way.
    4. Ctrl+G keymap bindings are ignored. Ctrl+G is bound to findNext when "Keymap:" is Linux-ey "default" or "pcDefault", but instead it does jumpToLine and not findNext.

      Now to "find next" while using these keymaps, you must click outside the editor box to blur the editor, then press F3 (not Ctrl+G).
    5. jumpToLine should be Ctrl+J when "findNext" is Ctrl+G. For consistency with Firefox, unless there's a more common Linux usage.
    6. Ctrl+S should be "findNext" in the "emacsy" keymap. Instead, Ctrl+S saves the style.
    7. Ctrl+R should be "findPrev" in the "emacsy" keymap. Instead, Ctrl+R reloads the editor page.
    8. Ctrl+F shouldn't open CodeMirror's "Find" bar when the "emacsy" keymap is selected. Ctrl+F is "goCharRight" in emacs; it has nothing to do with Find.
    9. The "vim" keymap is missing.
    10. The "pcDefault" keymap doesn't use Windows key bindings. In fact
      JSON.stringify(CodeMirror.keyMap.pcDefault) === JSON.stringify(CodeMirror.keyMap.default)
      so this is surely an upstream oversight.
    11. There's currently no "save" in CodeMirror.commands. And therefore no way to bind "save" to a key in a keymap.
    12. F3 can set the "edited" status when the text hasn't changed. This happens intermittently with any keymap but "sublime". When it happens, "undo" may or may not clear the "edited" status. It happens most often when F3 is pressed while text is selected in a focused editor (which calls up Chrome's "Find" bar if the keymap doesn't bind F3).
    240 x 184 - 8K
    242 x 339 - 10K
Sign In or Register to comment.