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?
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.
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"?
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.
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?
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...
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.
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.
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>
</a>
section#actions is irregular, making it very awkward to style. Three buttons, three completely different constructions [fig.1].
Editor boxes should be highlighted when they're focused like other input controls. In Chrome, that's
Editor sometimes says that code is unchanged when it has changed, and that it's changed when it hasn't.
Edit an existing style.
Type "/*anything*/" to modify the style - asterisk appears, indicating that the text has changed.
Save the style (ctrl+s) - the style is now unmodified, and the asterisk disappears.
Undo what was typed (ctrl+z) - the style has been modified, but the editor indicates that the style is still unchanged.
Redo the change (ctrl+y) - the style is once again unmodified, but the editor indicates that it isn't.
Reload the page (F5) - the (unmodified) style doesn't change, but the editor state changes to indicate an unmodified style.
Code errors are reported where there is no error. This for example:
.\. {color: red}
No warning for @import, which works locally but will prevent a style from being uploaded. Could be, should be, but isn't.
Popup menu
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).
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.
The toolbar icon should change when no styles are enabled, as in Firefox.
"Edit" and particularly "Delete" shouldn't be so near the "Enable" checkbox.
Userstyles.org support
There is still no support for chrome-extension: URLs at Userstyles.org. 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.
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.
No. @import fails 100% of the time when uploading to Userstyles.org, 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.)
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?
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...
[2] http://www.w3.org/TR/css3-selectors/#attribute-representation 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 identifiersor strings. [CSS21] The case-sensitivity of attribute names and values in selectors depends on the document language.
[3] http://www.w3.org/TR/css3-selectors/#class-html 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 (.).
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? :]
No. @import fails 100% of the time when uploading to Userstyles.org, 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 userstyles.org 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!".
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.
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 :)
There's excess space below "Turn all styles off" [fig.1]
There's no space below "Write style for ...". It's particularly noticeable when the actions precede the styles [fig.2].
Keymaps
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.
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 (notCtrl+G).
jumpToLine should be Ctrl+J when "findNext" is Ctrl+G. For consistency with Firefox, unless there's a more common Linux usage.
Ctrl+S should be "findNext" in the "emacsy" keymap. Instead, Ctrl+S saves the style.
Ctrl+R should be "findPrev" in the "emacsy" keymap. Instead, Ctrl+R reloads the editor page.
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.
The "vim" keymap is missing.
The "pcDefault" keymap doesn't use Windows key bindings. In fact
There's currently no "save" in CodeMirror.commands. And therefore no way to bind "save" to a key in a keymap.
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).
Comments
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.
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.
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.
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...
lol, kind of.
idk which one is batman though.
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.
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.
I'm sorry. Please just forget it xD
Editor- 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]
- Editor boxes should be highlighted when they're focused like other input controls. In Chrome, that's
- Editor sometimes says that code is unchanged when it has changed, and that it's changed when it hasn't.
- Edit an existing style.
- Type "/*anything*/" to modify the style - asterisk appears, indicating that the text has changed.
- Save the style (ctrl+s) - the style is now unmodified, and the asterisk disappears.
- Undo what was typed (ctrl+z) - the style has been modified, but the editor indicates that the style is still unchanged.
- Redo the change (ctrl+y) - the style is once again unmodified, but the editor indicates that it isn't.
- Reload the page (F5) - the (unmodified) style doesn't change, but the editor state changes to indicate an unmodified style.
- Code errors are reported where there is no error. This for example:
- No warning for @import, which works locally but will prevent a style from being uploaded. Could be, should be, but isn't.
- 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).
- 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.
- The toolbar icon should change when no styles are enabled, as in Firefox.
- "Edit" and particularly "Delete" shouldn't be so near the "Enable" checkbox.
- There is still no support for chrome-extension: URLs at Userstyles.org. 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 Userstyles.org? You were hot to do it three weeks ago.section#actionsis irregular, making it very awkward to style. Three buttons, three completely different constructions [fig.1].:focus {outline: -webkit-focus-ring-color auto 5px;
}
input:focus, textarea:focus, keygen:focus, select:focus {
outline-offset: -2px;
}
.\. {color: red}Popup menu
Userstyles.org support
https://github.com/JasonBarnabe/stylish-chrome/pull/76
@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 https://github.com/codemirror/CodeMirror/issues/3187
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:
@importis 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: https://github.com/JasonBarnabe/stylish-chrome/issues/100, 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.
.\.is valid but#\.is not. The grammar has it reversed. Thisident [-]?{nmstart}{nmchar}*
should instead be thisname {nmchar}+
"#"{name} return HASH;
class : '.' IDENT ;
ident [-]?{nmstart}{nmchar}*
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. No. @import fails 100% of the time when uploading to Userstyles.org, 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.) 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? Well, that's 2px more than you usually give me. Is it enough for those users who won't be restyling the menu, though?name {nmchar}+
"#"{ident} return HASH;
class : '.' NAME ;
[1] https://html.spec.whatwg.org/multipage/dom.html#classes
3.2.5.7 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...
[2] http://www.w3.org/TR/css3-selectors/#attribute-representation
6.3.1. Attribute presence and value selectors
CSS2 introduced four attribute selectors:
...
[att~=val]Represents an element with theattattribute 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.
[3] http://www.w3.org/TR/css3-selectors/#class-html
6.4. Class selectors
Working with HTML, authors may use the "period" notation as an alternative to the
~=notation when representing theclassattribute. Thus, for HTML,div.valueanddiv[class~=value]have the same meaning. The attribute value must immediately follow the full stop (.).<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? :]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.
Popup
Keymaps
find,findNext,findPrev, andreplacecommands should open CodeMirror's "Find".Shift+F3 fails in the same way.
findNextwhen "Keymap:" is Linux-ey "default" or "pcDefault", but instead it doesjumpToLineand notfindNext.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).
jumpToLineshould be Ctrl+J when "findNext" is Ctrl+G. For consistency with Firefox, unless there's a more common Linux usage.CodeMirror.commands. And therefore no way to bind "save" to a key in a keymap.