[Bug 22772] width, height, top, left attributes or properties that always work


--- Comment #2 from Jim Michaels <jmichae3@yahoo.com> ---
(In reply to comment #1)
> What's the use case?

I am not that familiar with UML diagramming to know what to do with use cases,

> (In reply to comment #0)
> > these need to be accessible especially from css attr(), calc(), and also
> > from javascript,
> Why?

when accessing <div id="abc">hello</div> for the first time, if there is no css
specifically setting these properties, you can't get them from js as much as
you might want to (such as if you needed to move things around dynamically, but
relatively or absolutely or shackled, etc whatever). one could argue that you
could do a fixed job quite well with css, but js adds more functionality, that
would be much more functional IF these properties were simply not blank when
you access them before setting them. meaning, they should always have a value
specifying the current location and size of the element. but right now they do
not. this makes them unusable in some situations (like when you wish to do work
with layers and relative positioning to top of page or to another element which
may be in another layer). currently, layer element flow and the model for
handling these attributes/properties prevents this.

I have a web page where I attempted to do these kinds of things, but failed
miserably and found no workarounds to find the current location and size of an
element. if you have an alternative you can come up with which would solve this
problem, I should like to see it. seeing the names, I figured these were
best-fit and mnemonic and easy to figure out for everyone who would want to use

I am unsure why these properties are blank before setting in the first place.
isn't that a bug? has nobody questioned it for years? why is it this way?

> > these need to be accessible when the element is available (when loaded).
> Styles might not have been applied yet when the element is first available...

I already knew that from testing. precisely why I wrote this bug report (I am
sure I wrote it well enough and put in good details) - and why I was unable to
make some projects with CSS layers (z-index) and positioning I wanted. I didn't
think "it's just not available yet" was a good excuse for not making the
current position and size of an element available, always, somehow,
cross-platform. this seemed the best way to do it.
I can't show you an example of what I am talking about, because it's not
implementable the way things are now. I am just saying instead of blank, it
should have a nice default value, or, some kind of properties should be
available which do supply these things.

current issues I can think of for browser implementation are:
- the return value: you could argue for A. an expectation for a certain kind of
dynamic number but always with the same dimension such as left:243px; or
left:246 but this might conflict with being able to return the value a web
developer sets unless you make a whole new set of properties that do the needed
functionality, or B. a default value which may be DIFFERENT from the value a
web developer sets with js or CSS. for instance, the default value may be for
example 12em or 20px (for convenience) if it has text in it or 480px if an img,
but web developer may set a value like 
- for B. or just general handiness for calc() and js, making the css available
in other dimensions, such as a css property value dimension conversion function
in JS like 
el.convertDim(cssPropertyNameString, toDimensionString) 
and css function like 
the browser has the dimensions already inside itself and knows internally what
the conversions are I should guess in some internal variables in a class or
something. this is just exposing this as functions. without these, it's going
to be hard to manage differing dimensions (such as converting between em and
px). in fact, it already is difficult without these.

> > currently, unless you have specified an element's height and width, there is
> > no way to get the element's width and height values. 
> Is getComputedStyle() not sufficient?

based on my cross-major-browser testing, getComputedStyle() doesn't work on all
platforms (it's just not available on everything, .style is not available on
all platforms, and .style[] I think it was is not available on all platforms,
.setAttribute() clobbers a whole style, and ). need something that works for
modifying styles cross-platform too, but I guess that would be a separate bug
for me to report. :-) in fact, I have found NO code that is fully
cross-browser. see the code in o'reilly's javascript cookbook page 265 to see
what I mean - I did a lot of googling for this. I tried nearly everyone's
"cross-browser" code in all major browsers and nothing worked cross-browser in
safari, chrome, IE10, ff, o, but have not tested jquery yet. I didn't want to
have to load 250k of heavy source to just change a style.

You are receiving this mail because:
You are the QA Contact for the bug.

Received on Friday, 9 August 2013 08:07:24 UTC