0.40-beta2 alignment issues in Chrome and Firefox
Sean Gilligan
".row" that shows in the latest Chrome and Firefox.
This page shows the issue:
http://demo.iui-js.org/samples/music/music.html#_settings
This seems to be a fix:
https://github.com/msgilligan/msgilligan.github.com/commit/ae99524945dc940c7581203cad6a3add3cd996a1
Will the "fix" break anything else?
-- Sean
Sean Gilligan
> We've got a visual problem with alignment in ".panel > fieldset" and
> ".row" that shows in the latest Chrome and Firefox.
This also seems to be showing up as Issue #329.
http://code.google.com/p/iui/issues/detail?id=329
Rémi Grumeau
It's also out of 0.5.
Remi
> --
> You received this message because you are subscribed to the Google Groups "iui-developers" group.
> To post to this group, send email to iui-dev...@googlegroups.com.
> To unsubscribe from this group, send email to iui-developer...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/iui-developers?hl=en.
>
Sean Gilligan
> This text align right has always been a bad idea...
> It's also out of 0.5.
Mike Xu recommends setting top and left (since the positioning is
absolute, they should be set) which also fixes the problem. Maybe I
should make both changes in 0.40-beta3?
-- Sean
Remi Grumeau
Remi
On 23 mars 2012, at 09:00 AM, Sean Gilligan <se...@msgilligan.com> wrote:
Remi Grumeau
http://we-are-gurus.com/iui/0.4b2/samples/music/music.html#_settings
Remi
Sean Gilligan
> To fix it, just remove "text-align: right" from iui.css on line 274 &
> line 284
> in 0.4b2 without fix
> http://we-are-gurus.com/labs/iui/issues/90/
If you look at 0.4b2 without the fix, you'll see that ".row > label" is
positioned absolutely. If you set "top" and "left" both to "0px" that
*also* fixes the problem.
Mike Xu says you shouldn't use "absolute" without specifying coordinates
because otherwise different browsers may chose different defaults.
So, I'm thinking we should do *both*: remove the 2 "text-align: right"
properties *and* add the top/left. Does that make sense?
> This seems like a really old bug:
> http://code.google.com/p/iui/issues/detail?id=90
Thanks for this link: I closed Issue #329 as a duplicate of #90.
It's an old bug that keeps coming back. I think it's been "fixed" more
than once (maybe like 3 times). In fact, I think you made (another) fix
for this in an earlier 0.40-xxxxn release. I'd like to kill it once and
for all. I'm just concerned that if we fix it for the latest Chrome and
FF another issue might show up in another browser. We've made local
fixes several times now and the bug keep re-appearing. Do you think
changing both of these things is going to solve it once and for all?
-- Sean
Sean Gilligan
the main repo:
http://code.google.com/p/iui/source/detail?r=d1fa74d17c1b1335368d10ccc4e52ebbf3c9eab4
I'm still wondering if we should add top/left to some of the "position:
absolute" elements in iui.css...
-- Sean
Remi Grumeau
--
You received this message because you are subscribed to the Google Groups "iui-developers" group.
To post to this group, send email to iui-developers@googlegroups.com.
To unsubscribe from this group, send email to iui-developers+unsubscribe@googlegroups.com.
Sean Gilligan
> I did add an absolute positionning to label so the input field can use
> the full height and width of the row, just like native.
> Absolute positionning keeps the same position if you don't give it any
> top / left position. Aboslute is absolute so a top position is top...
> of the screen, not top of its parent element.
>
> It seems we need a float: right on select & input checkbox/radio too.
Thanks, Remi!
-- Sean
Eric Lindsey
position: relative or position: absolute in the DOM. So if parent
element has position: relative (with no left or top specified) then it
will remain in place but it changes the behavior of all child elements
with position: absolute to be absolutely positioned relative to said
parent element. Not sure if this information is of any use but I
thought I'd volunteer it anyways.
On Mar 26, 3:51 am, Remi Grumeau <remi.grum...@gmail.com> wrote:
> I did add an absolute positionning to label so the input field can use the
> / left position. Aboslute is absolute so a top position is top... of the
> screen, not top of its parent element.
>
> It seems we need a float: right on select & input checkbox/radio too.
>
> Line 300 in iui.css
> .row > input[type|=radio], .row > input[type|=checkbox] {
> margin: 7px 7px 0 0;
> height: 25px;
> width: 25px;
>
> }
>
> by
>
> .row > input[type|=radio], .row > input[type|=checkbox],
> .row > select {
> float: right;
> margin: 7px 7px 0 0;
> height: 25px;
> width: 25px;}
>
> .row > select {
> width: auto;
> margin: 9px 7px 0 0;
>
> }
>
> result before / after:http://cl.ly/0w1J2G341m0O3C1F4504
>
> Remi
>
>
>
>
>
>
>
> On Sun, Mar 25, 2012 at 9:34 AM, Sean Gilligan <s...@msgilligan.com> wrote:
> > OK, the text-align: right's have been removed and it is in "master" on the
> > main repo:
> > d1fa74d17c1b1335368d10ccc4e52e**bbf3c9eab4<http://code.google.com/p/iui/source/detail?r=d1fa74d17c1b1335368d10cc...>
> > I'm still wondering if we should add top/left to some of the "position:
> > absolute" elements in iui.css...
>
> > -- Sean
>
> > On 3/23/12 12:40 PM, Sean Gilligan wrote:
>
> >> On 3/23/12 10:37 AM, Remi Grumeau wrote:
>
> >>> To fix it, just remove "text-align: right" from iui.css on line 274 &
> >>> line 284
> >>> in 0.4b2 without fix
> >> If you look at 0.4b2 without the fix, you'll see that ".row > label" is
> >> positioned absolutely. If you set "top" and "left" both to "0px" that
> >> *also* fixes the problem.
> >> Mike Xu says you shouldn't use "absolute" without specifying coordinates
> >> because otherwise different browsers may chose different defaults.
>
> >> So, I'm thinking we should do *both*: remove the 2 "text-align: right"
> >> properties *and* add the top/left. Does that make sense?
>
> >> This seems like a really old bug:
> >> Thanks for this link: I closed Issue #329 as a duplicate of #90.
>
> >> It's an old bug that keeps coming back. I think it's been "fixed" more
> >> than once (maybe like 3 times). In fact, I think you made (another) fix
> >> for this in an earlier 0.40-xxxxn release. I'd like to kill it once and
> >> for all. I'm just concerned that if we fix it for the latest Chrome and FF
> >> another issue might show up in another browser. We've made local fixes
> >> several times now and the bug keep re-appearing. Do you think changing
> >> both of these things is going to solve it once and for all?
>
> >> -- Sean
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "iui-developers" group.
> > .
> > To unsubscribe from this group, send email to iui-developers+unsubscribe@*
> > *googlegroups.com <iui-developers%2Bunsu...@googlegroups.com>.
> > For more options, visit this group athttp://groups.google.com/**
> > group/iui-developers?hl=en<http://groups.google.com/group/iui-developers?hl=en>
> > .
Remi Grumeau
Remi
To post to this group, send email to iui-dev...@googlegroups.com.
To unsubscribe from this group, send email to iui-developer...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/iui-developers?hl=en.
Eric Lindsey
code you're talking about, I'm just chiming my $.02 based on what you
guys have been remarking on. Could somebody point me to a page where
the problem exists? Cause I don't see it anymore. ;)
It sounds to me (I hope I'm interpreting your previous comments
correctly) like you're running into the label problem I had when I
tried to make my own simplified Apple-looking style.
If we have:
<div>
<label for="item">Username</label>
<input id="item" />
</div>
Then what you want to do is assign position: relative to the DIV, then
position: absolute to the LABEL and INPUT. Or whatever HTML elements
are actually being used. That will cause the DIV to not move anywhere
in the document, but make all the position: absolute on child elements
relative to it, making it easy to say, put a 33%/67% width split on
the items without having to use floats.
If you point me towards a page that still has the bug you're trying to
eliminate (since I haven't gotten to see it in action yet) I may be
able to provide more insight. I hope I'm not totally off base on what
you guys are trying to do. :)
Rémi Grumeau
Keeping the input element in relative makes the div height adapt itself based on the input one (without using some overflow: hidden crappy hack)
Sent from my iPad
Sean Gilligan
> Haha. I'd love to join this conversation, but I don't even know what
> code you're talking about, I'm just chiming my $.02 based on what you
> guys have been remarking on. Could somebody point me to a page where
> the problem exists? Cause I don't see it anymore. ;)
The problem occurs in 0.40-beta2, which you can see here:
http://iui.googlecode.com/git-history/REL-0.40-beta2/web-app/samples/music/music.html
> If you point me towards a page that still has the bug you're trying to
> eliminate (since I haven't gotten to see it in action yet) I may be
> able to provide more insight. I hope I'm not totally off base on what
> you guys are trying to do. :)
I would appreciate your input. I'm looking for a solution that will
work for all use cases -- so we have to be careful not to fix it in one
place and break it in others.
Thanks!
-- Sean
Sean Gilligan
> http://code.google.com/r/remigrumeau-iui-dev/source/detail?r=b4cf95b6e2c3232e0853ea23c8eaa273fe77e67f&name=remigrumeau-navigation
> <http://code.google.com/r/remigrumeau-iui-dev/source/detail?r=b4cf95b6e2c3232e0853ea23c8eaa273fe77e67f&name=remigrumeau-navigation>
Thanks for these changes, Remi. They are in 'master', here:
http://code.google.com/p/iui/source/detail?r=c1edfba1c31fdc9fc5c38849a66eb6ca222833ae
and here:
http://code.google.com/p/iui/source/detail?r=42dde7bf260e3e95208ee0d5c2f0c009eaa6e625
I also pushed to http://stage.iui-js.org/
The "arrays" view of the form-test.html page now has radio buttons,
checkboxes, and a select:
http://stage.iui-js.org/test/form-test.html#_arrays
Additional testing, feedback, and/or comments welcome.
-- Sean
p.s. I merged Issue #197
<http://code.google.com/p/iui/issues/detail?id=197> into Issue #90
<http://code.google.com/p/iui/issues/detail?id=90>
Remi Grumeau
Remi
Sean Gilligan
> Can we release 0.4 now ? :)
We've made significant changes since beta2, I think we should call the
next release beta3. I think we should propose that to the list and see
if there are any issues that should be fixed before a beta3. If not, we
can make a beta3 right away. We can consider beta3 a final candidate, I
think.
-- Sean
Remi Grumeau
Remi
Sean Gilligan
> Then what about calling it RC1 ?
Yeah, that's a good idea.
-- Sean
Michael nietzold
Von meinem iDingens gesendet...
Am 04.04.2012 um 01:12 schrieb Sean Gilligan <se...@msgilligan.com>:
> On 3/26/12 1:51 AM, Remi Grumeau wrote:
>> It seems we need a float: right on select & input checkbox/radio too.
>> see
>> http://code.google.com/r/remigrumeau-iui-dev/source/detail?r=b4cf95b6e2c3232e0853ea23c8eaa273fe77e67f&name=remigrumeau-navigation <http://code.google.com/r/remigrumeau-iui-dev/source/detail?r=b4cf95b6e2c3232e0853ea23c8eaa273fe77e67f&name=remigrumeau-navigation>
>
>
> Thanks for these changes, Remi. They are in 'master', here:
> http://code.google.com/p/iui/source/detail?r=c1edfba1c31fdc9fc5c38849a66eb6ca222833ae
> and here:
> http://code.google.com/p/iui/source/detail?r=42dde7bf260e3e95208ee0d5c2f0c009eaa6e625
>
> I also pushed to http://stage.iui-js.org/
> The "arrays" view of the form-test.html page now has radio buttons, checkboxes, and a select:
> http://stage.iui-js.org/test/form-test.html#_arrays
>
> Additional testing, feedback, and/or comments welcome.
If i open this form on iphone and i click on dialog.
I was thinking this dialog is modal, but i see this problems:
A) Then i can scroll down but the mask is not over the submit button (see pic)
Sean Gilligan
> If i open this form on iphone and i click on dialog.
> I was thinking this dialog is modal, but i see this problems:
>
> A) Then i can scroll down but the mask is not over the submit button (see pic)
This has been reported as Issue #203 and there is a patch:
http://code.google.com/p/iui/issues/detail?id=203
> B) if i am in the form and i am in the param1 field then i can click on the keyboard previous button (on my screenshot the "zur�ck" button): and i am now i the dropdown field from the underlaying form and not from the dialog:
Any idea what is causing this?
-- Sean
Remi Grumeau
>
> Any idea what is causing this?
>
> -- Sean
the same behavior can be seen with the first GET panel, where the two inputs in the background get selectee too.
i guess Safari provides by next/previous buttons a way to navigate tru all active inputs displayed on the page. let's take a look at how this behave on other frameworks but honnestly it sounds like a browser native feature we could only "change" by adding a readonly attribute to non active inputs. And i would be strongly against it, sonce it would do more trouble than it solves.
Remi
Sean Gilligan
>>> B) if i am in the form and i am in the param1 field then i can click on the keyboard previous button (on my screenshot the "zurück" button): and i am now i the dropdown field from the underlaying form and not from the dialog:
>> Any idea what is causing this?
>>
>> -- Sean
> the same behavior can be seen with the first GET panel, where the two inputs in the background get selectee too.
I see it there, too.
I created an Issue:
http://code.google.com/p/iui/issues/detail?id=334
Not a showstopper for 0.4.0 in my opinion, but hopefully we can find a
clean fix for it. Maybe some elves will see the Issue and submit a nice
fix... ;)
-- Sean
Remi Grumeau
Not a showstopper for 0.4.0 in my opinion, but hopefully we can find a clean fix for it. Maybe some elves will see the Issue and submit a nice fix... ;)
-- Sean