Inputveld met daarna een .NET MVC Validation box

[F.West98]

Let op: Afgesplitst vanuit De Devschuur Coffee Corner - Iteratie 4

Zit in CSS nu bezig, browsercontrole:
Firefox, prima
IE10, prima
IE9, prima
IE8, prima (kleine bug, maar dat ligt aan geen rgba)
Chrome, TOTAAAL NIET, TOTAL DISASTER.

Argh.

[ Voor 21% gewijzigd door Creepy op 10-09-2013 22:44 ]

[Verwijderd]

F.West98 schreef op dinsdag 10 september 2013 @ 16:41:
Zit in CSS nu bezig, browsercontrole:
Firefox, prima
IE10, prima
IE9, prima
IE8, prima (kleine bug, maar dat ligt aan geen rgba)
Chrome, TOTAAAL NIET, TOTAL DISASTER.

Argh.

Je vergeet Opera

[MoietyMe]

F.West98 schreef op dinsdag 10 september 2013 @ 16:41:
Zit in CSS nu bezig, browsercontrole:
Firefox, prima
IE10, prima
IE9, prima
IE8, prima (kleine bug, maar dat ligt aan geen rgba)
Chrome, TOTAAAL NIET, TOTAL DISASTER.

Argh.

Je vergeet Safari.

[Verwijderd]

Good Fella schreef op dinsdag 10 september 2013 @ 16:49:
[...]

Je vergeet Safari.

En IE6

[ Voor 89% gewijzigd door Verwijderd op 10-09-2013 16:51 ]

[F.West98]

Het is voornamelijk voor gemeentes, dus IE8 is belangrijk
Maar inmiddels al *brrr* gefixt in Chrome:

Cascading Stylesheet:

@media screen and (-webkit-min-device-pixel-ratio: 0) {
   ...
}

[MoietyMe]

F.West98 schreef op dinsdag 10 september 2013 @ 16:51:
Het is voornamelijk voor gemeentes, dus IE8 is belangrijk
Maar inmiddels al *brrr* gefixt in Chrome:

Cascading Stylesheet:

@media screen and (-webkit-min-device-pixel-ratio: 0) {
   ...
}

Zou je het niet gewoon in moderne browsers oplossen en dan terug werken naar IE9 en IE8.

[F.West98]

Good Fella schreef op dinsdag 10 september 2013 @ 17:48:
[...]

Zou je het niet gewoon in moderne browsers oplossen en dan terug werken naar IE9 en IE8.

Helaas, het werkt dus wel in Firefox, maar in Chrome een verkleining nodig met 2px van een voorwerp, en een calc width wordt niet overal ondersteund, dan liever zo

Verder:
jQuery UI elementen stylen, vreselijk.
Kies ik bewust een negatieve margin top voor overlap, gaat het script overcompenseren

[R4gnax]

F.West98 schreef op dinsdag 10 september 2013 @ 19:17:
Helaas, het werkt dus wel in Firefox, maar in Chrome een verkleining nodig met 2px van een voorwerp

Als ik dat hoor krijg ik de indruk dat je ergens verkeerd bezig bent. Of je bent voor een pixel-nazi aan het werken die verwacht dat input velden overal op de pixel consistent renderen. (In welk geval je hem/haar eens een paar verschillende smaakjes van mobile device browsers moet laten zien zodat duidelijk wordt dat die dingen in de verste verte niet compleet hetzelfde te maken zijn.)

[F.West98]

Situatieschets:
Inputveld met daarna een .NET MVC Validation box.
Dat is een span met daarin een span met een eventuele error.
Wat ik doe, is die span een position absolute geven, waardoor hij over andere elementen heenvalt. Width van input is 100%.
Onhover de span (die doorzichtig is en uitlijnt rechts van de input, waar ook een icoontje staat met dat er een error is), klapt de subspan uit met de melding in een ballonnetje.
Nou is het zo dat in FF en IE8-10 die span keurig rechts in de regel komt te staan, over de input heen.
In Chrome komt 'ie op de volgende regel te staan, en dus totaal ergens anders. Pas als ik de width van de input met 3px kleiner maak gaat het goed.....

En IE deed geen onhover in de input als de span geen achtergrond had, dus maar een rgba(0,0,0,0) meegegeven)
IE8 heeft totaal iets anders.

Bijgevoegd jsfiddle:
http://jsfiddle.net/H4xD8/
Firefox werkt wel, Chrome niet.

[kaesve]

F.West98 schreef op dinsdag 10 september 2013 @ 21:45:
Situatieschets: ...

Volgens mij is wat chrome doet helemaal niet zo gek hoor. Je hebt je .error absoluut gepositioneerd, maar geen coordinaten gespecificeerd. Ik kan zo snel niet vinden wat de specs daarover zeggen, maar chrome rendert hem op de plek waar .error normaal zou komen. In dit geval zou je het makkelijk kunnen fixen met:

Cascading Stylesheet:

div {
  width: 300px;
  white-space: nowrap;
}

[Douweegbertje]

