Re: CSS developer tools
Barry van Oudtshoorn
I can see:
1. The "doctor" won't work with large stylesheets -- searching through
them will become too much of a pain. As the developer of a large
web-app, I'm well aware that stylesheets can very quickly reach
thousands of lines, with potentially thousands of selectors. I think
that the assumption with developer tools should always be that the
developer knows what they're doing: in the example, the developer would
*know* that the styles in #content don't apply to #inspectedNode. The
interface in Firebug and the like is, I think, more generally useful:
you can see all of the selectors that apply to the inspected element,
and how those styles cascade. I'm not saying that I think the doctor
needs to go, just that I think that it will be of limited utility to
those developing large stylesheets, and should therefore be supplemented
by an interface similar to that existing in Firebug already.
2. When I start a new page or section of an app, what I do is decorate
the various elements with classes, write the selectors I'm likely to
need, and then fire up Firebug. I inspect the elements, and start
filling in the styles under each selector, transferring the CSS manually
as I go. I don't see how this sort of workflow will work -- how will I
go about actually editing styles for an inspected element quickly?
3. The inspector is based around styles, rather than rules and
stylesheets. I guess this works if the user's goal is to merely inspect
-- but if their goal is to *develop*, then surely it makes sense to
organise the data presented according to how it's organised in their
development environment? After all, these are *developer tools*. ;)
I guess that in summary, I'm saying that while these mockups certainly
look interesting, and present novel and potentially beneficial ideas, I
can't see anything that makes them "better". I'm not wanting to suggest
that this is reinvention merely for the sake of it, but I think that
it's perhaps worthwhile investigating how developers use the existing
tools, and using that as the foundation for new development.
On a more general note (which, I'll admit, I should probably have
started a new thread for), I'm starting to worry that the developer
tools in Firefox are becoming somewhat too disconnected from each other,
and end up reinventing the wheel (or at least parts of it). For example,
we have the console, the scratchpad, and the GCLI, all of which do the
same *sort* of thing, albeit in different contexts and with different
approaches. Now we have the CSS Error Console, the CSS Doctor, the CSS
Inspector, and the Style Editor. I really think that there needs to be
more integration between the tools, and as little duplication of effort
as possible. When I want to develop or tinker with a site, I don't want
to first have to think of which tools is bested suited to the job:
"Should I use the console? But that's not as fast as the GCLI. But if I
want to save my code, I should use the Scratchpad!"
I hope I haven't come across as too negative -- I'm really excited by
the work being done on the devtools, and I think that there are some
really good ideas coming out.
- Barry
On 20/07/11 00:18, Joe Walker wrote:
>
> There was a bit of confusion about exactly how the CSS tools that
> devtools are building worked, so I've created some mockups that
> describe what we're doing.
>
> https://people.mozilla.com/~jwalker/css-panels/
>
> Feedback welcome.
>
> Joe.
>
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
--
Barry van Oudtshoorn
www.barryvan.com.au
Not sent from my Apple πPhone.
Kevin Dangoor
bvanoud...@gmail.com> wrote:
> I like some of the thinking behind this, but there are a few issues that I
> can see:
>
> 1. The "doctor" won't work with large stylesheets -- searching through them
> will become too much of a pain. As the developer of a large web-app, I'm
> well aware that stylesheets can very quickly reach thousands of lines, with
> potentially thousands of selectors. I think that the assumption with
> developer tools should always be that the developer knows what they're
> doing: in the example, the developer would *know* that the styles in
> #content don't apply to #inspectedNode. The interface in Firebug and the
> like is, I think, more generally useful: you can see all of the selectors
> that apply to the inspected element, and how those styles cascade. I'm not
> saying that I think the doctor needs to go, just that I think that it will
> be of limited utility to those developing large stylesheets, and should
> therefore be supplemented by an interface similar to that existing in
> Firebug already.
>
The Doctor might be of limited utility to CSS masters... but the ability to
catch things like "inline elements cannot have a width property" or
"box-direction: vertical is incorrect, perhaps you meant box-orient:
vertical?" in a single step without having to poke around at docs seems like
a win, if we can make the ruleset robust enough.
I do agree that it's important that the developers *can* get at the "raw"
information, but I also think that it's important to let the tools do as
much as possible to complete the task at hand.
> 2. When I start a new page or section of an app, what I do is decorate the
> various elements with classes, write the selectors I'm likely to need, and
> then fire up Firebug. I inspect the elements, and start filling in the
> styles under each selector, transferring the CSS manually as I go. I don't
> see how this sort of workflow will work -- how will I go about actually
> editing styles for an inspected element quickly?
>
Oooh, you're going to be a perfect tester for something we've got in mind.
The idea is not yet fully baked (and doesn't even have a feature page
started), but the end goal would be that you'd be able to use the Style
Editor for this. I've just added a note to my todo list to start working on
that feature page soon so that we can start hammering out the details.
> 3. The inspector is based around styles, rather than rules and stylesheets.
> I guess this works if the user's goal is to merely inspect -- but if their
> goal is to *develop*, then surely it makes sense to organise the data
> presented according to how it's organised in their development environment?
> After all, these are *developer tools*. ;)
>
This actually makes clear something I was wondering about earlier today. I
was trying to think of the use case supported by organizing around
stylesheet/rules. Personally, I would rather use an editor environment for
developing than an inspection environment... and that's the goal we're
shooting for.
> I guess that in summary, I'm saying that while these mockups certainly look
> interesting, and present novel and potentially beneficial ideas, I can't see
> anything that makes them "better". I'm not wanting to suggest that this is
> reinvention merely for the sake of it, but I think that it's perhaps
> worthwhile investigating how developers use the existing tools, and using
> that as the foundation for new development.
>
Yes, indeed. I'll go what I think is a step beyond "how developers use the
existing tools" and say that what we're really looking for is "what are
developers trying to do". Your explanation above of what you wanted out of
the CSS inspection was perfect because you explained not just how you use
the existing tool but what you were trying to accomplish.
>
> On a more general note (which, I'll admit, I should probably have started a
> new thread for), I'm starting to worry that the developer tools in Firefox
> are becoming somewhat too disconnected from each other, and end up
> reinventing the wheel (or at least parts of it). For example, we have the
> console, the scratchpad, and the GCLI, all of which do the same *sort* of
> thing, albeit in different contexts and with different approaches. Now we
> have the CSS Error Console, the CSS Doctor, the CSS Inspector, and the Style
> Editor. I really think that there needs to be more integration between the
> tools, and as little duplication of effort as possible. When I want to
> develop or tinker with a site, I don't want to first have to think of which
> tools is bested suited to the job: "Should I use the console? But that's not
> as fast as the GCLI. But if I want to save my code, I should use the
> Scratchpad!"
>
This falls squarely on my shoulders to communicate more about. There *is* a
big picture here. I'd rather not muddy this thread with it, but it does
exist.
> I hope I haven't come across as too negative -- I'm really excited by the
> work being done on the devtools, and I think that there are some really good
> ideas coming out.
>
Not negative at all!
Thanks!
Kevin
--
Kevin Dangoor
product manager, developer tools
work: http://mozilla.com/
email: kdan...@mozilla.com <k...@blazingthings.com>
blog: http://www.BlueSkyOnMars.com
Joe Walker
Agreed, and I would add 2 things: We've briefly discussed having some
sort of filtering for the doctor panel, and it may happen, but I think
we need to try it out first.
I also fundamentally disagree with the statement that we should assume
web developers know what they're doing. Specificity/layout/etc may seem
easy when you've been doing it for a while, but the reality is that the
majority of web developers don't understand those in detail.
Joe.
Axel Hecht
interesting stuff.
I'm trying to estimate the scope of this, in particular of CSS Doctor:
How many of those diagnostic messages do you expect?
Asking, of course, with my l10n hat on.
Axel
Joe Walker
That's a good, and hard question.
I'm currently of the opinion that 20-30 is rules (and therefore 20-30
messages) is enough to be useful to many developers, and good enough to
release.
However that won't catch several edge cases, and there will be a long
tail of edge cases that get progressively more obscure as we go, however
I expect that these rules will be filled out over time.
Also note that the CSS Doctor isn't in our goals for this quarter.
Joe.
Nick Fitzgerald
> I think that the assumption with developer tools should always be that
> the developer knows what they're doing: in the example, the developer
> would *know* that the styles in #content don't apply to #inspectedNode.
Good point, but I think we also need to ask how to help people catch
that they meant to have the style apply to the #foobar element, but
accidentally typed #foobra in their stylesheet.
I think using edit distance in a similar way as Norvig's spellchecker
would be a good compromise. We could train it on only the existing ids
and classes on the page. (Panos, we can finally make that code useful!)
http://norvig.com/spell-correct.html
http://blog.astithas.com/2009/08/spell-checking-in-javascript.html
Nick
Joe Walker
> Den 20-07-2011 03:59, Kevin Dangoor skrev:
>> https://people.mozilla.com/~jwalker/css-panels/
>
> But you can give these hints without choosing anything but the
> element, so your mockups of the doctor, which require quite at lot
> more input from the user seems quite strange for this. I cannot even
> think of anything which would require choosing an arbitrary selector
> expect "why didn't this selector match?" and in your mockup your only
> answer seems to be "because it doesn't", which is not quite helpful.
Other hints that require knowledge of the rule in question:
- Some other rule was more specific
- Misspelled property name
- Incorrect property value
- Property in question does not apply to element (e.g. span with width:10px)
- etc
> Your mockup also indicate that Doctor and Inspector are two separate
> interfaces you have to switch between. I don't think that is needed.
> If the doctor is good enough, it could just show ambient information
> where ever it is needed. For example your "inline elements cannot have
> a width property" could automatically be shown next to the width
> property in the Inspector.
I would love to see a mockup that shows the Inspector showing Doctor
hints. So far my attempts to create such a thing have ended up
significantly reducing the usability of the Doctor. The key aim with the
doctor is that something like 5 secs after a page refresh with something
that doesn't work, the user can have advice on how to fix it. I think
that means no hunting around in the Inspector.
>> This actually makes clear something I was wondering about earlier
>> today. I
>> was trying to think of the use case supported by organizing around
>> stylesheet/rules. Personally, I would rather use an editor
>> environment for
>> developing than an inspection environment... and that's the goal we're
>> shooting for.
>
> When I write CSS, I constantly switch between what you call
> "developing" and "inspecting", maybe ten times a minute. If these two
> things were two different interfaces, that would complicate my task
> quite a bit. I think there are good use cases for organizing around
> selectors and for organizing around properties, but you should not
> limit either of those to "developing" or "inspecting".
I think we can help there, our CSS editor isn't shown in this mockup,
but it should allow developing and inspecting (as in looking at the
page) to happen simultaneously - no need to flip at all.
Joe.
Panos Astithas
Hey, that's an idea!
Panos
Jesper Kristensen
> On 20/07/2011 19:18, Jesper Kristensen wrote:
>> Den 20-07-2011 03:59, Kevin Dangoor skrev:
>>> https://people.mozilla.com/~jwalker/css-panels/
>>
>> But you can give these hints without choosing anything but the
>> element, so your mockups of the doctor, which require quite at lot
>> more input from the user seems quite strange for this. I cannot even
>> think of anything which would require choosing an arbitrary selector
>> expect "why didn't this selector match?" and in your mockup your only
>> answer seems to be "because it doesn't", which is not quite helpful.
>
> Other hints that require knowledge of the rule in question:
> - Some other rule was more specific
In this case you only need to look at rules that match, and not all
rules. This seems like exactly the places where the Inspector would show
a property with a line through it, so maybe it could be displayed as a
help tip describing what that line through means.
> - Misspelled property name
That error would be discovered when the page is parsed, and could be
displayed without even choosing an element or a selector. If there are
too many of such errors, I would guess filtering on just the element
would be enough.
> - Incorrect property value
Again detectable as an error directly when the page is parsed.
> - Property in question does not apply to element (e.g. span with
> width:10px)
When you select an element, I would expect this to show next to the
"width"-property in the Inspector. For example your mockup of the
Inspector shows values in gray, which you could change to red in this
case, and show a tooltip when you hover it.
Mockup:
http://i53.tinypic.com/15y9gf4.png
--
Jesper Kristensen
Joe Walker
> Den 20-07-2011 21:29, Joe Walker skrev:
>> On 20/07/2011 19:18, Jesper Kristensen wrote:
>>> Den 20-07-2011 03:59, Kevin Dangoor skrev:
>>>> https://people.mozilla.com/~jwalker/css-panels/
>>>
>>> But you can give these hints without choosing anything but the
>>> element, so your mockups of the doctor, which require quite at lot
>>> more input from the user seems quite strange for this. I cannot even
>>> think of anything which would require choosing an arbitrary selector
>>> expect "why didn't this selector match?" and in your mockup your only
>>> answer seems to be "because it doesn't", which is not quite helpful.
>>
>> Other hints that require knowledge of the rule in question:
>> - Some other rule was more specific
>
> In this case you only need to look at rules that match, and not all
> rules. This seems like exactly the places where the Inspector would
> show a property with a line through it, so maybe it could be displayed
> as a help tip describing what that line through means.
inspector. The inspector will always be able to give you all the answers
that the doctor can give you and more, but what it can't do is to give
you them quickly in plain English.
>> - Property in question does not apply to element (e.g. span with
>> width:10px)
>
> When you select an element, I would expect this to show next to the
> "width"-property in the Inspector. For example your mockup of the
> Inspector shows values in gray, which you could change to red in this
> case, and show a tooltip when you hover it.
> Mockup:
> http://i53.tinypic.com/15y9gf4.png
Thanks for the mockup. It makes sense and it's very clear.
The design of the doctor is to not make you hunt, it just serves up the
solution on a plate. It's all about being easy and fast.
I think there is a problem with the 50% example - the Inspector is
showing the actual style there. As far as I'm aware there can't be
errors in the actual style. Also I'm not sure how you would display
mis-typed selectors with your tweaks to the inspector.
Thanks,
Joe.
Jesper Kristensen
https://people.mozilla.com/~jwalker/css-panels/
> Thanks for the mockup. It makes sense and it's very clear.
> The design of the doctor is to not make you hunt, it just serves up the
> solution on a plate. It's all about being easy and fast.
Maybe it is just the mockups, where it is hard to see how interaction
would work. I would just imagine that it would be quite slow and error
prone if you have to manually "type in your question" as opposed to the
tool automatically finding typical problems and shows them.
> I think there is a problem with the 50% example - the Inspector is
> showing the actual style there. As far as I'm aware there can't be
> errors in the actual style. Also I'm not sure how you would display
> mis-typed selectors with your tweaks to the inspector.
Ok, but even if it shows "125px" it would still be able to know where
that value comes from and highlight it.
Also, it was not clear from the mockups what degree of "actual styles"
you show here. The "matched but overloaded" in the mockup wouldn't be
the actual style, because it is overloaded. I guess I expected the
inspector to show more than just "this is what it ended up like", but
also how it got there.
Joe Walker
> Den 22-07-2011 17:51, Joe Walker skrev:
>
> https://people.mozilla.com/~jwalker/css-panels/
>
>> Thanks for the mockup. It makes sense and it's very clear.
>> The design of the doctor is to not make you hunt, it just serves up the
>> solution on a plate. It's all about being easy and fast.
>
> Maybe it is just the mockups, where it is hard to see how interaction
> would work. I would just imagine that it would be quite slow and error
> prone if you have to manually "type in your question" as opposed to
> the tool automatically finding typical problems and shows them.
currently we've got the errors that pop-up in the web console, so this
isn't top priority.
It's only 3 clicks to navigate to the rule in question, so I don't this
as long winded, and it's sure to give you the answer. The inspector
isn't sure to give you the answer in an easy way.
>> I think there is a problem with the 50% example - the Inspector is
>> showing the actual style there. As far as I'm aware there can't be
>> errors in the actual style. Also I'm not sure how you would display
>> mis-typed selectors with your tweaks to the inspector.
>
> Ok, but even if it shows "125px" it would still be able to know where
> that value comes from and highlight it.
>
> Also, it was not clear from the mockups what degree of "actual styles"
> you show here. The "matched but overloaded" in the mockup wouldn't be
> the actual style, because it is overloaded. I guess I expected the
> inspector to show more than just "this is what it ended up like", but
> also how it got there.
It does show you how you got there if you open the property up.
Unexpanded, it's like computed styles. Expanded you get to find out how
the browser got to where it is.
There are 2 points of contention. One is easily solved, the other is
open to debate:
- Can/should we do this with tooltips? I think that tooltips are not
obvious enough, and would be slow because the would need to be computed
ahead of time, and this might not always be cheap. This could easily be
solved with a "Why didn't it work" button.
- I contend that navigation to the rule (as in the doctor view) is a
more natural, faster, and simpler thing for the beginner to do. This may
not be true - we'll need to play to be sure. When we begin development
in earnest we'll need to evaluate both options more.
Thanks for the feedback.
Joe.
Kevin Dangoor
> There are 2 points of contention. One is easily solved, the other is open to debate:
> - Can/should we do this with tooltips? I think that tooltips are not obvious enough, and would be slow because the would need to be computed ahead of time, and this might not always be cheap. This could easily be solved with a "Why didn't it work" button.
> - I contend that navigation to the rule (as in the doctor view) is a more natural, faster, and simpler thing for the beginner to do. This may not be true - we'll need to play to be sure. When we begin development in earnest we'll need to evaluate both options more.
> Thanks for the feedback.
This discussion brought something to mind... So far, everything I've seen of the CSS Doctor has fallen into two categories:
1. selector didn't match or rule was overridden by another
2. some error in the CSS
Are there others?
If not, perhaps the Doctor is not the tool we're hunting for. Maybe what we need is the errors pane and some sort of tool (possibly designed just like the Doctor, possibly something with a different shape) that helps with selectors specifically.
Kevin
--
Kevin Dangoor
product manager, developer tools
work: http://mozilla.com/
blog: http://blueskyonmars.com/
@dangoor
Mike Shaver
> If not, perhaps the Doctor is not the tool we're hunting for. Maybe what we need is the errors pane and some sort of tool (possibly designed just like the Doctor, possibly something with a different shape) that helps with selectors specifically.
My CSS "WTF RAGE FFFFFUUUUUU" moments are almost all of this form:
* that thing is in the wrong place (too indented, not indented enough,
too narrow, too wide, not aligned with something else)
* what rules make it be there?
* change a rule
* doesn't move, or moves too far, because of some fragile interactions
with other rules
* WTF RAGE FFFFFFFUUUUUU
If I had a CSS Doctor (like a version of Eric Meyer that fit in my
pocket), I would want it to help me understand all the rules that
affect it cumulatively (like, padding from the containing element) and
then destroy them. I mean, make them better.
Mike
Joe Walker
> On Jul 22, 2011, at 4:53 PM, Joe Walker wrote:
>
>> There are 2 points of contention. One is easily solved, the other is
>> open to debate:
>> - Can/should we do this with tooltips? I think that tooltips are not
>> obvious enough, and would be slow because the would need to be
>> computed ahead of time, and this might not always be cheap. This
>> could easily be solved with a "Why didn't it work" button.
>> - I contend that navigation to the rule (as in the doctor view) is a
>> more natural, faster, and simpler thing for the beginner to do. This
>> may not be true - we'll need to play to be sure. When we begin
>> development in earnest we'll need to evaluate both options more.
>> Thanks for the feedback.
>
>
> This discussion brought something to mind... So far, everything I've
> seen of the CSS Doctor has fallen into two categories:
>
> 1. selector didn't match or rule was overridden by another
> 2. some error in the CSS
>
> Are there others?
>
> what we need is the errors pane and some sort of tool (possibly
> designed just like the Doctor, possibly something with a different
> shape) that helps with selectors specifically.
Some CSS errors are contextual:
.foo { width:10%; } is just fine for a div but not for a span.
And you can't just lay those out without reference to an element.
The motivation for the doctor was going over and over how to display
specificity information in the inspector, and not coming up with a UI
that was simple enough, so I don't think that taking CSS 'errors' out of
the picture will solve the problem.
Joe.
Axel Hecht
>
> That's a good, and hard question.
> I'm currently of the opinion that 20-30 is rules (and therefore 20-30
> messages) is enough to be useful to many developers, and good enough to
> release.
> However that won't catch several edge cases, and there will be a long
> tail of edge cases that get progressively more obscure as we go, however
> I expect that these rules will be filled out over time.
> Also note that the CSS Doctor isn't in our goals for this quarter.
I wonder if this would be better served as an add-on, with an integrated
install experience.
It seems to target a few million people, and shipping it to 400 million
to get to that distribution sounds not necessary?
Also, from an l10n point of view, this is gonna be tough, and I doubt
it's going to be right to translate this into 100 languages, as most of
those won't have a CSS ecosystem to support people in learning more
about what they see. Developing this externally from the main product
would make it a lot easier to have people with special interests in CSS
in their language to participate in this particular feature.
Axel
Joe Walker
> On 20.07.11 20:18, Joe Walker wrote:
>>
>> That's a good, and hard question.
>> I'm currently of the opinion that 20-30 is rules (and therefore 20-30
>> messages) is enough to be useful to many developers, and good enough to
>> release.
>> However that won't catch several edge cases, and there will be a long
>> tail of edge cases that get progressively more obscure as we go, however
>> I expect that these rules will be filled out over time.
>> Also note that the CSS Doctor isn't in our goals for this quarter.
>
> I wonder if this would be better served as an add-on, with an
> integrated install experience.
>
> It seems to target a few million people, and shipping it to 400
> million to get to that distribution sounds not necessary?
I'd like to avoid discussion of distribution mechanism in this context
(i.e. something that's not in our goals for the quarter) because we've
got to answer the 80/20/2 question for developer tools in general in the
light of a wider goal of baking something like firebug into firefox, and
the security constraints of avoiding devtools becoming a conduit for
social engineering attacks.
In short - good question, but lets ask it of devtools in general first.
> Also, from an l10n point of view, this is gonna be tough, and I doubt
> it's going to be right to translate this into 100 languages, as most
> of those won't have a CSS ecosystem to support people in learning more
> about what they see. Developing this externally from the main product
> would make it a lot easier to have people with special interests in
> CSS in their language to participate in this particular feature.
This is an interesting point - how do we decide how far to go with l10n
of developer tools? While not ideal, it does seem to be true that there
are some reasons for developer tools to have slightly different rules
than the rest of Firefox:
- The % of Firefox users that are web developers is something like 10%
(based on FB installs??)
- Firebug is localized into 34 locales (i.e. 30% of Firefox)
- MDN CSS documentation is localized into between 2 and 11 locales
depending on the section
Maybe we should define a smaller set of locales that we say we need to
get done, and accept others if/when they are ready?
Joe.
Axel Hecht
> On 26/07/2011 12:55, Axel Hecht wrote:
>> On 20.07.11 20:18, Joe Walker wrote:
>>>
>>> That's a good, and hard question.
>>> I'm currently of the opinion that 20-30 is rules (and therefore 20-30
>>> messages) is enough to be useful to many developers, and good enough to
>>> release.
>>> However that won't catch several edge cases, and there will be a long
>>> tail of edge cases that get progressively more obscure as we go, however
>>> I expect that these rules will be filled out over time.
>>> Also note that the CSS Doctor isn't in our goals for this quarter.
>>
>> I wonder if this would be better served as an add-on, with an
>> integrated install experience.
>>
>> It seems to target a few million people, and shipping it to 400
>> million to get to that distribution sounds not necessary?
>
> I'd like to avoid discussion of distribution mechanism in this context
> (i.e. something that's not in our goals for the quarter) because we've
> got to answer the 80/20/2 question for developer tools in general in the
> light of a wider goal of baking something like firebug into firefox, and
> the security constraints of avoiding devtools becoming a conduit for
> social engineering attacks.
>
> In short - good question, but lets ask it of devtools in general first.
Mind opening up that thread? I'd do it, but I don't understand your
wording on what you've set up as context.
>> Also, from an l10n point of view, this is gonna be tough, and I doubt
>> it's going to be right to translate this into 100 languages, as most
>> of those won't have a CSS ecosystem to support people in learning more
>> about what they see. Developing this externally from the main product
>> would make it a lot easier to have people with special interests in
>> CSS in their language to participate in this particular feature.
>
> This is an interesting point - how do we decide how far to go with l10n
> of developer tools? While not ideal, it does seem to be true that there
> are some reasons for developer tools to have slightly different rules
> than the rest of Firefox:
> - The % of Firefox users that are web developers is something like 10%
> (based on FB installs??)
> - Firebug is localized into 34 locales (i.e. 30% of Firefox)
> - MDN CSS documentation is localized into between 2 and 11 locales
> depending on the section
>
> Maybe we should define a smaller set of locales that we say we need to
> get done, and accept others if/when they are ready?
For stuff in-product, we have only very limited tools. We could probably
use the "reporting" logic we had for Lorentz, i.e., report the strings,
but not as red but just as yellow, but that's not really anywhere close
to "let's put a feature into a bucket and have a distinct set of locales
working on such a feature only". Sounds like a discussion to have after
the global question above.
Axel
Kevin Dangoor
> On Mon, Jul 25, 2011 at 1:36 PM, Kevin Dangoor <kdan...@mozilla.com> wrote:
>> If not, perhaps the Doctor is not the tool we're hunting for. Maybe what we need is the errors pane and some sort of tool (possibly designed just like the Doctor, possibly something with a different shape) that helps with selectors specifically.
>
> My CSS "WTF RAGE FFFFFUUUUUU" moments are almost all of this form:
>
> * that thing is in the wrong place (too indented, not indented enough,
> too narrow, too wide, not aligned with something else)
Excellent point, because I find myself in this position a lot, too. The way you expressed it is good as well, because layout problems seem like they're not just a case of "why didn't this property/value get applied properly" because it's not clear what "properly" means. Saying "this is too wide" is much clearer.
When Joe was first talking about the CSS Doctor, he had called out layout as a separate set of concerns, likely for this very reason. I agree that they're a very important use case, because they trip people up quite a bit. As much as I love flexbox, there are times when I find myself scratching my head over why an element ends up where it does)
Kevin
--
Kevin Dangoor
product manager, developer tools
work: http://mozilla.com/
blog: http://blueskyonmars.com/
@dangoor
Kevin Dangoor
> Some CSS errors are contextual:
> .foo { width:10%; } is just fine for a div but not for a span.
> And you can't just lay those out without reference to an element.
>
That's a good point.
> The motivation for the doctor was going over and over how to display specificity information in the inspector, and not coming up with a UI that was simple enough, so I don't think that taking CSS 'errors' out of the picture will solve the problem.
The point was more about CSS errors being the kind of thing that should be more visible (as in your mockups, where you have a tab for them) and that if selectors were the only other real issue then perhaps a different UI is warranted. For example, I have seen tools designed to help you create a selector that gets the right nodes.
That said, your point about things like width on inline elements and Shaver's point about layout problems does point to a solution that involves getting ahold of the node first.
Kevin
--
Kevin Dangoor
product manager, developer tools
work: http://mozilla.com/
blog: http://blueskyonmars.com/
@dangoor
Joe Walker
Short answer:
Yes. It would be awesome if we could integrate layout understanding into
the highlighter, so it could show you not only the box model, but also
the parent to which it is absolutely positioned or the baseline along
which it flows, etc.
Long answer:
The CSS Doctor is good at answering questions of the form 'why didn't
this rule do what i wanted?', but not good at answering 'why is this
like that?'
The latter question is a better question to answer because it gives you
general knowledge of how the web works than a point solution to a
problem. However:
- What the developer actually wanted there and then is a point solution, and
- Point solutions can lead to MDN articles with general knowledge
Also the various answers to the question 'why is this like that?' are
very different, and I've not come up with a way of tacking it except for
specific cases. The most obvious and important being layout, and the
highlighter could be an excellent start point.
Joe.
Kevin Dangoor
> Short answer:
> Yes. It would be awesome if we could integrate layout understanding into the highlighter, so it could show you not only the box model, but also the parent to which it is absolutely positioned or the baseline along which it flows, etc.
>
> Long answer:
> The CSS Doctor is good at answering questions of the form 'why didn't this rule do what i wanted?', but not good at answering 'why is this like that?'
> The latter question is a better question to answer because it gives you general knowledge of how the web works than a point solution to a problem. However:
> - What the developer actually wanted there and then is a point solution, and
> - Point solutions can lead to MDN articles with general knowledge
> Also the various answers to the question 'why is this like that?' are very different, and I've not come up with a way of tacking it except for specific cases. The most obvious and important being layout, and the highlighter could be an excellent start point.
You may be right that the Highlighter is the best tool for dealing with layout issues. If we can extend ti to give us all of the numbers that went into making a given node 100px wide, for example, that would likely be almost as good as asking the Doctor why a node was too narrow.
It may be possible for the Doctor to answer questions of the "why is this too narrow?" form, but I can see how it may not always be possible to come up with answers there.
Kevin
--
Kevin Dangoor
product manager, developer tools
work: http://mozilla.com/
blog: http://blueskyonmars.com/
@dangoor
Joe Walker
> On 26.07.11 14:49, Joe Walker wrote:
>> I'd like to avoid discussion of distribution mechanism in this context
>> (i.e. something that's not in our goals for the quarter) because we've
>> got to answer the 80/20/2 question for developer tools in general in the
>> light of a wider goal of baking something like firebug into firefox, and
>> the security constraints of avoiding devtools becoming a conduit for
>> social engineering attacks.
>>
>> In short - good question, but lets ask it of devtools in general first.
>
> Mind opening up that thread? I'd do it, but I don't understand your
> wording on what you've set up as context.
Talking it through a bit, I've been perhaps less sure of my opinions
than I should be.
- Devtools is 2%. (as defined by limi's UX work, but in short it means
the user doesn't see it by default, but they get easy access to it if
they want)
- However it is a privileged 2% - it is going to be built in.
I guess you can look at devtools as an add-on that is very quick to
download.
It's possible that something will change or even that I'm (shock horror)
wrong. However, I do want to get to the l10n discussion, and don't think
we should get sidetracked by UX or delivery issues.
>>> Also, from an l10n point of view, this is gonna be tough, and I doubt
>>> it's going to be right to translate this into 100 languages, as most
>>> of those won't have a CSS ecosystem to support people in learning more
>>> about what they see. Developing this externally from the main product
>>> would make it a lot easier to have people with special interests in
>>> CSS in their language to participate in this particular feature.
>>
>> This is an interesting point - how do we decide how far to go with l10n
>> of developer tools? While not ideal, it does seem to be true that there
>> are some reasons for developer tools to have slightly different rules
>> than the rest of Firefox:
>> - The % of Firefox users that are web developers is something like 10%
>> (based on FB installs??)
>> - Firebug is localized into 34 locales (i.e. 30% of Firefox)
>> - MDN CSS documentation is localized into between 2 and 11 locales
>> depending on the section
>>
>> Maybe we should define a smaller set of locales that we say we need to
>> get done, and accept others if/when they are ready?
>
> For stuff in-product, we have only very limited tools. We could
> probably use the "reporting" logic we had for Lorentz, i.e., report
> the strings, but not as red but just as yellow, but that's not really
> anywhere close to "let's put a feature into a bucket and have a
> distinct set of locales working on such a feature only". Sounds like a
> discussion to have after the global question above.
So, if I'm understanding you properly, the 2 options open to us seem to be:
- force 100% localization of all devtools
- allow localization of devtools strings but don't block release on
missing strings
And that the 3rd option of:
- force localization of some locales, but not all
isn't an option.
It seems to me that we've already accepted (given the examples above)
that devtools don't need 100% localization, (and probably can't have
100% localization?), so the only option is to not block on missing strings.
It's not my preferred option, but maybe we've got no choice?
Joe.
Axel Hecht
> On 26/07/2011 15:01, Axel Hecht wrote:
>> On 26.07.11 14:49, Joe Walker wrote:
>>> ...
>>> I'd like to avoid discussion of distribution mechanism in this context
>>> (i.e. something that's not in our goals for the quarter) because we've
>>> got to answer the 80/20/2 question for developer tools in general in the
>>> light of a wider goal of baking something like firebug into firefox, and
>>> the security constraints of avoiding devtools becoming a conduit for
>>> social engineering attacks.
>>>
>>> In short - good question, but lets ask it of devtools in general first.
>>
>> Mind opening up that thread? I'd do it, but I don't understand your
>> wording on what you've set up as context.
>
> Talking it through a bit, I've been perhaps less sure of my opinions
> than I should be.
> - Devtools is 2%. (as defined by limi's UX work, but in short it means
> the user doesn't see it by default, but they get easy access to it if
> they want)
> - However it is a privileged 2% - it is going to be built in.
>
> I guess you can look at devtools as an add-on that is very quick to
> download.
From an l10n POV, I can not, you just ruled that one out.
> It's possible that something will change or even that I'm (shock horror)
> wrong. However, I do want to get to the l10n discussion, and don't think
> we should get sidetracked by UX or delivery issues.
It's sad that this is not a discussion involving all parties but just
dumped on folks.
What you're describing as options are requests for enhancements on our
l10n infrastructure. Those won't come lightly, nor quick.
You should also include a 4th option into your thinking, not the least
likely in my experience:
- your feature is going to look crappy in some localizations.
I can't deny taking a 100 great strings in prime Firefox UI for
something awkward in devtools. There's actually a current example of
this, the DOM Attr node deprecation notices. I didn't understand the
en-US text, many localizers didn't. And the resulting messages are all
over, some being great and right, some saying that ".parentNode
shouldn't be used" (not restricting that to attribute nodes), some
probably just wrong. And there's nothing we can do about it.
Axel
Boris Zbarsky
> And there's nothing we can do about it.
We can either fix the en-US wording to be clearer (if our localizers
don't get it, why would web developers?) or file bugs on locales with
bad translations. Or both.
-Boris
Axel Hecht
> On 8/1/11 10:30 AM, Axel Hecht wrote:
>> And there's nothing we can do about it.
>
> We can either fix the en-US wording to be clearer (if our localizers
> don't get it, why would web developers?)
We could have done something about the en-US strings back when the patch
initially landed and the localizers complained,
https://bugzilla.mozilla.org/show_bug.cgi?id=661327. Given that that bug
doesn't say what it's doing, nor the bug it's blocking,
https://bugzilla.mozilla.org/show_bug.cgi?id=611787, really does, I had
to go to the w3c draft it links to to finally make some sense out of the
bug. Oh, the patch doesn't have tests either which one could reverse
engineer.
Anyway, the strings are now frozen, for a while now, so we can't change
them anymore.
> or file bugs on locales with
> bad translations. Or both.
I can read enough of Dutch to know that we have a problem, and if I had
a German localization to review, I'd probably realize something, and
perhaps nag.
But for most of our languages, I can't even read the script, let alone
understand if the translation is good or not.
No, we, as in I, can't do anything about those translations being bad.
And I don't think that's worse than any other localization problem they
may or may not have.
Axel
Ron Hunter
The biggest problem with localization is that some languages just don't
have the words to express some technical concepts. That is why machine
translation is often so misleading.
Boris Zbarsky
> We could have done something about the en-US strings back when the patch
> initially landed and the localizers complained,
> https://bugzilla.mozilla.org/show_bug.cgi?id=661327.
It seems that it wasn't clear how serious this problem was..
> Anyway, the strings are now frozen, for a while now, so we can't change
> them anymore.
For fx6, right? We can do it for Fx8!
-Boris
Axel Hecht
If we want to change them, we should probably change them a good deal. I
saw a few of those today in the error console, and they're hardly
constructive. My example was a page of the l10n dashboard, and it says
"this page uses getAttributeNode", no indication of where, and which of
the handful of external libraries could be the one to change.
Anywho, derailing this particular thread on to this particular bug.
The takeaway for this subthread is much more that for devtools, you
shouldn't rely on the localizers that do Firefox to understand the specs
and rationales of the web technologies involved, and that there's no
project management to help that.
Axel
Joe Walker
>> So, if I'm understanding you properly, the 2 options open to us seem
>> to be:
>> - force 100% localization of all devtools
>> - allow localization of devtools strings but don't block release on
>> missing strings
>>
>> And that the 3rd option of:
>> - force localization of some locales, but not all
>> isn't an option.
>>
>> It seems to me that we've already accepted (given the examples above)
>> that devtools don't need 100% localization, (and probably can't have
>> 100% localization?), so the only option is to not block on missing
>> strings.
>> It's not my preferred option, but maybe we've got no choice?
>
> What you're describing as options are requests for enhancements on our
> l10n infrastructure. Those won't come lightly, nor quick.
So how should we proceed? Should I raise a bug?
> You should also include a 4th option into your thinking, not the least
> likely in my experience:
>
> - your feature is going to look crappy in some localizations.
I think this is your opinion of the 3rd option? Do you know of any more
practical alternative suggestions?
> I can't deny taking a 100 great strings in prime Firefox UI for
> something awkward in devtools. There's actually a current example of
> this, the DOM Attr node deprecation notices. I didn't understand the
> en-US text, many localizers didn't. And the resulting messages are all
> over, some being great and right, some saying that ".parentNode
> shouldn't be used" (not restricting that to attribute nodes), some
> probably just wrong. And there's nothing we can do about it.
From what I can see of tools in the same space:
- Chrome: No l10n for devtools
- Safari: No l10n for devtools
- Opera: No l10n for devtools
- Firefox / Firebug: Uses optional l10n to get 34 partial translations
without reports of crappy translations
I do want to hear positive suggestions about how to push the envelope
further.
Joe.
Joe Walker
> ...
> The takeaway for this subthread is much more that for devtools, you
> shouldn't rely on the localizers that do Firefox to understand the
> specs and rationales of the web technologies involved, and that
> there's no project management to help that.
So can we put this advice a positive way, so there's something we can do?
Should we have a flag or simply a note in the string description to
localizers not to attempt translation unless they understand the tech?
Joe.
Joe Walker
> - Opera: No l10n for devtools
Mihai just corrected me - Dragonfly does have l10n, just using a
separate config option to the main Opera language option. Apparently
they both sync to the OS language.
Joe.
Axel Hecht
My constructive comment would have been to go for an addon. That's the
existing architecture we have to ship independently localized UI.
As long as you're in the main Firefox l10n infra, having your
localizable strings in separate files, maybe in a purposed directory,
makes them easy to mark as ignore or keep as English on a social level.
On a technical level, creating something new for devtools is something I
need to put into perspective:
You mentioned 2% as the developer share. Of those, at least 50% use
en-US, probably much higher. I don't think I invest right if I invest in
to some special purpose process to deal with potential issues for a
per-locale-fraction of 1% of our ADUs.
Any work the l10n team does to help this is likely going to be around
generally making it easier for localization leads to take contributions
from other volunteers in general, and maybe, if that works for the rest
of firefox, prioritization of strings in general. But that's driven from
making new localizations easier.
Axel
Rob Campbell
On 2011-08-02, at 09:46 , Axel Hecht wrote:
>
> My constructive comment would have been to go for an addon. That's the existing architecture we have to ship independently localized UI.
That's not what we're trying to do here. "Integrated" means integrated.
> As long as you're in the main Firefox l10n infra, having your localizable strings in separate files, maybe in a purposed directory, makes them easy to mark as ignore or keep as English on a social level.
OK, this is kind of what we were hoping to hear. We have a browser/devtools directory now and can put devtools-specific strings into a locales subdirectory there (for things that live in browser, at least).
> On a technical level, creating something new for devtools is something I need to put into perspective:
>
> You mentioned 2% as the developer share. Of those, at least 50% use en-US, probably much higher. I don't think I invest right if I invest in to some special purpose process to deal with potential issues for a per-locale-fraction of 1% of our ADUs.
I'm not sure about that. I'd love to see some actual numbers around localized developer tools. I know that Firebug is a very well-translated add-on and we've had requests to make it possible to use localized builds of Firebug on different localizations of Firefox -- usually due to perceived quality issues of one localization or the other.
I think there is real demand for developer tools running in people's native languages.
> Any work the l10n team does to help this is likely going to be around generally making it easier for localization leads to take contributions from other volunteers in general, and maybe, if that works for the rest of firefox, prioritization of strings in general. But that's driven from making new localizations easier.
Our available localizations are a great feature of Firefox and we should always remember that. I don't want our devtools to be a hindrance there.
BUT! I also don't want to be held back because we can't figure out how to localize a particular string. We'll need work with l10n to get as much feedback about our strings as we can.
I think the way we localized and named the Scratchpad was a great example of how we could accomplish this.
~ rob
Ron Hunter
than is feasible. I don't see any good solution for this.
Robert Kaiser
> You mentioned 2% as the developer share. Of those, at least 50% use
> en-US, probably much higher. I don't think I invest right if I invest in
> to some special purpose process to deal with potential issues for a
> per-locale-fraction of 1% of our ADUs.
Given that almost all tradition development tools (not necessarily
talking web here) and a number of web development resources (like
selfhtml) are available in or even written in German, I'd really think
it would make us be a bad development help in German-speaking countries
if devtools were _not_ localized in German.
Things differ for other languages, of course, I think French probably
has a similar story to German, though.
Robert Kaiser
--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community should think about. And most of the
time, I even appreciate irony and fun! :)
Axel Hecht
> On 2011-08-02, at 09:46 , Axel Hecht wrote:
>> My constructive comment would have been to go for an addon. That's the existing architecture we have to ship independently localized UI.
> That's not what we're trying to do here. "Integrated" means integrated.
>> As long as you're in the main Firefox l10n infra, having your localizable strings in separate files, maybe in a purposed directory, makes them easy to mark as ignore or keep as English on a social level.
> OK, this is kind of what we were hoping to hear. We have a browser/devtools directory now and can put devtools-specific strings into a locales subdirectory there (for things that live in browser, at least).
browser/locales/en-US/chrome/devtools than
browser/devtools/locales/en-US, the latter is a much more involved patch
with makefile changes and different l10n.inis for different branches and
all that. From the social contracts pov, they're equivalent.
>> On a technical level, creating something new for devtools is something I need to put into perspective:
>>
>> You mentioned 2% as the developer share. Of those, at least 50% use en-US, probably much higher. I don't think I invest right if I invest in to some special purpose process to deal with potential issues for a per-locale-fraction of 1% of our ADUs.
> I'm not sure about that. I'd love to see some actual numbers around localized developer tools. I know that Firebug is a very well-translated add-on and we've had requests to make it possible to use localized builds of Firebug on different localizations of Firefox -- usually due to perceived quality issues of one localization or the other.
>
> I think there is real demand for developer tools running in people's native languages.
languages themselves are only single-digit % shares of our ADUs among
our end-user audience. For the things that the l10n team can do, and how
many people that impacts, devtools with a share of a share quickly falls
below the fold.
>> Any work the l10n team does to help this is likely going to be around generally making it easier for localization leads to take contributions from other volunteers in general, and maybe, if that works for the rest of firefox, prioritization of strings in general. But that's driven from making new localizations easier.
> Our available localizations are a great feature of Firefox and we should always remember that. I don't want our devtools to be a hindrance there.
>
> BUT! I also don't want to be held back because we can't figure out how to localize a particular string. We'll need work with l10n to get as much feedback about our strings as we can.
>
> I think the way we localized and named the Scratchpad was a great example of how we could accomplish this.
>
here. You can haz the Firefox localizers and their input, nothing wrong
with that.
OTH, I want to set the expectations right on where the l10n team is
going to put its efforts to improve our l10n ecosystem, and given the
vast areas where we can improve, devtools will benefit from things
getting better, but I don't expect it to change what we do.
Axel
Dr J R Stockton
zilla.org>, Mon, 1 Aug 2011 17:29:37, Axel Hecht <l1...@mozilla.com>
posted:
>
>I can read enough of Dutch to know that we have a problem, and if I had
>a German localization to review, I'd probably realize something, and
>perhaps nag.
>
>But for most of our languages, I can't even read the script, let alone
>understand if the translation is good or not.
>
>No, we, as in I, can't do anything about those translations being bad.
>And I don't think that's worse than any other localization problem they
>may or may not have.
If the total message-size is a small proportion of the size of Firefox,
why not install messages both in the desired local demotic and in the
original English and provide a means whereby the English of the current
message can easily be seen in parallel with the demotic if desired
(tool-tip? HTML title?)? After all, many who prefer a strange language
have some understanding of English, or have friends/family/colleagues
who do.
Moreover, some will tell you if the translation is bad.
--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05.
Website <http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
PAS EXE etc. : <http://www.merlyn.demon.co.uk/programs/> - see in 00index.htm
Dates - miscdate.htm estrdate.htm js-dates.htm pas-time.htm critdate.htm etc.