Some of the things I want to improve are listed in this post. (None of the ideas listed here are really new, it’s just that nobody gets around to actually do it.) I want to enable better style sheet manipulation. Being able to retrieve the pixel value of the width property of some element as a number using element.currentStyle.width.px in a way that is still compatible with what element.currentStyle.width currently does in Internet Explorer. This also enables you to do fancy things like element.currentStyle.width.px++ et cetera. I’m hoping to get to this during the summer. Should be a fun project.
I want to improve the read-write web so that WYSIWYG editing tools become easier to write for everyone and we no longer have to fiddle around with markup on the web when publishing weblog entries or comments. A good first step is having implementations of contenteditable, but that doesn’t solve the whole problem:
In general, I want to improve the building blocks of the “browsable web.” Doing things like XMLHttpRequest (see the XMLHttpRequest interface specification), document.matchAll("body > div:last-of-type") (see the Selectors API specification) will hopefully help with that.
Actually, on a technical level using width.px is virtually impossible, as it would require a new Number type. It is a nice shorthand though. Something I’d also like is to be able to get both the original CSS value and a pixel value.
It would not require a new Number type. Why would it? You can of course still get to the original CSS value as well using width.cssText or just width or something like that.
The idea behind having width.px is that you no longer need to have the unit in there so you can use the basic Number type in ECMAScript and something like unsigned long or whatever in your IDL.
currentStyle.width returns a string (sorry, not a number) in Internet Explorer. Adding a px property (getter/setter method, actually, with regards to px++) would make it a special string which you can’t just use in other locations:
var s = node.currentStyle.width;
s.px++; // What should happen here?
Fascinating post.
Regarding width.px isn't that just the same as the computed style seen in Mozilla's DOM Inspector? So if a table is set to 50% width, it might be displayed in reality as 504px.
...We no longer have to fiddle around with markup on the web when publishing weblog entries or comments.
You mean like on this site? :-)
"Pixel perfect control" over your markup.
I'm not sure that is a good wish. Designers often say the web does not lead to pixel-perfect layouts, as each browser displays things differently, user settings can override the layout as well, such as enlarged fonts, or disabled CSS, etc, etc. We should do away with the utopian idea of a pixel-perfect web.
Mark, the same as with location and location.href. “Magic.” For languages other than ECMAScript you use binding-specific casting methods.
location is an instance of Location in Gecko, and setting location = 'about:blank' is magic on the window object. This is a bit different from what you are proposing.
Since, AFAIK, .currentStyle is a proprietary IE only property, the DOM 2 way of achieving it is like this:
window.getComputedStyle(element, null).getPropertyValue("width")Note: The element variable in that code would need to be assigned an Element node.
That returns a string with the value and unit, both Firefox and Opera return it as px for width, regardless of the unit used in the CSS. Extending it to be able to return a value in a specific unit (for properties whose values are numeric) as an integer or long would be useful. At present, we'd have to split the string with a regex and parse an integer from the value.
We should do away with the utopian idea of a pixel-perfect web.
Anne meant there “Pixel perfect control” over your markup, not presentation.
Lachlan, what’s wrong with parseInt()?
Anne meant there “Pixel perfect control” over your markup, not presentation.
That's fine, but what does "pixel-perfect" mean in a markup context? This is not at all obvious to me.
Mark, yeah, the type of the attribute might have to change. Still looking into that.
Lachlan, it is indeed. My plan is to standardize it and perhaps do the same with runtimeStyle which is also quite useful. (They would both live on some CSSElement interface.) Note that it’s wrong to return pixel values for getComputedStyle given that the specification says it returns absolute values. However, I guess the specification might need to be changed to match implementation practice as I guess sites will rely on it by now.
J. King, it means you can predict (exactly) how your source will look like after performing a certain editing operation.
Note that it's wrong to return pixel values for
getComputedStylegiven that the specification says it returns absolute values.
But the computer screen can only work in pixels, so that is what it must compute. (And yeah, the spec is wrong then.)
Hmmm, I notice in Opera 9 that the list numbers in comments that start with a blockquote appear lower down, next to the replies! So in comment 13 above, the number appears next to the words "But the computer screen". That's odd. I tracked it down to position:relative being applied to the blockquote element in Anne's stylesheet. I also made a bug page and reported it to Opera:
Thanks Chris, known bug though.