Tom Tromey :tromey Reporter
	Description • 9 years ago

In bug 984880 we agreed to defer handling changes coming from CSSOM.

I think it is possible to handle these changes, though tricky.

When opening the tools, we would have to compare our source text
with the contents of the corresponding style sheets.  This could
be done by first adding a dirty bit to rules, which would be set
by modifications to the rule (or to any property in the rule).
The dirty bit would be cleared by parseStyleSheet.  It might be
handy to have a second dirty bit on the sheet itself, so we could
easily skip a lot of work in the common case that CSSOM is not used.

Then, we'd write a simple CSS parser that would find rule starts
and match these against the rules in the style sheet:

* If an existing rule is found at that location:
  * If the rule is dirty, use the computed css text,
    editing it into the source text (perhaps commenting
    out the old rule so it can be referred to)
  * Otherwise use the source text
* If there is no rule at that location, assume it was removed
  and comment out the rule in the source text

This relies on rule locations remaining the same over edits,
and having some way to distinguish rules added via CSSOM.


While the toolbox is open, the tools would listen to CSSOM changes
and edit them back into the relevant source text.  Perhaps we'd
need a way to explicitly clear the dirty bits here.

	Tom Tromey :tromey Reporter
	Comment 1 • 9 years ago

In the other bug, Patrick pointed this out as an example using CSSOM:

https://bgrins.github.io/devtools-demos/inspector/authored-styles.html

	Tom Tromey :tromey Reporter
	Comment 2 • 9 years ago

It is more robust to just reuse the platform parser when examining the
original style sheet.  I think all we would need to get out of it is a list
of locations at which rules appear.

	Gabriel [:gl] (ΦωΦ)
	Comment 3 • 8 years ago

Filter on CLIMBING SHOES

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)
	Comment 5 • 7 years ago

Tom's plan in comment 0 seems reasonable overall.  A few recent developments may make this a bit easier.  Brad is actively expanding the "dirty" bit fields on sheets in bug 1415940, so we could potentially build on that for this bug as needed. In a separate project, I am working on exposing the Stylo CSS lexer from Rust to DevTools via WASM in bug 1410184, and I believe this should make it easier for DevTools to find the rule starts in the way Tom describes.

	Glenn Linderman
	Comment 6 • 7 years ago

When I create a dynamic style sheet from javascript, there doesn't seem to be any way to view the text of that stylesheet from the debugger's Style Editor. I get a single line (numbered 1) and no content, even though I added 523 rules to the stylesheet.

I can toggle the stylesheet visibility, and see the viewable content be restyled, so the rules are in the sheet, and taking effect, but it is very hard to figure out why they are having the wrong effect. Probably I am generating the rules wrong. It would sure be nice to see them in the style editor, but I guess I'll have to try to log them to the console or something as a workaround until this bug is fixed? From what I can tell, this bug might address the issue?

	Glenn Linderman
	Comment 7 • 7 years ago

After re-reading the comments here, and in the other bugs mentioned, I should point that while editing the authored style sheet and being able to save it is a nice feature for folks that work that way, my style sheets are authored only by javascript... there is no "source file".

On the other hand, when I set the content of a style sheet using innerHTML = big_text_string, then I can see the style sheet in the style editor, even though there is no style sheet source file. It is described as an inline style sheet, but is certainly not present as source in the .html file... it gets inserted into the DOM by javascript.  But when I create a style sheet rule by rule, I get the blank listing. It is also identified as an inline style sheet.  And they are numbered, rather than named. I notice the debugger shows id and class values for variable contents displayed; it would be nice if similar were done for Style Editor when there is no src=, so that the various style sheets can be more readily identified, when id and/or class is given for the <style>.

I guess this gives me another workaround... I could cache the rules as I create them, and then set them into into the sheet via innerHTML. That would only be helpful if repeated calls to innerHTML are reflected in the Style Editor, though, which would take implementation of the scheme to discover. If it caches only the first version, it'd still be hard to see rule #523.

	Glenn Linderman
	Comment 8 • 7 years ago

And the innerHTML workaround works, to let me see the styles I created. They _look_ syntactically correct, but aren't doing quite the right think, maybe an off-by-one error somewhere. Well, it would sure be nice if the Style Editor worked better, it would have saved me a couple hours of head-scratching, bug-searching, bug-reading, and workaround coding. I'll be following any progress here with interest.