F.West98 schreef op dinsdag 10 september 2013 @ 21:45:
Situatieschets:
Inputveld met daarna een .NET MVC Validation box.
Dat is een span met daarin een span met een eventuele error.
Wat ik doe, is die span een position absolute geven, waardoor hij over andere elementen heenvalt. Width van input is 100%.
Onhover de span (die doorzichtig is en uitlijnt rechts van de input, waar ook een icoontje staat met dat er een error is), klapt de subspan uit met de melding in een ballonnetje.
Nou is het zo dat in FF en IE8-10 die span keurig rechts in de regel komt te staan, over de input heen.
In Chrome komt 'ie op de volgende regel te staan, en dus totaal ergens anders. Pas als ik de width van de input met 3px kleiner maak gaat het goed.....

En IE deed geen onhover in de input als de span geen achtergrond had, dus maar een rgba(0,0,0,0) meegegeven)
IE8 heeft totaal iets anders.

Bijgevoegd jsfiddle:
http://jsfiddle.net/H4xD8/
Firefox werkt wel, Chrome niet.

Maak gewoon even wat fatsoenlijks. Ik heb er even naar gekeken + mee gekloot maar mij ontgaat echt elk praktisch nut ervan. Sowieso.. spans met dit is al apart. Dan moet je er alweer inline-blocks van maken en andere meuk. Daarnaast, een 100% witdh op een input, waarbij je dan EROVER een error wilt geven, die dan ernaast weer uitklapt? Volgens mij maak je het jezelf erg moeilijk. Kom anders met een voorbeeld die is uitgewerkt. Ik heb het in FF gekeken en ik snap namelijk nog niet wat je wilt bereiken.

Overigens kwam ik tot hier; http://jsfiddle.net/H4xD8/7/ maar toen snapte ik je min-widths e.d. niet waarom je dat wilde en stopte ik maar

[ Voor 4% gewijzigd door Douweegbertje op 10-09-2013 22:17 ]

[R4gnax]

F.West98 schreef op dinsdag 10 september 2013 @ 21:45:
Situatieschets:
Inputveld met daarna een .NET MVC Validation box.
Dat is een span met daarin een span met een eventuele error.

Da's dan in elk geval niet echt standaard. De standaard (unobtrusive) client-side validation rendert:

HTML:

<span
  class="field-validation-{valid|error}"
  data-valmsg-for="[fieldname]"
  data-valmsg-replace="true"
></span>

Het zet enkel de validation error message in dat ene span element en schakelt tussen de valid en error CSS class. Het rendert naar mijn weten standaard niet nog een extra span element daar binnen in.

F.West98 schreef op dinsdag 10 september 2013 @ 21:45:
Wat ik doe, is die span een position absolute geven, waardoor hij over andere elementen heenvalt. Width van input is 100%.
Onhover de span (die doorzichtig is en uitlijnt rechts van de input, waar ook een icoontje staat met dat er een error is), klapt de subspan uit met de melding in een ballonnetje.
Nou is het zo dat in FF en IE8-10 die span keurig rechts in de regel komt te staan, over de input heen.
In Chrome komt 'ie op de volgende regel te staan, en dus totaal ergens anders. Pas als ik de width van de input met 3px kleiner maak gaat het goed.....

Ja; goed gegokt. Je doet inderdaad iets verkeerd.

Enkel opgeven van position:absolute zonder deze positie met top, right, bottom en/of left te ankeren plaatst het element weliswaar out-of-flow, maar op de plek waar het in-flow geplaatst zou worden als het niet absoluut gepositioneerd zou zijn. Dus, laten we even kijken naar het non-gepositioneerde scenario:

Je gebruikt een negative margin-left om de breedte van het validatie element terug naar 0 te compenseren in een poging het nog achter de input te krijgen op dezelfde regel. Of dit gaat werken is op twee manieren browser afhankelijk:

Ten eerste hangt het er vanaf of een element met breedte 0 bij een beschikbare ruimte van breedte 0 nog gezien gaat worden als 'passend'. Ten tweede hangt het er vanaf of de negatieve margin door de layout engine verwerkt wordt vóór of nadat de tekstlijn naar de volgende regel gebroken wordt. Voor zover ik weet zijn beiden ongespecificeerd gedrag in de W3 recommendations betreffende het layout model.

Daarnaast wordt er geen rekening gehouden met de breedte van het spatie karakter tussen de input en het validatie element. Beiden zijn inline replaced elements, wat inhoudt dat white-space tussen die elementen in de HTML (ook carriage returns en leading spaces of tabs) zich vertaald gaan zien naar een spatie tussen beide elementen.

F.West98 schreef op dinsdag 10 september 2013 @ 21:45:
En IE deed geen onhover in de input als de span geen achtergrond had, dus maar een rgba(0,0,0,0) meegegeven)
IE8 heeft totaal iets anders.

Wist je dat je dit probleem met het afvangen van pointer interactie voor IE8 en lager (die geen opacity of rgba kleuren ondersteunen) ook op kunt lossen door background-image: url("#") te gebruiken. IE zal vrolijk de huidig ingeladen style sheet pakken (zonder een extra server request) en als bron voor een achtergrond plaatje proberen te gebruiken. Daarin zal IE meteen falen, maar het 'gebroken' achtergrond plaatje (dat IE als transparant rendert) telt nog wel als achtergrond.

