- From: <bugzilla@jessica.w3.org>
- Date: Fri, 09 Aug 2013 08:07:23 +0000
- To: public-css-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22772 --- 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, sorry. > > (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 it. 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 convertDim(cssValueString,toDimensionString) 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