Re: Fw: how firebug handles html boolean attributes... also
Kyle Simpson
>>> say in markup just `disabled` or `disabled="disabled"`, and that all
>>> other variations are considered incorrect. So it seems a little
>>> strange to me that Firebug is representing the attribute as an empty
>>> string value.
>
> FWIW, this is wrong. `disabled=""` is just as correct as `disabled` or
> `disabled=disabled`. (This is a direct result of the fact that this
> requirement is written in terms of the DOM, which, as you noticed,
> doesn't differentiate between the first two cases.)
Ok, fine, so saying `disabled=""` is permissable in the original markup. But
the spirit of my question is really if dev-tools in a DOM view should
represent a boolean variable on a DOM element like `disabled`,
`disabled=true`, `disabled=""`, `disabled="disabled"`, or some other
variation?
I would posit that no matter how one gets to the fact that they've specified
a boolean flag attribute (whatever the original markup looks like), the most
concise and proper representation of that boolean attribute in the DOM view
of dev-tools would be to say just `disabled`, as no other value that you
enter for that attribute will have any meaning. If the value has no meaning
(it's merely the presence of the attribute that's relevant) then is there
any reason to show (or allow editing of) the value at all? I submit there is
not. But I was hoping to see if there was some other use-case or reason for
that which I was not aware of.
> Note that, for example, <img src=spacer.gif alt> would be correct as
> well, and is equivalent to <img src=spacer.gif alt="">. Would you like
> the DOM to tell you the former is a boolean attribute as well?
As far as I'm aware, the nature of a property being a special boolean
attribute type has nothing to do with (ie, isn't determined by) whether or
how there is a value specified in the original markup. `alt` should never be
represented as a boolean attribute because, in fact, it's not a boolean
attribute. OTOH, `disabled`, for any node which allows/defines the
`disabled` attribute as in fact a boolean attribute, should always represent
itself as a boolean attribute, and not merely as a non-special attribute
that has an empty/non-editable value.
In other words, I'm suggesting that dev-tools should make a distinction in
how it represents (and allows interaction with) a boolean attribute vs. a
regular string value attribute. Namely, that the value for a boolean
attribute is irrelevant, and should thus be suppressed from display, to
reduce visual clutter.
Now, the question remains, how (if any) can one decipher that an attribute
you are working with in the `attributes` collection of a DOM element is, in
fact, interpreted (by the parent element) as a special boolean attribute? It
doesn't appear that the DOM API exposes that distinction (though clearly
internally it treats boolean attributes with special behavior compared to
just normal attributes). If not, why doesn't it? And wouldn't it be useful
if it did? And is this a shortcoming of the spec, or is it merely a small
implementation detail that we could consider addressing?
The case for why this is useful goes to my original question/point, which is
that it would allow dev-tools to make such a distinction, which I think
would make interacting with such attributes a little cleaner (removing the
clutter of unnecessary empty string values).
--Kyle
Mike Shaver
> I would posit that no matter how one gets to the fact that they've specified
> a boolean flag attribute (whatever the original markup looks like), the most
> concise and proper representation of that boolean attribute in the DOM view
> of dev-tools would be to say just `disabled`, as no other value that you
> enter for that attribute will have any meaning. If the value has no meaning
> (it's merely the presence of the attribute that's relevant) then is there
> any reason to show (or allow editing of) the value at all? I submit there is
> not. But I was hoping to see if there was some other use-case or reason for
> that which I was not aware of.
The value of the attribute, not just its presence, can be detected and
manipulated from script:
>> document.forms[0].elements[0].disabled
false
>> document.forms[0].elements[0].getAttribute("disabled")
null
>> document.forms[0].elements[0].setAttribute("disabled", "orange")
undefined
>> document.forms[0].elements[0].disabled
true
>> document.forms[0].elements[0].getAttribute("disabled")
"orange"
In my younger years, I had been known to put things like "by-user" or
"by-mode" in boolean attrs to carry state. Maybe not a good idea, but
here we are.
Mike
Henri Sivonen
> Ok, fine, so saying `disabled=""` is permissable in the original markup. But the spirit of my question is really if dev-tools in a DOM view should represent a boolean variable on a DOM element like `disabled`, `disabled=true`, `disabled=""`, `disabled="disabled"`, or some other variation?
I think dev tools should show the user what's in the DOM without trying to present boolean attributes any differently from other attributes, since parsing boolean attributes works exactly the same way as parsing normal attributes and the DOM Core representation of boolean attributes is exactly the same as the representation of normal attributes. I think making dev tools show boolean attributes differently from others would create more confusion than it would solve.
So I think dev tools should show `disabled=""` if the markup said `disabled` or `disabled=""` and should show `disabled="disabled"` if the markup said `disabled=disabled` or `disabled="disabled"`. If the markup said something invalid like `disabled="true"`, then dev tools should show `disabled="true"`, since that's what's in the DOM in that case.
Furthermore, the disabled="disabled" variation shouldn't be promoted in any way. It's more characters to type and the only thing it helps with is pretending that HTML is SGML which it isn't.
--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/
Boris Zbarsky
> I would posit that no matter how one gets to the fact that they've
> specified a boolean flag attribute (whatever the original markup looks
> like), the most concise and proper representation of that boolean
> attribute in the DOM view of dev-tools would be to say just `disabled`,
> as no other value that you enter for that attribute will have any
> meaning.
This last claim is false. While the only thing that matters for the
disabled _state_ is whether the attribute is present, the string value
of the attribute matters for other things (e.g. getAttribute, attribute
selector matching, and so forth).
So what the dev tool should show depends on what information the author
is looking for.
> In other words, I'm suggesting that dev-tools should make a distinction
> in how it represents (and allows interaction with) a boolean attribute
> vs. a regular string value attribute.
One issue is you think that attributes are either one or the other. The
problem is that all attributes are always string attributes. Boolean
attributes have an additional semantic behavior on top of that. The
question is not _which_ behavior to expose but how to expose _both_
behaviors, no?
> Now, the question remains, how (if any) can one decipher that an
> attribute you are working with in the `attributes` collection of a DOM
> element is, in fact, interpreted (by the parent element) as a special
> boolean attribute?
By hardcoding the list, at the moment.
> It doesn't appear that the DOM API exposes that
> distinction
It's not a "distinction". It's just additional behavior.... E.g. the
"disabled" attribute on <input> is special, just like the "style"
attribute on HTML elements is special.
> If not, why doesn't it?
See above? Of course one could add API for this additional behavior.
> And wouldn't it be useful if it did?
To whom?
> And is this a shortcoming of the spec
If you want new DOM API, it needs to be specced, yes.
> The case for why this is useful goes to my original question/point,
> which is that it would allow dev-tools to make such a distinction
dev-tools can just hardcode a list; it's really not that big a deal.
But again, how would it use the list given the information above?
-Boris
johnjbarton
> On Jun 4, 2011, at 20:23, Kyle Simpson wrote:
>> Ok, fine, so saying `disabled=""` is permissable in the original markup. But the spirit of my question is really if dev-tools in a DOM view should represent a boolean variable on a DOM element like `disabled`, `disabled=true`, `disabled=""`, `disabled="disabled"`, or some other variation?
The real question here: should the Firefox API be extended to
distinguish boolean HTML attributes from string attributes. Based on
what we know, the answer should be Yes. I'll give two reasons: 1)
because devs want to see boolean attributes as booleans and 2) because
displaying boolean attributes as strings is misleading.
>
> I think dev tools should show the user what's in the DOM without trying to present boolean attributes any differently from other attributes, since parsing boolean attributes works exactly the same way as parsing normal attributes and the DOM Core representation of boolean attributes is exactly the same as the representation of normal attributes. I think making dev tools show boolean attributes differently from others would create more confusion than it would solve.
Development tools can present the DOM in many ways. Firebug shows the
DOM elements as decompiled source: it creates fake markup from the DOM
API. This is very effective: it presents the live result of parsing in
the same language a developer could have used to create that result.
Whenever more than one source string creates the same DOM element, the
decompiled result can differ from what the developer might have used. In
such cases the development tool will have to choose how to decompile. No
matter what choice is made, some developers will be surprised because
the source will not look like they would have written it. For example,
decompiling to |disabled=""| will surprise devs who typically write
|disabled|.
The choice that development tools use will have a cultural effect and
vice versa: developers will tend to adopt the same solution in their
code and tools try to mimic devs. I believe that Kyle is trying to say
that the DOM API should allow distinguishing boolean attributes so that
the decompiled code can display them in the culturally accepted way,
|disabled|. This is the first reason for support to detect booleans.
>
> So I think dev tools should show `disabled=""` if the markup said `disabled` or `disabled=""`
Certainly for Firebug and I guess for most Web development tools these
days parsing the markup is not a practical option. Parsing HTML is a
full time job for experts. So: we don't know what the markup said.
Moreover, even if we could parse it, JavaScript probably walked on it in
the meantime. Consequently there is no option that starts "if the
markup said".
> Furthermore, the disabled="disabled" variation shouldn't be promoted in any way. It's more characters to type and the only thing it helps with is pretending that HTML is SGML which it isn't.
So why should we promote |disabled=""|? Worse than number of characters
it creates confusion: it displays a boolean attribute as if it were not
boolean. This is the second reason for supporting detecting boolean
attributes.
The alternative here is to create a list of supported attributes that
are boolean, then consult the list when decompiling. This path is prone
to errors where and when the list is incorrect. Firebug has to do quite
a lot of this kind of thing and it just makes the tool buggy and hard to
maintain. It's not like the platform doesn't know which attributes are
boolean, it just won't tell us.
jjb
Kyle Simpson
>> But the spirit of my question is really if dev-tools in a DOM view should
>> represent a boolean variable on a DOM element like `disabled`,
>> `disabled=true`, `disabled=""`, `disabled="disabled"`, or some other
>> variation?
>
> present boolean attributes any differently from other attributes,
This is a narrow interpretation of the scope of dev-tools. I don't
necessarily think that a dev-tool should be constrained to that, if there
are ways the dev-tool can help make things clearer.
For instance, we all know that there's a wide-array of different types of
markup that can all end up in the exact same DOM representation. We
shouldn't restrict an author to only inputting *markup* with how the DOM API
views and handles it.
I think it's a bad idea to ignore that many devs who are using such a tool
are, by and large, thinking in the mental context of the *markup*, not in
terms of their individual mutation actions mapping 1-to-1 to actual DOM API
calls (though in reality, they are under the covers). The tool should
represent things to the dev in the most natural context they are used to,
which I would argue is the markup-centric approach, not the DOM API
approach.
So a dev-tool should accept as input (when someone is editing
attributes/values) the wide array of variations that a markup developer is
used to having at their disposal, and should re-parse that input exactly as
the original parser would have had it come across that input in the original
source document.
But, by contrast, if there are certain representations (the output) of the
page structure which can be confusing (such as showing `disabled=""` when in
fact it semantically it means `disabled` or even `disabled=true`), then we
shouldn't be afraid to limit the output to the more sane/sensible
variations, so as to reduce confusion.
> Furthermore, the disabled="disabled" variation shouldn't be promoted in
> any way.
I'm confused, as you seem to contradict yourself, since in the paragraph
above this statement, you specifically cited that `disabled="disabled"`
should be shown, if that's what was in markup.
> This last claim is false. While the only thing that matters for the
> disabled _state_ is whether the attribute is present, the string value
> of the attribute matters for other things (e.g. getAttribute, attribute
> selector matching, and so forth).
OK, so this is a fair point. The attribute *can* have values, even though
the spec clearly says that all those values are invalid (only "" and
"{attribute-name}" are valid values for a boolean attribute).
It leads me to refine my suggestion a bit, that in the case of
`disabled=""`, *this* alone should be condensed to just `disabled`, but if
the author in the markup gave that attribute a value (despite that being an
invalid and frowned upon practice spec-wise), it should show that value.
Is there any case where showing specifically `disabled=""` is more helpful
as compared to `disabled`?
Clarification: does a CSS3 selector like `[disabled="foobar"]` actually
work? Should it? I'm a little bit surprised by that, as it would seem to
allow CSS3 selectors to match against invalid HTML5 markup, but I guess
that's just a fact of compat web dev out the wild.
> One issue is you think that attributes are either one or the other. The
> problem is that all attributes are always string attributes. Boolean
> attributes have an additional semantic behavior on top of that. The
> question is not _which_ behavior to expose but how to expose _both_
> behaviors, no?
OK, again, this is a fair point but it depends on your perspective. From
purely the perspective of the spec, I think my assertion is a little more
correct, in that the value of "" or "disabled" would be the only valid
values, so in fact it's not just a regular string attribute that can have
any value -- it's quite a bit more constrained.
But from the perspective of in-the-wild web dev, yes, the attribute can have
any string value, and I guess for legacy/compat sake, HTML5 parsers still
accept and keep that (technically invalid) value?
>> Now, the question remains, how (if any) can one decipher that an
>> attribute you are working with in the `attributes` collection of a DOM
>> element is, in fact, interpreted (by the parent element) as a special
>> boolean attribute?
>
> By hardcoding the list, at the moment.
It's been suggested that one could inspect the IDL reflected property (of
the same name as the attribute in question) on the DOM object, and
specifically its type, since this type should be "boolean" only for special
boolean attributes.
Does that sound like a viable way to find out if a particular attribute is
interpreted as a special boolean attribute? Are there pitfalls to that
approach I'm not aware of?
> dev-tools can just hardcode a list; it's really not that big a deal.
Hmm... I think maintaining a hard-coded list of each tag-type, and the
boolean attributes thereof, is a bit less trivial than it sounds. I believe
it's not just a list of attribute names ("disabled", "checked", etc) that
would be sufficient, but the pairings to their parent element, because I
believe there are cases where an attribute of some name is only boolean for
some tags, and not for others. For instance, I think there are cases where
`disabled` is not a recognized attribute (some elements), in which case it
would purely be interpreted as a string value attribute, not a special
boolean.
Even if this were somewhat trivial, I think it'd be a bad idea to maintain
such a list (duplication of logic from inside a parser) in a dev-tool. I'd
strongly prefer (almost to exclusivity) that if a dev-tool were going to
treat a boolean attribute in any special way, that it would be able to glean
that information from the DOM (or IDL property) solely.
> The real question here: should the Firefox API be extended to
> distinguish boolean HTML attributes from string attributes. Based on
> what we know, the answer should be Yes. I'll give two reasons: 1)
> because devs want to see boolean attributes as booleans and 2) because
> displaying boolean attributes as strings is misleading.
I agree (mostly) with John here. The only caveat would be, as mentioned
above, that I can see that if the parser maintains the (technically invalid)
arbitrary value of the `disabled` attribute from the markup, then I can see
that a dev-tool should show that. But, also as I said above, if there is no
such special/invalid value given (it's "" or "disabled"), then I could see
that the attribute display should collapse to just `disabled`.
> Whenever more than one source string creates the same DOM element, the
> decompiled result can differ from what the developer might have used. In
> such cases the development tool will have to choose how to decompile. No
> matter what choice is made, some developers will be surprised because
> the source will not look like they would have written it. For example,
> decompiling to |disabled=""| will surprise devs who typically write
> |disabled|.
+1
> The choice that development tools use will have a cultural effect and
> vice versa: developers will tend to adopt the same solution in their
> code and tools try to mimic devs. I believe that Kyle is trying to say
> that the DOM API should allow distinguishing boolean attributes so that
> the decompiled code can display them in the culturally accepted way,
> |disabled|. This is the first reason for support to detect booleans.
+1
> Certainly for Firebug and I guess for most Web development tools these
> days parsing the markup is not a practical option. Parsing HTML is a
> full time job for experts. So: we don't know what the markup said.
> Moreover, even if we could parse it, JavaScript probably walked on it in
> the meantime. Consequently there is no option that starts "if the
> markup said".
+1
> The alternative here is to create a list of supported attributes that
> are boolean, then consult the list when decompiling. This path is prone
> to errors where and when the list is incorrect. Firebug has to do quite
> a lot of this kind of thing and it just makes the tool buggy and hard to
> maintain. It's not like the platform doesn't know which attributes are
> boolean, it just won't tell us.
+1
--Kyle
Boris Zbarsky
> It leads me to refine my suggestion a bit, that in the case of
> `disabled=""`, *this* alone should be condensed to just `disabled`
This seems like an excellent idea, yes.
> Clarification: does a CSS3 selector like `[disabled="foobar"]` actually
> work?
Yes, of course.
> Should it?
Yes.
> I'm a little bit surprised by that, as it would seem to
> allow CSS3 selectors to match against invalid HTML5 markup
Uh... I think you have some really weird idea of what "invalid" means.
CSS selectors match against a DOM (in the HTML world). They don't match
against markup. The only thing that matters is what DOM is produced
from given markup. As long as getAttribute('disabled') returns "foobar"
when the markup is <input disabled="foobar">, the selector above will match.
>> One issue is you think that attributes are either one or the other. The
>> problem is that all attributes are always string attributes. Boolean
>> attributes have an additional semantic behavior on top of that. The
>> question is not _which_ behavior to expose but how to expose _both_
>> behaviors, no?
>
> OK, again, this is a fair point but it depends on your perspective. From
> purely the perspective of the spec, I think my assertion is a little
> more correct, in that the value of "" or "disabled" would be the only
> valid values
It doesn't matter what's "valid". That's an authoring requirement.
Behavior, on the other hand, depends on UA requirements. I will posit
that dev tools should help the author answer the "why am I getting this
behavior?" question.
> so in fact it's not just a regular string attribute that
> can have any value -- it's quite a bit more constrained.
By the same token, the "alt" attribute can't have "any value": its value
must be a text alternative for the image. Any other value is invalid
per spec.
And the "size" attribute for <select> is not allowed to have non-numeric
values per spec.
But none of these validity restrictions affect the processing per se;
size="100 blackbirds baked in a pie" on a <select> will put that string
in the DOM and give you a <select> with size 100.
> But from the perspective of in-the-wild web dev, yes, the attribute can
> have any string value, and I guess for legacy/compat sake, HTML5 parsers
> still accept and keep that (technically invalid) value?
HTML5 parsers accept _all_ input. The only question is what DOM they
produce. They never drop attribute values.
> It's been suggested that one could inspect the IDL reflected property
> (of the same name as the attribute in question) on the DOM object, and
> specifically its type, since this type should be "boolean" only for
> special boolean attributes.
>
> Does that sound like a viable way to find out if a particular attribute
> is interpreted as a special boolean attribute? Are there pitfalls to
> that approach I'm not aware of?
If I use this markup:
<style disabled="true">
body { color: green; }
</style>
then the body will be green (because there is no attribute named
"disabled" on <style> elements), but there _is_ a boolean DOM property
called 'disabled' on HTMLStyleElement and that property will test
_false_ in this case.
I can probably find other such examples; this is off the top of my head.
> Hmm... I think maintaining a hard-coded list of each tag-type, and the
> boolean attributes thereof, is a bit less trivial than it sounds. I
> believe it's not just a list of attribute names ("disabled", "checked",
> etc) that would be sufficient, but the pairings to their parent element,
That's what you would need, yes.
> Even if this were somewhat trivial, I think it'd be a bad idea to
> maintain such a list (duplication of logic from inside a parser)
There is no logic for this in the parser.
> I'd strongly prefer (almost to exclusivity) that if a dev-tool
> were going to treat a boolean attribute in any special way, that it
> would be able to glean that information from the DOM (or IDL property)
> solely.
I think you're conflating IDL properties and DOM attributes here...
We could have this logic in the core, but it would have _exactly_ the
form that devtools-specific logic would take: it would be a list of
element+attribute pairs. There's no existing source for this information.
>> The alternative here is to create a list of supported attributes that
>> are boolean, then consult the list when decompiling. This path is prone
>> to errors where and when the list is incorrect.
I think you're assuming that such a list in some to-be-created file in
the Gecko source will magically be more correct... there's no a priori
reason I believe that.
>It's not like the platform doesn't know which attributes are
> boolean, it just won't tell us.
"The platform" doesn't know. Individual elements know...
-Boris
Henri Sivonen
> > So I think dev tools should show `disabled=""` if the markup said `disabled` or `disabled=""`
>
> Certainly for Firebug and I guess for most Web development tools these
> days parsing the markup is not a practical option. Parsing HTML is a
> full time job for experts. So: we don't know what the markup said.
> Moreover, even if we could parse it, JavaScript probably walked on it in
> the meantime. Consequently there is no option that starts "if the
> markup said".
I was trying to illustrate what kind of DOMs you get. I don't expect dev tools to know what the markup said.
> > Furthermore, the disabled="disabled" variation shouldn't be promoted in any way. It's more characters to type and the only thing it helps with is pretending that HTML is SGML which it isn't.
>
> So why should we promote |disabled=""|?
I don't think presenting an attribute named "disabled" that has the
empty string as a value promotes things if you present it as
|disabled=""|. It's the the least special-casey way to present such an
attribute.
However, showing |disabled=""| is a red pill that creates a teachable
moment about the true nature of the DOM and HTML parsing.
> Worse than number of characters
> it creates confusion: it displays a boolean attribute as if it were not
> boolean.
That's the red pill moment. On the DOM Core and parsing levels, it's not
any different from other attributes.
> The alternative here is to create a list of supported attributes that
> are boolean, then consult the list when decompiling. This path is prone
> to errors where and when the list is incorrect.
As Boris already said, I don't see any reason to believe that putting
the list into Gecko itself would guarantee the correctness of the list
better than putting the list into dev tools, since Gecko itself doesn't
have or need such a list to behave correctly.
On Sun, 2011-06-05 at 14:38 -0500, Kyle Simpson wrote:
> > Furthermore, the disabled="disabled" variation shouldn't be promoted
> > in any way.
>
> I'm confused, as you seem to contradict yourself, since in the
> paragraph
> above this statement, you specifically cited that
> `disabled="disabled"`
> should be shown, if that's what was in markup.
I meant that the dev tools shouldn't massage the disabled attribute with
the empty string as its value to |disabled="disabled"| for display. If
the value of the attribute is "disabled" in the DOM, by all means show
it as the value.
> It leads me to refine my suggestion a bit, that in the case of
> `disabled=""`, *this* alone should be condensed to just `disabled`,
> but if
> the author in the markup gave that attribute a value (despite that
> being an
> invalid and frowned upon practice spec-wise), it should show that
> value.
When the disabled attribute exists in the DOM with the empty string as
its value, presenting it as |disabled| only works for me. Expect some
distress from XHTML fans, though, but XHTML is a fashion is on the
decline.
Kyle Simpson
> However, showing |disabled=""| is a red pill that creates a teachable
> moment about the true nature of the DOM and HTML parsing.
I earlier in this thread asserted that I think the purpose of a DOM
manipulation devtool is not in fact to act like a thin veneer to the DOM
API, because such devtools seem to always present themselves not as DOM
elements specifically, but as a serialized HTML'ish representation. I think
that clearly sets in most devs' minds the mental context that they are in
fact working with markup (or something very near to it), not with direct DOM
API calls.
As such, *I* think a devtool for DOM-markup manip should (for the most part)
behave most closely to how any entered text/markup would behave if it were
present in the original HTML markup, and being passed through the parser on
its first pass.
In that context, I believe it makes more sense for a devtool to behave
closer to the markup spec side of things, which is that arbitrary string
values in a boolean a property are invalid (and either not supported at all,
or at least de-emphasized). One small way we can de-emphasize that a boolean
property can hold string values is to not show the empty ="" string value,
for attributes which were specified in the markup as only something like
`disabled` and not `disabled="foobar!!!!"`.
Moreover, on the same line of thought, `disabled="disabled"` seems like it'd
ALSO be a reasonable candidate to collapse to `disabled`, because again,
just like with ="", this is not an author taking advantage of special or
invalid behavior, it's simply them following strict spec guidelines in the
definition of a boolean attribute, and that value ("{attribute-name"")
itself likely has no important meaning to them. It's possibly (likely?) a
case where we could make a judgment call to suppress the `="disabled"` part,
in an effort to de-emphasize the concept of a boolean attribute being able
to hold arbitrary string values.
I'm honestly not sure why, except for compat reasons, the parser allows such
arbitrary values to be kept in a boolean attribute. Is there some other
reason that hasn't yet been stated here for why there's a divergence between
what the spec says and what the parser/engine allows?
In any case, that's not really in the scope of what we have to spend time
hashing out. If the parser is going to continue to accept and store such
values, then I can definitely see the argument that if the author *does*
give some special value (that is, not "" and not "{attribute-name}"), then
it should be shown. But if there's no value, or if the value is "" or
"{attribute-name}", then I think it should be collapsed.
Is there any reasonable use-case we'd be missing if that was the policy?
>> The alternative here is to create a list of supported attributes that
>> are boolean, then consult the list when decompiling. This path is prone
>> to errors where and when the list is incorrect.
>
> As Boris already said, I don't see any reason to believe that putting
> the list into Gecko itself would guarantee the correctness of the list
> better than putting the list into dev tools, since Gecko itself doesn't
> have or need such a list to behave correctly.
Correct me if I'm wrong (I don't know all the internal implementation
details of Gecko), but certainly somewhere, whether per-attribute, or at a
more global list level, there must be a mapping or code logic that
special-case handles attributes for a given element for which that element
will interpret the attribute in question as *boolean*, right?
Whether this is an out-right list or not is irrelevant, what is relevant is
that there must already be in Gecko some mapping that says "DOM element X
with attribute Y => attribute Y is boolean". As such, taking all such
mappings and duplicating them outside of Gecko is, in my opinion, a bad
idea, compared to if there's some way that Gecko and/or the DOM and/or the
IDL reflected property in JavaScript could reflect the "boolean nature" of
an attribute upon inspection.
> I meant that the dev tools shouldn't massage the disabled attribute with
> the empty string as its value to |disabled="disabled"| for display. If
> the value of the attribute is "disabled" in the DOM, by all means show
> it as the value.
No, I definitely wouldn't suggest that, as that's counter to the spirit of
what I'm trying to accomplish, which is to reduce and de-clutter the DOM
inspection dev-tool.
>> It leads me to refine my suggestion a bit, that in the case of
>> `disabled=""`, *this* alone should be condensed to just `disabled`,
>> but if
>> the author in the markup gave that attribute a value (despite that
>> being an
>> invalid and frowned upon practice spec-wise), it should show that
>> value.
>
> When the disabled attribute exists in the DOM with the empty string as
> its value, presenting it as |disabled| only works for me. Expect some
> distress from XHTML fans, though, but XHTML is a fashion is on the
> decline.
So, if we agree on suppressing `=""`, what about also suppressing
`="{attribute-name}"` specifically?
--Kyle
Kyle Simpson
> It doesn't matter what's "valid". That's an authoring requirement.
On the contrary, I'd argue that this is *exactly* what a devtool for the DOM
should be doing... enforcing authoring-centric rules, because in practice
what a user of such a tool is doing, especially since the UI they are
presented is in fact markup, is *authoring* new markup/content for the page.
That's why I said earlier that a devtool of this sort should be operating in
the most natural and comfortable mental context of the user. Since we
present things as markup, and let them edit them like they're editing
markup, then the behaviors and rules enforced should, by and large, act like
the rules enforced on markup.
> By the same token, the "alt" attribute can't have "any value": its value
> must be a text alternative for the image. Any other value is invalid
> per spec.
Apples and oranges. The `alt` attribute has a semantic restriction that it
be a text-alternative for the image, but this presents absolutely no
technical restriction on the value (it can still be any string the author
likes -- a validator would never be able to say "I don't think you followed
the semantic spirit of this value with what you entered."). Boolean
attributes on the other hand are specifically limited to "" or
"{attribute-name}", which is in fact a technical restriction, not a semantic
one.
> And the "size" attribute for <select> is not allowed to have non-numeric
> values per spec. But none of these validity restrictions affect the
> processing per se;
> size="100 blackbirds baked in a pie" on a <select> will put that string
> in the DOM and give you a <select> with size 100.
OK, so this is an example where there IS in fact a *technical* restriction
from the spec perspective on what you should and shouldn't enter into the
`size` attribute. And you're saying that the parser (or Gecko, or whatever)
does in fact enforce that the only value it's going to interpret from the
arbitrary string soup is to try to parse out a number, because the spec says
this value has to be numeric. And, we'd agree that the select should in fact
be size of 100 rows.
But the question that's more appropriate to our conversation is, does later
asking the DOM for the attribute of name `size` give only "100" or does it
give "100 blackbirds baked in a pie" since that's in the original markup?
I'd argue that if behaviorally the engine is only going to respect the
numeric "100" part, then keeping the " blackbirds baked in a pie" part
around is irrelevant and useless (unless there's a compelling compat
use-case to override the narrow definition of the spec).
Similarly, I'd expect if I were using a devtool to enter markup (or
something that is clearly represented to me as markup), and if I entered
"100 blackbirds baked in a pie" into a place that I knew only allowed a
numeric input, that either the tool would complain at me, or that the tool
would just drop whatever I entered that fails that validation rule
(everything non-numeric), such that the markup I then see reflected back to
me is in spirit the validated/filtered version of the markup as I *should*
have entered it.
In spirit, we already do the lion's share of this, by normalizing all the
various things that markup can include into some reasonable DOM
representation, which we then serialize back out to something that looks
like valid markup. I'm simply suggesting we take that one tiny step further,
and remove/suppress attribute values which would be caught by such a
"filter" as well.
Furthermore, I'd expect the parser to ignore/drop non-numeric data in a
numeric-only attribute value. However, I am going to make a strong guess
based on the previous discussion of boolean attributes that in fact the
whole invalid value is kept around. Am I right?
Bottom line: while that may be current (although I think possibly unhealthy)
behavior for the parser and engine to take, I don't necessarily think that a
devtool has to make all those same mistakes (or, rather, be saddled with all
that legacy/compat behavioral requirement). I think it's at least something
to think about that perhaps a devtool should only allow (or strongly
encourage you to adhere to) valid markup and best-practices...
...AKA, a better subset of what is actually allowed by the DOM API.
>> It's been suggested that one could inspect the IDL reflected property
>> (of the same name as the attribute in question) on the DOM object, and
>> specifically its type, since this type should be "boolean" only for
>> special boolean attributes.
>>
>> Does that sound like a viable way to find out if a particular attribute
>> is interpreted as a special boolean attribute? Are there pitfalls to
>> that approach I'm not aware of?
>
> If I use this markup:
>
> <style disabled="true">
> body { color: green; }
> </style>
>
> then the body will be green (because there is no attribute named
> "disabled" on <style> elements), but there _is_ a boolean DOM property
> called 'disabled' on HTMLStyleElement and that property will test
> _false_ in this case.
So, this example suggests that it would be a false-positive, where the check
I'm proposing (looking only at the `typeof` output) would think that the
`disabled` property is a boolean property, when in fact it's not.
HOWEVER, could the test look not only at the `typeof` output, but also the
reflected property's value, and combined then know if the element treated
that attribute as boolean? In other words:
<input id="foobar" type="text" disabled />
var elem = document.getElementById("foobar");
(typeof elem.disabled == "boolean" && elem.disabled === true); // true
If the element in fact treats the attribute as boolean, then its mere
presence in markup would imply that the behavior is that it's true, and thus
the reflected property should also show as `true`.
There's two questions:
1. Are there any cases where this would give a false-positive (where the
reflected property value is `true` by default, but that this doesn't
correctly imply that there's a boolean attribute of the same name)?
2. Are there any cases where this would give a false-negative (where the
reflected property value is `false` by default, even when a boolean
attribute of the same name is present in the markup for that element)?
NOTE: I *know* that user-land JavaScript could easily construct elements
which fail either of those questions... but I'm talking specifically about
*default* behavior of a newly created (not even yet DOM-inserted) test
element, that I as a devtool author could construct to do a "feature-test"
of sorts for determining if something is a boolean attribute or not.
Specifically, I'd like to know if any of the answers that may be cited for
question #1 or #2 would be cases where there's a valid reason that it's
true, and not just some bug/oversight that could/should be corrected.
--Kyle
Boris Zbarsky
>> On 6/5/11 2:36 PM, Boris Zbarsky wrote:
>> It doesn't matter what's "valid". That's an authoring requirement.
>
> On the contrary, I'd argue that this is *exactly* what a devtool for the
> DOM should be doing... enforcing authoring-centric rules, because in
> practice what a user of such a tool is doing, especially since the UI
> they are presented is in fact markup, is *authoring* new markup/content
> for the page.
What _I_ am typically doing with a devtool is debugging a page and
trying to understand why it's not behaving the way I expected it to.
Which means that I want the tool to tell me exactly what the DOM and CSS
that the browser see look like. That way if that DOM doesn't match what
I expected based on my markup that's a good indication that the problem
might lie in how my markup got parsed.
Note that this is also why I think that devtools presenting a "source
like" view is not very good UI: it tends to make you think inside the
"source view" box. On the other hand, the devtool I use most often in
fact presents a tree-like UI instead of a source-like one...
> That's why I said earlier that a devtool of this sort should be
> operating in the most natural and comfortable mental context of the
> user. Since we present things as markup, and let them edit them like
> they're editing markup, then the behaviors and rules enforced should, by
> and large, act like the rules enforced on markup.
One important question arises: _should_ you be presenting things as
markup? ;)
>> By the same token, the "alt" attribute can't have "any value": its value
>> must be a text alternative for the image. Any other value is invalid
>> per spec.
>
> Apples and oranges.
Not at all.
> The `alt` attribute has a semantic restriction that
> it be a text-alternative for the image, but this presents absolutely no
> technical restriction on the value (it can still be any string the
> author likes -- a validator would never be able to say "I don't think
> you followed the semantic spirit of this value with what you entered.").
Actually, I think you're wrong here. It wouldn't be that hard for a
validator to say that <img lang="en" alt="xxxydfgdg"> is invalid.
> Boolean attributes on the other hand are specifically limited to "" or
> "{attribute-name}", which is in fact a technical restriction, not a
> semantic one.
I think you're creating distinctions which just don't exist.....
>> And the "size" attribute for <select> is not allowed to have non-numeric
>> values per spec. But none of these validity restrictions affect the
>> processing per se;
>> size="100 blackbirds baked in a pie" on a <select> will put that string
>> in the DOM and give you a <select> with size 100.
>
> OK, so this is an example where there IS in fact a *technical*
> restriction from the spec perspective on what you should and shouldn't
> enter into the `size` attribute. And you're saying that the parser (or
> Gecko, or whatever) does in fact enforce that the only value it's going
> to interpret from the arbitrary string soup is to try to parse out a
> number, because the spec says this value has to be numeric. And, we'd
> agree that the select should in fact be size of 100 rows.
But in the DOM the value would be "100 blackbirds baked in a pie", note.
> But the question that's more appropriate to our conversation is, does
> later asking the DOM for the attribute of name `size` give only "100" or
> does it give "100 blackbirds baked in a pie" since that's in the
> original markup?
The latter.
> I'd argue that if behaviorally the engine is only going
> to respect the numeric "100" part, then keeping the " blackbirds baked
> in a pie" part around is irrelevant and useless
Your mental model doesn't match the web, the spec, or deployed, UAs, sorry.
> Similarly, I'd expect if I were using a devtool to enter markup (or
> something that is clearly represented to me as markup), and if I entered
> "100 blackbirds baked in a pie" into a place that I knew only allowed a
> numeric input, that either the tool would complain at me, or that the
> tool would just drop whatever I entered that fails that validation rule
> (everything non-numeric), such that the markup I then see reflected back
> to me is in spirit the validated/filtered version of the markup as I
> *should* have entered it.
I think we have a fundamental problem here where a "devtool" is being
viewed by you as primarily an _authoring_ tool whereas I think for most
people it's primarily a _debugging_ tool.
Now the existing tools can be used to do both, just like I can hammer in
nails with a crescent wrench if I really have to. But it's not obvious
to me that this is a _good_ thing.
In C++, say, my debugging tools do give me access to the source, but
also to the generated assembly and the like, for those times when I need
to tell what the processor is actually seeing. The web's debugging
tools need to do likewise.
> Furthermore, I'd expect the parser to ignore/drop non-numeric data in a
> numeric-only attribute value. However, I am going to make a strong guess
> based on the previous discussion of boolean attributes that in fact the
> whole invalid value is kept around. Am I right?
Yep.
>> then the body will be green (because there is no attribute named
>> "disabled" on <style> elements), but there _is_ a boolean DOM property
>> called 'disabled' on HTMLStyleElement and that property will test
>> _false_ in this case.
>
> So, this example suggests that it would be a false-positive, where the
> check I'm proposing (looking only at the `typeof` output) would think
> that the `disabled` property is a boolean property, when in fact it's not.
>
> HOWEVER, could the test look not only at the `typeof` output, but also
> the reflected property's value, and combined then know if the element
> treated that attribute as boolean?
Yes, if the reflected property's name matches the attribute name. In
many cases it does not.
> 1. Are there any cases where this would give a false-positive (where the
> reflected property value is `true` by default, but that this doesn't
> correctly imply that there's a boolean attribute of the same name)?
Good question. Check the spec?
> 2. Are there any cases where this would give a false-negative (where the
> reflected property value is `false` by default, even when a boolean
> attribute of the same name is present in the markup for that element)?
Again, check the spec.
-Boris
Cameron McCormack
> But the question that's more appropriate to our conversation is,
> does later asking the DOM for the attribute of name `size` give only
> "100" or does it give "100 blackbirds baked in a pie" since that's
> only going to respect the numeric "100" part, then keeping the "
> blackbirds baked in a pie" part around is irrelevant and useless
> definition of the spec).
I can imagine a case where the author has a script that does something
like this:
var x = myElement.getAttribute("size");
x *= 2;
That’ll give NaN for size="100 blackbirds baked in a pie". If the
author is trying to debug why x is NaN, they might want to inspect the
DOM. If the DOM inspector is hiding the fact that the attribute value
is "100 blackbirds baked in a pie" and not "100" then it’s going to be
misleading.
--
Cameron McCormack ≝ http://mcc.id.au/
Zack Weinberg
>> The `alt` attribute has a semantic restriction that
>> it be a text-alternative for the image, but this presents absolutely no
>> technical restriction on the value (it can still be any string the
>> author likes -- a validator would never be able to say "I don't think
>> you followed the semantic spirit of this value with what you entered.").
>
> Actually, I think you're wrong here. It wouldn't be that hard for a
> validator to say that <img lang="en" alt="xxxydfgdg"> is invalid.
>
>> Boolean attributes on the other hand are specifically limited to "" or
>> "{attribute-name}", which is in fact a technical restriction, not a
>> semantic one.
>
> I think you're creating distinctions which just don't exist.....
I have no dog in this fight, but I think you're being a little unfair
here. Authoring conformance requirements that can easily be checked
with a program we know how to write are not at all the same thing as
authoring conformance requirements that require strong AI.
Yeah, you could validate that in <img lang="en" alt="..."> the text of
... was a well-formed English sentence (as accurately as a word
processor's grammar checker can, anyway) but you couldn't check that the
sentence described the image.
>> Similarly, I'd expect if I were using a devtool to enter markup (or
>> something that is clearly represented to me as markup), and if I entered
>> "100 blackbirds baked in a pie" into a place that I knew only allowed a
>> numeric input, that either the tool would complain at me, or that the
>> tool would just drop whatever I entered that fails that validation rule
>> (everything non-numeric), such that the markup I then see reflected back
>> to me is in spirit the validated/filtered version of the markup as I
>> *should* have entered it.
>
> I think we have a fundamental problem here where a "devtool" is being
> viewed by you as primarily an _authoring_ tool whereas I think for most
> people it's primarily a _debugging_ tool.
It seems to me that the ideal behavior in both cases would be to show
size="100 blackbirds baked in a pie" with " blackbirds baked in a pie"
somehow marked as erroneous.
Similarly, for Boolean attributes, showing disabled="" as just
"disabled" would be fine by me, but disabled="disabled" should be
written out in full and disabled="true" should mark "true" as an error.
zw
Boris Zbarsky
> I have no dog in this fight, but I think you're being a little unfair
> here. Authoring conformance requirements that can easily be checked with
> a program we know how to write are not at all the same thing as
> authoring conformance requirements that require strong AI.
That's fair, but the poing is that machine-checkability of authoring
conformance requirements is not binary: it's a continuum. And there are
plenty of other examples of machine-checkable authoring conformance
requirements in HTML that don't impose any particular requirements on
implementors. @alt is just the most obvious case that I could cite
without digging into the spec. ;)
> Yeah, you could validate that in <img lang="en" alt="..."> the text of
> .... was a well-formed English sentence (as accurately as a word
> processor's grammar checker can, anyway) but you couldn't check that the
> sentence described the image.
Sure. So you can't tell when it's valid, but in many cases you can tell
when it's invalid.
>> I think we have a fundamental problem here where a "devtool" is being
>> viewed by you as primarily an _authoring_ tool whereas I think for most
>> people it's primarily a _debugging_ tool.
>
> It seems to me that the ideal behavior in both cases would be to show
> size="100 blackbirds baked in a pie" with " blackbirds baked in a pie"
> somehow marked as erroneous.
That would be ideal, yes.
> Similarly, for Boolean attributes, showing disabled="" as just
> "disabled" would be fine by me
Indeed.
> but disabled="disabled" should be
> written out in full and disabled="true" should mark "true" as an error.
Again, agreed.
-Boris
Kyle Simpson
> like this:
>
> var x = myElement.getAttribute("size");
> x *= 2;
>
> That’ll give NaN for size="100 blackbirds baked in a pie". If the
> author is trying to debug why x is NaN, they might want to inspect the
> DOM. If the DOM inspector is hiding the fact that the attribute value
> is "100 blackbirds baked in a pie" and not "100" then it’s going to be
> misleading.
I don't necessarily agree that this is a use-case that's best (or
reasonable) for a *DOM manip devtool* (which is inspecting the DOM, in
reality) to be expected to handle.
At most, I'd say that it's a secondary use-case. Here's why: the real
problem is an original markup authoring problem, of which there are already
tools to help you out (for instance, checking the generated markup from a
server-side script): namely, view-source. View-source would tell you exactly
the same info that you purport to have the DOM manip tool show (that is, the
*original* and somewhat invalid markup -- the strange/invalid attribute
value). And arguably, this is where your problem started (the original
markup), so you should fix the problem at its source: the source.
Consider for a moment that if you were approaching debugging this problem
from a "what is the current state of the DOM?" perspective (using a DOM
inspection/manip devtool), you'd potentially end up at a dead-end. Say for
instance that you skipped view-source as a tool, and went first to the
current state of the DOM in this devtool, and the devtool in question
exposed this crazy NaN string value.
If you're thinking about this as a "some code on the page set that value",
your logical question is then: "which line of JavaScript set that value",
but this DOM inspection/manip devtool will do nothing to help you answer
that question, so you're at a dead end. If you're instead thinking about
this as a "well how on earth did that markup get set", then you're actually
thinking the same thing as if you had started with the more appropriate
view-source as your tool of choice.
And, more to the point, view-source can definitively answer a question that
the DOM manip devtool cannot: did the problem originate with the original
markup, or with some JavaScript later. This is a much more useful first-step
debugging question & answer, so it's the place that such debugging should
ideally start. If view-source shows the bad value, then you should start by
fixing it in the source, not in JavaScript (nor in your DOM manip devtool).
Moreover, there's lots of other things in invalid markup that are
normalized/ignored away by the process of sending the original markup
through a parser, and then serializing that parsed DOM back into
human-readable "markup" in a devtool. We're for instance not at all
concerned with representing in the devtools the invalid DOM that is created
by <b><u>foobar</b></u> (and many other variations) -- the spec has a
consistent way of normalizing that junk, and we're fine with the devtool not
showing any of that original invalid markup (except in view-source).
So, why is it that we're concerned with preserving the display of original
attribute values (if they are, in fact, invalid)? What's special about those
use-cases (as opposed to the invalid structure use-cases, among other
examples) that causes us to preserve them (and not even consider normalizing
them away), in the views that devtools gives of the DOM?
Isn't view-source the more appropriate tool for such things?
--Kyle
Boris Zbarsky
> We're for instance not at all
> concerned with representing in the devtools the invalid DOM that is
> created by <b><u>foobar</b></u>
This creates a valid DOM in all modern browsers. The fact that you
think it doesn't is troubling. :(
> (and many other variations) -- the spec
> has a consistent way of normalizing that junk, and we're fine with the
> devtool not showing any of that original invalid markup (except in
> view-source).
Precisely; all that matters for purposes of the resulting behavior is
the resulting DOM, not the original markup.
The original markup is only interesting once you find where in your DOM
the problem is and are trying to figure out how you ended up with that DOM.
> So, why is it that we're concerned with preserving the display of
> original attribute values (if they are, in fact, invalid)? What's
> special about those use-cases (as opposed to the invalid structure
> use-cases, among other examples) that causes us to preserve them (and
> not even consider normalizing them away), in the views that devtools
> gives of the DOM?
The behavior of a web page is determined by its DOM and computed style
(and the way scripts change those). To debug said behavior, you need a
tool that shows you said DOM and computed style. Once you figure out
which part of the DOM or the computed style is causing your issue, you
need to figure out how the DOM and style got into that state.
This last part is where view-source, CSS debuggers, etc come in. But
the first step needs to happen first: determining which part of the DOM
and computed style is causing the problem in the first place.
-Boris
Kevin Dangoor
> On 6/6/11 6:30 PM, Kyle Simpson wrote:
>
>> We're for instance not at all
>> concerned with representing in the devtools the invalid DOM that is
>> created by <b><u>foobar</b></u>
>>
>
> This creates a valid DOM in all modern browsers. The fact that you think
> it doesn't is troubling. :(
>
>
I think Kyle misspoke there and that he meant that we're not concerned with
representing <b><u>foobar</b></u> which is invalid markup, but rather we
just display the DOM that was created which looks more like
<b><u>foobar</u></b> when serialized.
That said, the difference between this and the disabled="yes, this is
disabled" case is that the DOM that results from the invalid markup is a
valid DOM in the foobar case. In the disabled case, getAttribute("disabled")
still returns "yes, this is disabled". To display otherwise is not telling
what is truly in the DOM. I agree with Zack's point that the ideal is to
show the user what's actually in the DOM and flag errors as such.
Kevin
--
Kevin Dangoor
work: http://mozilla.com/
email: kdan...@mozilla.com <k...@blazingthings.com>
blog: http://www.BlueSkyOnMars.com
Kyle Simpson
> that only "disabled" and "" are valid values here and anything else you
> write isn't actually HTML) and _UA_ conformance requirements (which are
> that the value the parser sticks in the DOM should be the value that was
> in the markup).
I'm not sure that I'm confusing the two so much as I'm asserting that
perhaps a devtool of this nature doesn't have to fall into the same
requirements bucket as the UA and parser do.
Specifically, I think I'm advancing the idea that the devtool for DOM
inspection/manip, which already presents things in a fundamentally
markup-looking-way, should be closer in behavior to what *proper*
(well-formed AND valid) markup authoring should be (and where possible,
encourage or strongly guide toward that), as opposed to allowing any old
invalid markup as input *and* yet still preserving that for the dev to see.
Accepting the invalid markup is fine, but how that markup is normalized to
turn around and output visually to the dev -- THAT is the step that I'm
suggesting should be a bit more guiding and instructive.
In fact, most existing devtools (in various browsers) for DOM
inspection/manip present the DOM in a tree fashion, but they actually show
each DOM element as a `<tag-name attr="val" list="other" />` type of output
for each line, which is what I'm saying is much more "markup like" than "DOM
like". AND, most of these tools also implement structured editing on top of
this display; by that I mean that you are constrained to editing only the
attribute value one at a time, etc.
I'd argue that the purpose of structured editing, at least to a fair degree,
is to help give you guiding boundaries to stay in, such that you keep your
"authoring" to a valid subset of what's strictly possible to send at the
parser. This has the same philosophical goal that I'm suggesting: to have
the DOM inspection/manip tool help a dev author (even changes to existing
content are authoring; see below) both well-formed AND valid markup as they
go. In big and small ways, the devtool can constrain their input, normalize
the output, and other such subtleties, to strongly guide them toward not
shooting their toe off with screwing up the page's structure and content.
> Note that this is also why I think that devtools presenting a "source
> like" view is not very good UI: it tends to make you think inside the
> "source view" box. On the other hand, the devtool I use most often in
> fact presents a tree-like UI instead of a source-like one...
> ...
> One important question arises: _should_ you be presenting things as
> markup? ;)
As I said above, I agree that most devtools for the DOM use a tree, but I
still assert that they are fundamentally markup-like in their output,
because of how they associate the attributes list with the tag, by
presenting it like well-formed HTML tag would appear. This contrasts with
something which for instance would simply list the element tag name in the
tree, with no surrounding < ... >, and all its attributes would be listed as
children nodes vertically below, as opposed to serialized horizontally like
in typical markup.
True, tools like Firebug present a collapsible tree, where each line is a
single DOM element, and elements are nested below other elements. But if
each element in the tree is presented in markup-like fashion, then overall
the effect of this tool is that it's presenting something more akin to
markup than to the DOM itself.
> I think we have a fundamental problem here where a "devtool" is being
> viewed by you as primarily an _authoring_ tool whereas I think for most
> people it's primarily a _debugging_ tool.
I think what I'm specifically saying is that *any* action that you take to
mutate the page while using a tool that is primarily presented in the
markup-like view I've just described is, in fact, authoring. You change an
attribute value: you're *authoring* that value into a markup-like view
editor, in a very similar way to if you were in your own code editor and
editing the original markup. Same with tags, attribute names, structure,
etc. What you do as a dev when you are in a markup-view is quite akin to
authoring markup, and should be streamlined for such.
NOW, I recognize that the *reason* you are authoring (aka, mutating an
existing page) is almost entirely for debugging purposes. No argument there.
But I don't think that when you're mutating for debugging purposes only,
that you're doing something fundamentally all that different than when your
mutating the DOM in a markup-like view, which is quite similar to authoring
HTML.
They're so close, in fact, that I'm suggesting the devtool, when in that
presentation mode, should act with that mental context in mind first
(meaning the tool is optimized flow-wise for that context), not the rules
and quirks of the underlying DOM representation and API, nor what the parser
and UA must accept and preserve.
> In C++, say, my debugging tools do give me access to the source, but
> also to the generated assembly and the like, for those times when I need
> to tell what the processor is actually seeing. The web's debugging
> tools need to do likewise.
I don't disagree. Both are useful tools on the web. I just think that the
way most DOM inspection/manip devtools present each element in markup-like
fashion means that the tool's behavior is harmonically discordant with
showing (or allowing manipulation of) "generated assembly and the like".
That's using a screwdriver to drive in a nail.
There are other tools more well suited for that task, specifically the
navigable DOM-like tree that you can access if you console.log() a DOM
object; THAT is in my mind the "assembly language" tool. The tree-like tool
where each line looks like a markup tag with attributes -- THAT tool is more
akin to markup authoring, I think.
>> As such, taking
>> all such mappings and duplicating them outside of Gecko is, in my
>> opinion, a bad idea, compared to if there's some way that Gecko and/or
>> the DOM and/or the IDL reflected property in JavaScript could reflect
>> the "boolean nature" of an attribute upon inspection.
>
> The only way it could do that is by duplicating such mappings _inside_
> Gecko. Which is not really any better than duplicating them outside
> Gecko....
Even if the only way to expose such information to JavaScript was to create
an entirely separate list of these mappings (which I don't agree is the only
way), I'd still say that such a list inside of Gecko is better than a list
inside of a separate devtool, because I think it makes it more likely that
such a list will be kept "nearer" to the original bits of code, and thus
hopefully more up to date upon changes, as opposed to having the duplicated
code "further away" in the devtools code base. That's probably mostly a
subjective assertion, but I generally try to keep related (and especially
duplicated) code as "close" as possible.
Moreover, I've suggested here that a solution to this could be as simple as
having an additional property on the attribute node, like `isBoolean`, that
is only present, and is only `true`, for attributes on elements where that
element interprets that attribute as in fact boolean. Presumably every
element has somewhere inside it access to that information, so that it can
treat the presence or absence of that attribute appropriately (and
differently from simple string-value attributes).
So, as John said earlier in the thread, the DOM element knows if an
attribute on it is interpreted as boolean or not, and it is not currently
exposing that info, but it easily could. I think that is what he meant by
"the platform knows...".
--Kyle
Boris Zbarsky
>> One important question arises: _should_ you be presenting things as
>> markup? ;)
...
> True, tools like Firebug present a collapsible tree, where each line is
> a single DOM element, and elements are nested below other elements. But
> if each element in the tree is presented in markup-like fashion, then
> overall the effect of this tool is that it's presenting something more
> akin to markup than to the DOM itself.
I'm well aware of what the tools do. I'm just questioning whether it's
a good idea.
>> I think we have a fundamental problem here where a "devtool" is being
>> viewed by you as primarily an _authoring_ tool whereas I think for most
>> people it's primarily a _debugging_ tool.
>
> I think what I'm specifically saying is that *any* action that you take
> to mutate the page while using a tool that is primarily presented in the
> markup-like view I've just described is, in fact, authoring.
Sure. The vast majority of my devtool time is spent _examining_ the
page, not mutating it.
> NOW, I recognize that the *reason* you are authoring (aka, mutating an
> existing page) is almost entirely for debugging purposes.
When you get desperate, you fall back on this sort of debugging, yes.
By that point, your tool has probably failed you by not providing a way
to see the information you wanted to see, so you're falling back on
guess-and-check.
> They're so close, in fact, that I'm suggesting the devtool, when in that
> presentation mode, should act with that mental context in mind first
> (meaning the tool is optimized flow-wise for that context), not the
> rules and quirks of the underlying DOM representation and API, nor what
> the parser and UA must accept and preserve.
And I'm suggesting that the tool should be optimized for examining the
DOM and providing the author for information. The fact that it also
supports editing (which is fundamentally like poking memory values in a
C++ debugger in terms of usability for debugging and when you would use
it) should not interfere with the examining end of things.
> I don't disagree. Both are useful tools on the web. I just think that
> the way most DOM inspection/manip devtools present each element in
> markup-like fashion means that the tool's behavior is harmonically
> discordant with showing (or allowing manipulation of) "generated
> assembly and the like". That's using a screwdriver to drive in a nail.
Yes, and I'm arguing that it's the presentation that's wrong here.
>> The only way it could do that is by duplicating such mappings _inside_
>> Gecko. Which is not really any better than duplicating them outside
>> Gecko....
>
> Even if the only way to expose such information to JavaScript was to
> create an entirely separate list of these mappings (which I don't agree
> is the only way)
Pray tell me, what other ways are you seeing here?
> I'd still say that such a list inside of Gecko is
> better than a list inside of a separate devtool
Er... Why are we talking about a _separate_ devtool? I'm quite happy
for this list to be in an integrated devtool or API such tools can
access (because clearly devtools would want to share the list); I'm just
saying that it doesn't necessarily belong in the code DOM.
But note that a good devtool would need a heck of a lot more info than
this to do the sort of "this attribute value is erroneous" highlighting
that's really desirable.
> Moreover, I've suggested here that a solution to this could be as simple
> as having an additional property on the attribute node, like
> `isBoolean`
Given that we're working on removing attribute nodes.... I don't like
this solution. ;)
> Presumably every element has somewhere inside it access to that
> information
You presume wrong. That's what I've been trying to tell you. The
element may not be what's doing the interpreting at all. It might be
some code somewhere else that works with the element.
> So, as John said earlier in the thread, the DOM element knows if an
> attribute on it is interpreted as boolean or not
And John is wrong. And I've said so several times in this thread. But
you're just not listening.
-Boris
johnjbarton
> On 6/6/11 7:15 PM, Kyle Simpson wrote:
>>> I think we have a fundamental problem here where a "devtool" is being
>>> viewed by you as primarily an _authoring_ tool whereas I think for most
>>> people it's primarily a _debugging_ tool.
>>
>> I think what I'm specifically saying is that *any* action that you take
>> to mutate the page while using a tool that is primarily presented in the
>> markup-like view I've just described is, in fact, authoring.
>
> Sure. The vast majority of my devtool time is spent _examining_ the
> page, not mutating it.
>
>> NOW, I recognize that the *reason* you are authoring (aka, mutating an
>> existing page) is almost entirely for debugging purposes.
>
> When you get desperate, you fall back on this sort of debugging, yes. By
> that point, your tool has probably failed you by not providing a way to
> see the information you wanted to see, so you're falling back on
> guess-and-check.
Did you have an alternative tool in mind? Really what we have now is
pathetic, we need to think up new approaches.
On the other hand, runtime state manipulation seems primarily to be
addressing failings in source development tools, not debuggers. CSS/HTML
are very complex: devs rarely understand the nuances of |disabled| we
discuss here. Modifying the runtime values of an element to experiment
is a powerful why to learn. The feedback is immediate and you can focus
on just a single aspect of a complex problem.
(Arguably the learning is piecemeal: if you believe your goal is to
*learn* CSS/HTML/JavaScript, then its not a good solution. I believe
most developers gave up on that goal some time ago.)
>> I don't disagree. Both are useful tools on the web. I just think that
>> the way most DOM inspection/manip devtools present each element in
>> markup-like fashion means that the tool's behavior is harmonically
>> discordant with showing (or allowing manipulation of) "generated
>> assembly and the like". That's using a screwdriver to drive in a nail.
>
> Yes, and I'm arguing that it's the presentation that's wrong here.
What presentation would be right?
jjb
Henri Sivonen
> It's possibly (likely?) a
> case where we could make a judgment call to suppress the `="disabled"` part,
> in an effort to de-emphasize the concept of a boolean attribute being able
> to hold arbitrary string values.
Please don't suppress ="disabled" when getAttribute() would return
"disabled". Like Boris said, for debugging some of us want to know
what's really in the DOM. If you suppress the attribute value when the
value is not the empty string, you aren't telling what's really in the
DOM.
> I'm honestly not sure why, except for compat reasons, the parser allows such
> arbitrary values to be kept in a boolean attribute. Is there some other
> reason that hasn't yet been stated here for why there's a divergence between
> what the spec says and what the parser/engine allows?
Simplicity. Now the parser doesn't need to know anything about what's
allowed as the value of which attributes. The values of all attributes
are handled the same way in the parser.
> But if there's no value, or if the value is "" or
> "{attribute-name}", then I think it should be collapsed.
There's no such thing as "no value" for attributes in the DOM. And as
mentioned above, I disagree about collapsing {attribute-name}.
> Is there any reasonable use-case we'd be missing if that was the policy?
Yes: Debugging why different disabled controls on a page are styled in
different ways when the reason is that the page author wrote
|[disabled="disabled"]| in the style sheet, disabled some controls by
putting |disabled="disabled"| in the markup but disabled other controls
by assigning to the .disabled DOM property.
> Whether this is an out-right list or not is irrelevant, what is relevant is
> that there must already be in Gecko some mapping that says "DOM element X
> with attribute Y => attribute Y is boolean".
There *really* isn't.
> So, if we agree on suppressing `=""`, what about also suppressing
> `="{attribute-name}"` specifically?
Disagreed as explained above.
On Mon, 2011-06-06 at 17:35 -0500, Kyle Simpson wrote:
> <input id="foobar" type="text" disabled />
>
> var elem = document.getElementById("foobar");
> (typeof elem.disabled == "boolean" && elem.disabled === true); // true
>
> If the element in fact treats the attribute as boolean, then its mere
> presence in markup would imply that the behavior is that it's true,
> and thus
> the reflected property should also show as `true`.
>
> There's two questions:
> 1. Are there any cases where this would give a false-positive (where
> the
> reflected property value is `true` by default, but that this doesn't
> correctly imply that there's a boolean attribute of the same name)?
<video paused>
There's a DOM property called "paused" but the markup attribute of the
same name is bogus.
Boris Zbarsky
>> When you get desperate, you fall back on this sort of debugging, yes. By
>> that point, your tool has probably failed you by not providing a way to
>> see the information you wanted to see, so you're falling back on
>> guess-and-check.
>
> Did you have an alternative tool in mind? Really what we have now is
> pathetic, we need to think up new approaches.
Some of the existing tools that show margins/borders/padding are good.
A tool that would take a float and indicate which exact rules from the
CSS spec, applied to which boxes, forced it down to the position it's at
would be useful.
A tool that allows me to easily view computed styles would be useful; we
need to implement a Gecko api for this....
A tool that indicates which margins collapsed with which other margins
would be useful.
A tool that indicates exactly which kid of a shrink-wrapping box caused
it to not shrink below the width it is right now would be useful.
> On the other hand, runtime state manipulation seems primarily to be
> addressing failings in source development tools, not debuggers. CSS/HTML
> are very complex: devs rarely understand the nuances of |disabled| we
> discuss here. Modifying the runtime values of an element to experiment
> is a powerful why to learn. The feedback is immediate and you can focus
> on just a single aspect of a complex problem.
Agreed that this is a good use for runtime state manipulation.
>> Yes, and I'm arguing that it's the presentation that's wrong here.
>
> What presentation would be right?
If I knew I would have suggested it. :(
-Boris
Cedric Vivier
> A tool that would take a float and indicate which exact rules from the CSS
> spec, applied to which boxes, forced it down to the position it's at would
> be useful.
> A tool that indicates exactly which kid of a shrink-wrapping box caused it
> to not shrink below the width it is right now would be useful.
Good news is that such a tool is already being developed :)
https://wiki.mozilla.org/DevTools/Features/CSSDoctor
</offtopic>
Cheers,
Neil
> A tool that allows me to easily view computed styles would be useful;
> we need to implement a Gecko api for this....
Doesn't DOM Inspector already do this? (But annoyingly when you switch
elements it scrolls back to the top of the list...)
> A tool that indicates exactly which kid of a shrink-wrapping box
> caused it to not shrink below the width it is right now would be useful.
Not quite the same, but in XUL I fake this by toggling the parent's
align attribute between start and end and look to see what doesn't move ;-)
--
Warning: May contain traces of nuts.
Jeff Hammel
> On 6/6/11 6:30 PM, Kyle Simpson wrote:
>> We're for instance not at all
>> concerned with representing in the devtools the invalid DOM that is
>> created by <b><u>foobar</b></u>
>
> This creates a valid DOM in all modern browsers. The fact that you
> think it doesn't is troubling. :(
>
wrt multiple ids (and variations on the theme).
johnjbarton
> On 6/6/11 10:01 PM, johnjbarton wrote:
> A tool that would take a float and indicate which exact rules from the
> CSS spec, applied to which boxes, forced it down to the position it's at
> would be useful.
I've been thinking that we should be trying to think of more "global" or
"multibox" tools for this kind of issue. Maybe its easier to express the
result in terms of the 'voids'. For example, a centered box gets its
position by balancing the voids on each side, so the layout dramatically
changes as a function of the container width just at the point where
voids appear. Generally the problem with layout debug is that it is
based on multibox rules but our tools only reveal single box positions.
>
> A tool that allows me to easily view computed styles would be useful; we
> need to implement a Gecko api for this....
Can you say more about this one? Rob added Computed side panel to
Firebug some time ago and it is synchronized with the inspect function.
What is missing?
>
> A tool that indicates which margins collapsed with which other margins
> would be useful.
I guess we have to infer the collapse based on the positions? The
compute part seems easy enough, just compare to four adjacent boxes. The
UI could show the collapsed margin in different style.
>
> A tool that indicates exactly which kid of a shrink-wrapping box caused
> it to not shrink below the width it is right now would be useful.
>
Yes, that seems useful.
jjb
Boris Zbarsky
> Boris Zbarsky wrote:
>> A tool that allows me to easily view computed styles would be useful;
>> we need to implement a Gecko api for this....
>
> Doesn't DOM Inspector already do this?
No, it shows the return values of getComputedStyle(), which are NOT
actually CSS2.1 computed styles.
> (But annoyingly when you switch elements it scrolls back to the top of the list...)
Yes, that's dumb too.
>> A tool that indicates exactly which kid of a shrink-wrapping box
>> caused it to not shrink below the width it is right now would be useful.
>
> Not quite the same, but in XUL I fake this by toggling the parent's
> align attribute between start and end and look to see what doesn't move ;-)
Yes, the "poke the document" debugging method when all else has failed... ;)
-Boris
Boris Zbarsky
>> A tool that allows me to easily view computed styles would be useful; we
>> need to implement a Gecko api for this....
>
> Can you say more about this one? Rob added Computed side panel to
> Firebug some time ago and it is synchronized with the inspect function.
> What is missing?
As I said to Neil, you're showing the result of the DOM getComputedStyle
API. This is a bizarre frankenmix of CSS 2.1 used style and CSS 2.1
computed style, because it implements the quite different notion of
"computed style" from CSS2.
What's missing are Gecko APIs to expose CSS2.1 computed and used styles
and then devtool UI to show those.
>> A tool that indicates which margins collapsed with which other margins
>> would be useful.
>
> I guess we have to infer the collapse based on the positions?
Well, that's the hard question, yes. How does the devtool figure this
out? Can Gecko help somehow? I just don't know; I'm not sufficiently
familiar with the margin-collapsing code.
-Boris
Rob Campbell
On 2011-06-07, at 13:05, Boris Zbarsky wrote:
> On 6/7/11 8:26 AM, johnjbarton wrote:
>>> A tool that allows me to easily view computed styles would be useful; we
>>> need to implement a Gecko api for this....
>>
>> Can you say more about this one? Rob added Computed side panel to
>> Firebug some time ago and it is synchronized with the inspect function.
>> What is missing?
>
> As I said to Neil, you're showing the result of the DOM getComputedStyle API. This is a bizarre frankenmix of CSS 2.1 used style and CSS 2.1 computed style, because it implements the quite different notion of "computed style" from CSS2.
>
> What's missing are Gecko APIs to expose CSS2.1 computed and used styles and then devtool UI to show those.
This sounds bugworthy. Really, a refresh of iniDOMUtils would be great.
[snip!]
~ rob
Jonas Sicking
> On 6/7/11 8:26 AM, johnjbarton wrote:
>>>
>>> A tool that allows me to easily view computed styles would be useful; we
>>> need to implement a Gecko api for this....
>>
>> Can you say more about this one? Rob added Computed side panel to
>> Firebug some time ago and it is synchronized with the inspect function.
>> What is missing?
>
> As I said to Neil, you're showing the result of the DOM getComputedStyle
> API. This is a bizarre frankenmix of CSS 2.1 used style and CSS 2.1
> computed style, because it implements the quite different notion of
> "computed style" from CSS2.
And fixing getComputerStyle to return the CSS 2.1 computed style would
break the web or be undesirable in some other way?
/ Jonas
Boris Zbarsky
> And fixing getComputerStyle to return the CSS 2.1 computed style would
> break the web
Yep. In particular, in this example:
<div style="width: 400px">
<p style="width: 50%"></p>
</div>
the CSS 2.1 computed width for the <p> is "50%" but the web depends on
getting "200px" when using getComputedStyle there.
-Boris
johnjbarton
Why would we want 50% here?
jjb
>
> -Boris
Boris Zbarsky
We would want two different APIs: one that returns 50% and one that
returns 200px. Those are the computed and used style respectively.
The reason we would want that is that there are two separate questions
one would want to ask here:
1) What is the width of this <p>?
2) Why does it have that width?
The answer to #1 is "200px". The answer to #2 is "The computed width is
50% and the containing block width is 400px".
-Boris
Neil
> On 6/7/11 2:26 AM, Neil wrote:
>
>> Boris Zbarsky wrote:
>>
>>> A tool that allows me to easily view computed styles would be
>>> useful; we need to implement a Gecko api for this....
>>
>> Doesn't DOM Inspector already do this?
>
> No, it shows the return values of getComputedStyle(), which are NOT
> actually CSS2.1 computed styles.
OK, so assuming getComputedStyle() returns what it's supposed to, how do
CSS2.1 computed styles differ?
Kyle Simpson
>>>> break the web
>>>
>>> Yep. In particular, in this example:
>>>
>>> <div style="width: 400px">
>>> <p style="width: 50%"></p>
>>> </div>
>>>
>>> the CSS 2.1 computed width for the <p> is "50%" but the web depends on
>>> getting "200px" when using getComputedStyle there.
>>
>> Why would we want 50% here?
>
> We would want two different APIs: one that returns 50% and one that
> returns 200px. Those are the computed and used style respectively.
>
> The reason we would want that is that there are two separate questions
> one would want to ask here:
>
> 1) What is the width of this <p>?
> 2) Why does it have that width?
>
> The answer to #1 is "200px". The answer to #2 is "The computed width is
> 50% and the containing block width is 400px".
Minor nitpick, but it bugs me and is confusing to call something like "50%"
the "computed width" (though I understand "computed" probably means "the
result of all the cascading and rules applications"). "Computed" really
sounds like "the browser has already figured out what the width should be",
which to me would imply that the 50% has already been calculated to be
200px.
I wish that some naming less confusing was used, such as "applicableStyle"
for the style that will apply to that element ("50%") after all the CSS
rules have been consulted and "computed", and "computedStyle" for the real
actual after-calculation number (200px).
But, I'm guessing that naming change would screw everything up... so what
about (as it currently is) "computedStyle" for the 50%, but
"calculatedStyle" for the 200px?
--Kyle
Boris Zbarsky
>> No, it shows the return values of getComputedStyle(), which are NOT
>> actually CSS2.1 computed styles.
>
> OK, so assuming getComputedStyle() returns what it's supposed to, how do
> CSS2.1 computed styles differ?
CSS2.1 computed styles never depend on layout.
-Boris
Boris Zbarsky
> Minor nitpick, but it bugs me and is confusing to call something like
> "50%" the "computed width"
Talk to the CSS working group?
> (though I understand "computed" probably
> means "the result of all the cascading and rules applications").
It means more than that. For example, if the width were specified as
"50em" then the computed value would be in pixels and would depend on
the computed value of font-size.
The "result of all the cascading" is the specified value.
May I suggest just reading
http://www.w3.org/TR/CSS21/cascade.html#value-stages ? It's about one
page of text.
> I wish that some naming less confusing was used, such as
> "applicableStyle" for the style that will apply to that element ("50%")
> after all the CSS rules have been consulted and "computed", and
> "computedStyle" for the real actual after-calculation number (200px).
As you will see if you read the link above, there are actually 4
different values involved.
> But, I'm guessing that naming change would screw everything up... so
> what about (as it currently is) "computedStyle" for the 50%, but
> "calculatedStyle" for the 200px?
How you want to name them will probably depend on whether you want your
naming to match the naming in the CSS specification. If you choose to
not match it, I would recommend using a disjoint set of names, though,
not names that are the same but mean something different.
-Boris
Neil
So you mean the values returned by aFrame->GetStylePosition() which are
then used by layout to calculate the actual dimensions returned by
getComputedStyle()?
Boris Zbarsky
> Boris Zbarsky wrote:
>
>
> So you mean the values returned by aFrame->GetStylePosition() which are
> then used by layout to calculate the actual dimensions returned by
> getComputedStyle()?
Pretty much, yes.
-Boris