In the current WIP patch, the generated style sheet is prepended with : /* * This is a generated style sheet containing simple empty rules for : * {DOCUMENT_URL} */ Maybe it should contain a bit more or be something completely different, Kevin?

How about just: /* * This is a generated style sheet for: * {DOCUMENT_URL} */ I've thought a little about this feature since you demoed it, and I'm wondering how useful it is in practice. These days, there are lots of "resets" and "bootstraps" that people use. More often than not, it seems like designers would be working on layouts when there is already some existing CSS structure in place (adding additional pages, building on top of a WordPress theme, etc.) I've cc'ed Jason Grlicky to see if he (as a designer) has an opinion on how useful this feature would be. (For Jason's benefit: this feature would run through the current document and generate a style sheet with empty rules for selectors that match what is in the document.)

(In reply to Kevin Dangoor from comment #2) > /* > * This is a generated style sheet for: > * {DOCUMENT_URL} > */ Sweet. > I've thought a little about this feature since you demoed it, and I'm > wondering how useful it is in practice. These days, there are lots of > "resets" and "bootstraps" that people use. I think the reset/bootstrap use case is handled by "Import..." isn't it? The goal of this feature is to make 'New' more useful and less intimidating than only having a blank new editor. > I've cc'ed Jason Grlicky to see if he (as a designer) has an opinion on how > useful this feature would be. (For Jason's benefit: this feature would run > through the current document and generate a style sheet with empty rules for > selectors that match what is in the document.) For context, the demo is the first part of http://neonux.com/StyleEditor/contextual-style-editor.ogv

The default behavior of the New button is still to create a blank new style sheet. Clicking on the New button menu gives : [New] ... blank style sheet ... style sheet from markup To accomodate with the use case of not starting from scratch (on small projects at least) but from existing projects with a CSS structure, perhaps we'd like to add : ... style sheet from existing styles Which would also generate blank rules... with selectors of already existing rules (in other style sheets) - making this option useful to override/increment on an existing layout/structure.

It's certainly an interesting feature proposal! I think the use case of modifying existing styles on a project is covered pretty well by modifying the existing stylesheets and hitting "Save" to store a modified copy. Honestly, having to hunt through an auto-generated CSS file for the couple rules I'm looking to override or edit seems more intimidating to me than a blank page. I would be against this functionality as it is described, but it seems like it would be worthwhile to put some thought into how we can leverage integration between the inspector and style editor to make this use case easier for people.

Of course, making the file/line number clickable from the Inspector Rule View would be a great place to start. Another idea is to add functionality to the Node Menu (as described in http://htmlpad.org/devtools-01-12-12/#8.0 ). Imagine that one of the items on the Node Menu was "Styles" (or something), which would be a submenu that would reveal all the style rules that apply to this element. When the user would click on one of those rules, the style editor would open with the cursor positioned on the first property of that rule in the style editor. We'd definitely have to make sure that the style rule names only show the most important parts - we could take a look at what Espresso does in their inspector view for guidance here. I'd love to hear your thoughts.

(In reply to Jason Grlicky [:grlicky] from comment #6) > Of course, making the file/line number clickable from the Inspector Rule > View would be a great place to start. Yes, we have a patch almost ready for this kind of integration Bug 585563 :) Adding a menu item to the node menu is a good idea, we certainly could use Bug 674134 to add a "Create new CSS rule for this element". >I think the use case of modifying existing styles on a project is covered pretty well by modifying the existing stylesheets and hitting "Save" to store a modified copy. I agree. I'm quite unsatisfied though with the current only option "new blank style sheet" UX for the use case of creating a simple new project from scratch - certainly, this use case is much less common, however is having the option to start from a minimal template more harmful than not? For instance, bearcss.com does pretty much the same thing as this and seems quite popular lately.

(In reply to Jason Grlicky [:grlicky] from comment #6) > We'd definitely have to make sure that the style rule names only show the > most important parts Sounds interesting, can you give a bit more of context on this?

(In reply to Cedric Vivier [:cedricv] from comment #7) > Yes, we have a patch almost ready for this kind of integration Bug 585563 :) Yay!! > Adding a menu item to the node menu is a good idea, we certainly could use > Bug 674134 to add a "Create new CSS rule for this element". Yep, exactly! We'd need to let the user pick which stylesheet to put the new rule in, though, which seems like it would require some thought to get the UI non-awkward. > I agree. I'm quite unsatisfied though with the current only option "new > blank style sheet" UX for the use case of creating a simple new project from > scratch - certainly, this use case is much less common, however is having > the option to start from a minimal template more harmful than not? > For instance, bearcss.com does pretty much the same thing as this and seems > quite popular lately. Sorry, I was ambiguous above! I was referring to the "... style sheet from existing styles" option. You're right that the "... style sheet from markup" seems like a fine option to have. It would be handy for new small projects, and people who are learning CSS. As long as the auto-generated CSS is awesome, I've got no problem with this feature ^_^.

(In reply to Cedric Vivier [:cedricv] from comment #8) > (In reply to Jason Grlicky [:grlicky] from comment #6) > > We'd definitely have to make sure that the style rule names only show the > > most important parts > > Sounds interesting, can you give a bit more of context on this? For an example of what CSSEdit did (a couple versions ago, I'm sure), I took a screenshot of the inspector: http://cl.ly/0h3t3l2E2400043b3b1h The line I'm referring to is the "html,body,d...ead,tr,th,td" one. It seems like their algorithm is to list the whole rule, but if it is too long, only show the first and last parts.

(In reply to Jason Grlicky [:grlicky] from comment #9) > (In reply to Cedric Vivier [:cedricv] from comment #7) > > Adding a menu item to the node menu is a good idea, we certainly could use > > Bug 674134 to add a "Create new CSS rule for this element". > > Yep, exactly! We'd need to let the user pick which stylesheet to put the new > rule in, though, which seems like it would require some thought to get the > UI non-awkward. I like this line of thought and I agree that the potential for awkward UI is high. What I like about "Create new CSS rule for this element" is that it helps both when starting a new stylesheet and the much more common case of "I have an existing stylesheet". Of course, we've already got a bug for "Copy selector for this element". With that, the workflow is: 1. select element 2. copy selector 3. switch to Style Editor 4. select stylesheet or hit New 5. paste 6. add {} "Create new rule" basically removes steps 3, 5 and 6 from that list. In the workflow above, manual pasting means that the user gets to choose where in the file to put the result. (In reply to Cedric Vivier [:cedricv] from comment #4) > The default behavior of the New button is still to create a blank new style > sheet. > Clicking on the New button menu gives : > [New] > ... blank style sheet > ... style sheet from markup I agree that that's not obtrusive (as adding a separate toolbar button would be), but (see below) (In reply to Cedric Vivier [:cedricv] from comment #7) > For instance, bearcss.com does pretty much the same thing as this and seems > quite popular lately. People talk about it because it's new. I'm still uncertain how commonly used a feature like this would be. Building every little feature in and giving it UI visibility is how many other tools end up with submenus everywhere (toolbar items, tabs, context menu items). Plus, as Jason points out in his initial response, a generated style sheet means hunting around for the rules you want to work on first. It's not necessarily better than a blank slate. Will a generated sheet be organized in the way that the user would want to organize it? So, I definitely like the idea of helping people get started with new projects and pages, but I'm not sure that this is the best way to do that, and I think the "new pages" use cases are not as important as the others we're trying to work through right now.

(In reply to Kevin Dangoor from comment #11) > Plus, as Jason points out in his initial response, a generated style sheet > means hunting around for the rules you want to work on first. It's not > necessarily better than a blank slate. In the blank slate, you also have to hunt around for element names, IDs and class names that you want to work on first... in another tool. I don't think that's better experience than having them 'ready to use' in the editor. > Will a generated sheet be organized > in the way that the user would want to organize it? It's a starting point, giving you the most basic selectors to start work with. Of course, for any big project the user will want to reorganize to his taste, but for small projects (and learning as Jason pointed out), it gives a good example of efficient selectors imho (no unnecessary specialization). Ok, I guess we can put this feature on hold for now until we have more thinking/feedback about it.

(In reply to Cedric Vivier [:cedricv] from comment #12) > (In reply to Kevin Dangoor from comment #11) > > Plus, as Jason points out in his initial response, a generated style sheet > > means hunting around for the rules you want to work on first. It's not > > necessarily better than a blank slate. > > In the blank slate, you also have to hunt around for element names, IDs and > class names that you want to work on first... in another tool. > I don't think that's better experience than having them 'ready to use' in > the editor. That's a valid point, but there are other possible solutions: 1. copy selector from Page Inspector or create new rule from Page Inspector. Separate tool, but easy workflow if they're looking at the element they want to style. 2. autocompletion: # and . in a selector can then autocomplete based on what's in the document. > It's a starting point, giving you the most basic selectors to start work > with. > Of course, for any big project the user will want to reorganize to his > taste, but for small projects (and learning as Jason pointed out), it gives > a good example of efficient selectors imho (no unnecessary specialization). I agree that this feature has value. It's a question of focusing the UI on things that people are going to do more often than I think people will use this. Addons and GCLI commands are great for less-used features.

Inspector bug triage (filter on CLIMBING SHOES).