[F.West98]

kaesve schreef op dinsdag 10 september 2013 @ 22:15:
[...]


Volgens mij is wat chrome doet helemaal niet zo gek hoor. Je hebt je .error absoluut gepositioneerd, maar geen coordinaten gespecificeerd. Ik kan zo snel niet vinden wat de specs daarover zeggen, maar chrome rendert hem op de plek waar .error normaal zou komen. In dit geval zou je het makkelijk kunnen fixen met:

Cascading Stylesheet:

div {
  width: 300px;
  white-space: nowrap;
}

Hmm.. Goed idee, alleen heb ik af en toe twee inputvelden met een <br> erin staan.

R4gnax schreef op dinsdag 10 september 2013 @ 22:17:
[...]


Da's dan in elk geval niet echt standaard. De standaard (unobtrusive) client-side validation rendert:

HTML:

<span
  class="field-validation-{valid|error}"
  data-valmsg-for="[fieldname]"
  data-valmsg-replace="true"
></span>

Het zet enkel de validation error message in dat ene span element en schakelt tussen de valid en error CSS class. Het rendert naar mijn weten standaard niet nog een extra span element daar binnen in.

Ik heb echt gewoon in mijn broncode:

code:

@Html.EditorFor(model => model.bedrijf.visitAdress)
@Html.ValidationMessageFor(model => model.bedrijf.visitAdress)

En krijg gewoon 2 spans.

[...]

Ja; goed gegokt. Je doet inderdaad iets verkeerd.

Enkel opgeven van position:absolute zonder deze positie met top, right, bottom en/of left te ankeren plaatst het element weliswaar out-of-flow, maar op de plek waar het in-flow geplaatst zou worden als het niet absoluut gepositioneerd zou zijn. Dus, laten we even kijken naar het non-gepositioneerde scenario:

Je gebruikt een negative margin-left om de breedte van het validatie element terug naar 0 te compenseren in een poging het nog achter de input te krijgen op dezelfde regel. Of dit gaat werken is op twee manieren browser afhankelijk:

Ten eerste hangt het er vanaf of een element met breedte 0 bij een beschikbare ruimte van breedte 0 nog gezien gaat worden als 'passend'. Ten tweede hangt het er vanaf of de negatieve margin door de layout engine verwerkt wordt vóór of nadat de tekstlijn naar de volgende regel gebroken wordt. Voor zover ik weet zijn beiden ongespecificeerd gedrag in de W3 recommendations betreffende het layout model.

Daarnaast wordt er geen rekening gehouden met de breedte van het spatie karakter tussen de input en het validatie element. Beiden zijn inline replaced elements, wat inhoudt dat white-space tussen die elementen in de HTML (ook carriage returns en leading spaces of tabs) zich vertaald gaan zien naar een spatie tussen beide elementen.

Hmm, heb je een punt. Maar in dit geval is Chrome nog wel afwijkend. Misschien wel juist, maar afwijkend

[...]


Wist je dat je dit probleem met het afvangen van pointer interactie voor IE8 en lager (die geen opacity of rgba kleuren ondersteunen) ook op kunt lossen door background-image: url("#") te gebruiken. IE zal vrolijk de huidig ingeladen style sheet pakken (zonder een extra server request) en als bron voor een achtergrond plaatje proberen te gebruiken. Daarin zal IE meteen falen, maar het 'gebroken' achtergrond plaatje (dat IE als transparant rendert) telt nog wel als achtergrond.

Dan geeft LESS compiler een error, zelfde met vele andere IE8 trucs

douweegbertje schreef op dinsdag 10 september 2013 @ 22:20:
En maak een topic voortaan aan!

Het is allang opgelost, ik zat hier enkel te ranten. En toen snapte niemand het en toen gaf ik situatie en nu is er een discussie.
Het werkt al hoor

[R4gnax]

F.West98 schreef op dinsdag 10 september 2013 @ 22:36:
Dan geeft LESS compiler een error, zelfde met vele andere IE8 trucs

Cascading Stylesheet:

background-image : ~"url('#')";

Literals

[MoietyMe]

Ik hoop niet dat die jsFiddle gelijk staat aan de rest van de front-end in dit project.

Volgens mij wil je zoiets: http://jsfiddle.net/4N5Lg/2/

Alleen getest in Safari, maar zou het ook gewoon moeten doen in IE8+, Chrome, Firefox, etc.

Waarom je het in hemelsnaam op z'n manier zou willen doen is verder beyond me.

[ Voor 0% gewijzigd door MoietyMe op 11-09-2013 01:58 . Reden: Kleine aanpassing jsFiddle ]

[F.West98]

De HTML-base staat vast, daar kan ik niets aan veranderen en is een standaard .NET MVC item. Dus ik kan daar weinig aan doen.

Verder, het was al opgelost inmiddels, en mooier dan de testcase inderdaad.