Re: [css-d] Equal length columns?

[Hakan Kirkan]

Hey J.C,

Please check this out, that may answer your question
http://www.dynamicdrive.com/style/blog/entry/css-equal-columns-height-script/P20/


Regards,
Hakan KIRKAN
IT Manager
@http://miamirealestateinc.com
Tel+1.:954.6637171
Miami, FL

On Mon, Oct 22, 2012 at 1:59 PM, J.C. Berry  wrote:

> Hello all,
> I would like to extend one column of our site all the way to the bottom of
> the varying middle column (first column always same length). I had a JS
> that someone recommended, but it seems to be crashing IE (using P7EHC
> script). Is there a CSS-only way to do this or better script?
>
> --
> J.C. Berry, M.A.
> UI Developer
> 619.306.1712(m)
> jcharlesbe...@gmail.com
> portfolio: http://www.mindarc.com
>
> 
>
> This E-mail is covered by the Electronic Communications Privacy Act, 18
> U.S.C. ?? 2510-2521 and is legally privileged. This information is
> confidential information and is intended only for the use of the individual
> or entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any dissemination, distribution or
> copying of this communication is strictly prohibited.
>
> 
> __
> css-discuss [css-d@lists.css-discuss.org]
> http://www.css-discuss.org/mailman/listinfo/css-d
> List wiki/FAQ -- http://css-discuss.incutio.com/
> List policies -- http://css-discuss.org/policies.html
> Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
>
__
css-discuss [css-d@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Re: [css-d] Equal length columns?

[J.C. Berry]

Thanks, Al, unfortunately this test site is internal only right now. I'll
look at your pages.

On Mon, Oct 22, 2012 at 11:13 AM, Al Sparber wrote:

> On 10/22/2012 1:59 PM, J.C. Berry wrote:
>
>> Hello all,
>> I would like to extend one column of our site all the way to the bottom of
>> the varying middle column (first column always same length). I had a JS
>> that someone recommended, but it seems to be crashing IE (using P7EHC
>> script). Is there a CSS-only way to do this or better script?
>>
>>
> Hi J.C.,
>
> "CSS-only" methods would essentially be hacks like negative padding or
> using borders. Each would have it s limitations. The display property
> (table) is another option if you are not concerned with IE7 and under, but
> using the display property to make a DIV display as if it were a table cell
> is going to bring with it some the problems inherent in actual tables.
> Another option is to use background images. The best solution would be
> easier to give you, however, if you would provide a link to your page.
>
> The EHC script will not crash IE. The most it can do is cause a recursion
> if deployed incorrectly.
>
> Our home page, as well as most of our new products all use EHC and there
> are no crashes. Try these page:
>
> http://www.projectseven.com/
> http://www.projectseven.com/**products/templates/pagepacks/**
> adaptations/examples/layout-**01.htm
>
> If you want help in fixing a problem, email us directly and include a link
> to your page.
>
> If you want the good folks on this list to guide you further in a pure CSS
> solution, you should post a link to your page here.
>
> --
> Al Sparber - PVII
> http://www.projectseven.com
> The Finest Dreamweaver Menus | Galleries | Widgets
> Since 1998
> __**__**__
> css-discuss [css-d@lists.css-discuss.org]
> http://www.css-discuss.org/**mailman/listinfo/css-d
> List wiki/FAQ -- 
> http://css-discuss.incutio.**com/
> List policies -- 
> http://css-discuss.org/**policies.html
> Supported by evolt.org -- 
> http://www.evolt.org/help_**support_evolt/
>



-- 
J.C. Berry, M.A.
UI Developer
619.306.1712(m)
jcharlesbe...@gmail.com
portfolio: http://www.mindarc.com


This E-mail is covered by the Electronic Communications Privacy Act, 18
U.S.C. ?? 2510-2521 and is legally privileged. This information is
confidential information and is intended only for the use of the individual
or entity named above. If the reader of this message is not the intended
recipient, you are hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited.

__
css-discuss [css-d@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Re: [css-d] CSS "content" attribute.

[Jukka K. Korpela]

2012-10-22 20:58, Philip TAYLOR wrote:


What is somewhat odd is that when I use the validator
to confirm that it is indeed valid, and then use the CSS link-
through to validate the CSS, it (a) validates against the CSS 3
specification (why ?),


They decided the default to CSS3 a while ago. Some tools (like the CSS 
validation command in Firefox Web Developer Extension) still call the 
validator with the level set to CSS 2.1, but using the W3C CSS Validator 
directly, CSS3 is the default. Before they did this, they got many 
complaints from people who used CSS3 features.


There is no rigorous definition for "CSS3" is this context; effectively 
it means CSS 2.1 + the CSS3 specs that have reached at least CR status + 
some other CSS3 "specs" (drafts), depending on the judgment of people 
who maintain the software.



and (b) validates only the stylesheet
that appears in the  region and overlooks completely
the inline styles on which I really want it to comment :


This looks like a mystery to me, but it seems that it's just a mystery 
in reporting "Valid CSS". Testing with an HTML 4.01 document with style="color: red">Hello world and no other style sheets, I get a 
response about Valid CSS but with the message "No style sheet found". I 
think it still reads the style attributes and checks them, since if I 
use color: funnycolor instead, an error is reported.


Yucca



__
css-discuss [css-d@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Re: [css-d] Equal length columns?

[Al Sparber]

On 10/22/2012 1:59 PM, J.C. Berry wrote:

Hello all,
I would like to extend one column of our site all the way to the bottom of
the varying middle column (first column always same length). I had a JS
that someone recommended, but it seems to be crashing IE (using P7EHC
script). Is there a CSS-only way to do this or better script?



Hi J.C.,

"CSS-only" methods would essentially be hacks like negative padding or 
using borders. Each would have it s limitations. The display property 
(table) is another option if you are not concerned with IE7 and under, 
but using the display property to make a DIV display as if it were a 
table cell is going to bring with it some the problems inherent in 
actual tables. Another option is to use background images. The best 
solution would be easier to give you, however, if you would provide a 
link to your page.


The EHC script will not crash IE. The most it can do is cause a 
recursion if deployed incorrectly.


Our home page, as well as most of our new products all use EHC and there 
are no crashes. Try these page:


http://www.projectseven.com/
http://www.projectseven.com/products/templates/pagepacks/adaptations/examples/layout-01.htm

If you want help in fixing a problem, email us directly and include a 
link to your page.


If you want the good folks on this list to guide you further in a pure 
CSS solution, you should post a link to your page here.


--
Al Sparber - PVII
http://www.projectseven.com
The Finest Dreamweaver Menus | Galleries | Widgets
Since 1998
__
css-discuss [css-d@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

[css-d] Equal length columns?

[J.C. Berry]

Hello all,
I would like to extend one column of our site all the way to the bottom of
the varying middle column (first column always same length). I had a JS
that someone recommended, but it seems to be crashing IE (using P7EHC
script). Is there a CSS-only way to do this or better script?

-- 
J.C. Berry, M.A.
UI Developer
619.306.1712(m)
jcharlesbe...@gmail.com
portfolio: http://www.mindarc.com


This E-mail is covered by the Electronic Communications Privacy Act, 18
U.S.C. ?? 2510-2521 and is legally privileged. This information is
confidential information and is intended only for the use of the individual
or entity named above. If the reader of this message is not the intended
recipient, you are hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited.

__
css-discuss [css-d@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Re: [css-d] CSS "content" attribute.

[Philip TAYLOR]

Jukka K. Korpela wrote:


I don't think the constraints prevent that; class="Set: 1; parts: 2" is
valid HTML 4.01,


Well I'm d@mned : so it does.  Thank you for drawing that to my
attention.  What is somewhat odd is that when I use the validator
to confirm that it is indeed valid, and then use the CSS link-
through to validate the CSS, it (a) validates against the CSS 3
specification (why ?), and (b) validates only the stylesheet
that appears in the  region and overlooks completely
the inline styles on which I really want it to comment :


http://validator.w3.org/check?uri=http://web-consultants.org.uk/tests/css-content.html

Philip Taylor
__
css-discuss [css-d@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Re: [css-d] CSS "content" attribute.

[Jukka K. Korpela]

2012-10-22 20:31, Philip TAYLOR wrote:

>> You are effectively using the 'style' attribute as a carrier for
>> application-specific data, not for making presentational suggestions.
[...]
>> But no better option appeared to present
>> itself; "title" was an option, but there was a distinct risk that
>> a browser would present the contents thereof as a tooltip, and no
>> way of overriding that behaviour in CSS of which I was aware.

That is correct. The 'title' attribute has sometimes been used for such 
purposes, but it has obvious drawbacks, and CSS indeed has no tools for 
switching off or tuning the "tooltip" behavior.


>> There is a better option,
>> especially designed for such purposes: data-* attributes; though
>> formally still just part of the HTML5 draft, they can be freely used, as
>> they require no special support in browsers.
>
> If they were in the HTML 4.01 specification (even the transitional
> version), I would use them without compunction.

I see your point, but on the practical side, HTML 4.01 is partly 
outdated, and using some HTML5 features - which are in this case just 
canonicalization of what actually works in browsers - looks more robust 
to me than using 'style' for purposes like this.


> Unfortunately the contraints placed on syntactically valid values
> for the "class" attribute would prevent me from presenting the
> data in a semantically transparent manner : I /want/ to express
> the concept 'Set: 1; parts: 2'

I don't think the constraints prevent that; class="Set: 1; parts: 2" is 
valid HTML 4.01, though it somewhat unintuitively specifies four 
separate classes. Using such class names in CSS would be problematic 
(not impossible - you just need to use some escapes), but in scripting, 
you won't have those problems.


Yucca
__
css-discuss [css-d@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Re: [css-d] CSS "content" attribute.

[Philip TAYLOR]

Jukka K. Korpela wrote:


In any browser that conforms to the CSS 2.1 specification, yes. But
browsers are increasingly deviating from CSS 2.1 here, allowing at least
a url(...) value. I think it is an unnecessary risk to rely on a CSS 2.1
principle that was really meant to say just that in CSS 2.1, the
'content' property applies to ':before' and ':after' pseudoelements only.


Well, that is not what the prose says, but each must interpret the
prose as he or she sees fit ...


You are effectively using the 'style' attribute as a carrier for
application-specific data, not for making presentational suggestions.


I agree.


So
I would classify this as a hack and kludge.


I would reluctantly agree.  But no better option appeared to present
itself; "title" was an option, but there was a distinct risk that
a browser would present the contents thereof as a tooltip, and no
way of overriding that behaviour in CSS of which I was aware.


There is a better option,
especially designed for such purposes: data-* attributes; though
formally still just part of the HTML5 draft, they can be freely used, as
they require no special support in browsers.


If they were in the HTML 4.01 specification (even the transitional
version), I would use them without compunction.  But I am not willing
even to consider using anything from HTML 5 unless and until it becomes
a full W3C specification.  To base work that we hope will still be of
use and interest in fifty years time on a specification that is no
more than a work-in-progress would strike me as close to evidence of
certifiable insanity.


Without knowing exactly how the data is to be used, I'd say that this
might be handled using a 'class' attribute, too.


Unfortunately the contraints placed on syntactically valid values
for the "class" attribute would prevent me from presenting the
data in a semantically transparent manner : I /want/ to express
the concept 'Set: 1; parts: 2' and not have to elide this into
a horror such as "Set1parts2" (or even the somewhat less objectionable
"Set1 parts2" which multiple classes would allow).


I have coerced Opera into behaving acceptably by adding an !important
style rule in the  region.


Whenever !important seems to be the solution, it's time to reconsider
the problem.


I have never had to use !important before, I hope never to have to use
it again, but if it is both necessary and sufficient in order to
coerce Opera into behaving in a conformant manner I am willing to use
it.  And this will also have the beneficial side-effect of future-
proofing the code should browser rendering behaviour cease to be
CSS 2.1 conformant in the future, as you predict in your opening words.

Philip Taylor
__
css-discuss [css-d@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Re: [css-d] CSS "content" attribute.

[Jukka K. Korpela]

2012-10-22 19:50, Philip TAYLOR wrote:


 

I use it because (a) it is permitted (i.e., it is in accordance with
the specification and therefore validates, yet has no effect on the
rendered output in any conforming browser),


In any browser that conforms to the CSS 2.1 specification, yes. But 
browsers are increasingly deviating from CSS 2.1 here, allowing at least 
a url(...) value. I think it is an unnecessary risk to rely on a CSS 2.1 
principle that was really meant to say just that in CSS 2.1, the 
'content' property applies to ':before' and ':after' pseudoelements only.



and (b) because it is
a reliable way of passing information into the DOM which I can later
retrieve in order to affect the processing of the data.


You are effectively using the 'style' attribute as a carrier for 
application-specific data, not for making presentational suggestions. So 
I would classify this as a hack and kludge. There is a better option, 
especially designed for such purposes: data-* attributes; though 
formally still just part of the HTML5 draft, they can be freely used, as 
they require no special support in browsers.



In this
particular case I tag two (or more) disjoint spans with the same
style/content information to allow client-side scripting


Without knowing exactly how the data is to be used, I'd say that this 
might be handled using a 'class' attribute, too.



I have coerced Opera into behaving acceptably by adding an !important
style rule in the  region.


Whenever !important seems to be the solution, it's time to reconsider 
the problem.


Yucca


__
css-discuss [css-d@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Re: [css-d] CSS "content" attribute.

[Philip TAYLOR]

Thank you for your further comments, Philippe : as we are
moving on to philosophy rather than CSS per se, I will
not continue the debate here.  However, to address your
closing query :



PS - If one makes an error in a stylesheet (did you wrote E {
content: 'foo'; } instead of E::after {} ?) then sometimes strange
things happen…

PPS - E { content: 'foo'; } actually validates.


No, I am actually using (and relying on)



the actual code reads :



I use it because (a) it is permitted (i.e., it is in accordance with
the specification and therefore validates, yet has no effect on the
rendered output in any conforming browser), and (b) because it is
a reliable way of passing information into the DOM which I can later
retrieve in order to affect the processing of the data.  In this
particular case I tag two (or more) disjoint spans with the same
style/content information to allow client-side scripting to ascertain
that they are to be treated identically in terms of visual rendition
(in this case, dynamic underlining which takes place when the 
is clicked on in order to trigger a dynamic footnote to appear or
disappear.

I have coerced Opera into behaving acceptably by adding an !important
style rule in the  region.

Philip Taylor
__
css-discuss [css-d@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Re: [css-d] CSS "content" attribute.

[Philippe Wittenbergh]

Le 22 oct. 2012 à 18:10, Philip TAYLOR  a écrit :

> Thank you for your comments, Philippe, for which I am very grateful.
> I am, however, puzzled by your view that it can be considered a feature
> (albeit an experimental feature) rather than a bug.
> 
> If an implementation chooses to ignore the wording of the current
> specification, which according to :
> 
>   http://www.w3.org/Style/CSS/Overview.en.html
> 
> is CSS 2.1 as amended by CSS Color Level 3, CSS Namespaces and
> Selectors Level 3, and implements a behaviour that directly
> contradicts that specification, how can that be classified as
> anything other than a bug ?
> 
> In my view (which I do not think is heretical), an author should be
> able to /rely/ on a W3C specification, not have to test his/her work
> against every extant browser -- would you not agree ?

1. CSS 2.1 is a REC (a recommendation), it is not a law punishable with the 
death penalty (we wouldn't have much browser in that case)
2. For ages, work has been going on to extend CSS 2.1; the noted CSS-content 
module is one such example. Browser implentators can start implementing that 
work on an experimental basis and test it. Ideally, that would happen behind a 
vendor-prefix flag; obviously, that didn't happen that much at the time that 
CSS content module was first produced (10 years ago); there are (quite a few) 
other properties and values that are implemented in one or more rendering 
engines that way. Some would argue that such experimental feature shouldn't 
ship with release version of browsers. I think that would be sad; many of the 
features that are commonly used in designing pages nowadays wouldn't be as 
solid as they are today without those experimental features being included in 
release version of browsers.

So no, not a bug, but an experimental feature; an unfortunate one maybe, at 
least for you apparently, and I don’t see much use for that feature, 
personally, but nothing more. It is extending the boundaries of the possible. 
And some of those experiments stick, some fail. Some get improved, some turn 
out to be useless.

A bug is something more irrational, like, for example, Opera running on OS X 
making crapshoot of an element with { font-weight:  bold; font-style: italic; } 
- they are slanting the font, & substituting glyphs even though the specific 
font-family has all required faces. Creepily ugly doesn’t start describing it. 
Or Gecko being unable to draw a nice dotted border in combination with the 
border-radius property (an other real old bug). Real ugly results again.

Sometimes I wish I could ‘rely’ on the REC status of CSS 2.1 or other modules 
and save on cross browsers testing time. That always turn out to be wishful 
thinking. Without fail.  IOW, a pipe dream.

PS - If one makes an error in a stylesheet (did you wrote E { content: 'foo'; } 
instead of E::after {} ?) then sometimes strange things happen…

PPS - E { content: 'foo'; } actually validates.

Philippe
--
Philippe Wittenbergh
http://l-c-n.com




__
css-discuss [css-d@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

[css-d] Standards in general Re: CSS "content" attribute.

[Ben Henick]

On 10/22/12 4:10 AM, Philip TAYLOR wrote:

We, and the stakeholders for whom we work, have expectations founded on 
solving real-world problems.  Some of those problems are more imagined 
than others, depending upon the actor who presents them.


The standing and immediate requirements faced by browser product teams 
and W3C Group participants are rarely so tangible, or so relevant to the 
problems that we solve day-in-day-out.



If an implementation chooses to ignore the wording of the current
specification, which according to :

http://www.w3.org/Style/CSS/Overview.en.html

is CSS 2.1 as amended by CSS Color Level 3, CSS Namespaces and
Selectors Level 3, and implements a behaviour that directly
contradicts that specification, how can that be classified as
anything other than a bug ?


...On account of three points of logic:

1.  Reccos are not binding, no matter how passionately
we might wish otherwise.
2.  "Bugs" lead to completely unintended behavior or,
in a specification, unintended consequences.
3.  CSS 2.1 and especially CSS 3 are in a number of
areas well ahead of the state of the art.  In most
test results I see many given features labelled
"Partial" or "Experimental" - and unless someone
claims to have built a reference implementation,
it's hard to call the contradictory behavior a
bug.

...Better to call it a "misimplementation."  So goes the rationale for 
duplicative -vendor property prefixes; the implication is "until we meet 
the spec and/or the typical behavior, we're keeping this in our own 
little sandbox."



In my view (which I do not think is heretical), an author should be
able to /rely/ on a W3C specification, not have to test his/her work
against every extant browser -- would you not agree ?


I do agree in principle, starting from the premise that the Reccos etc. 
define the not-broken behavior, and then researching real-world 
deviation from that expected result.


I would even carry my sentiment to the point of stating that if it's 
contradicting the spec, then it needs to live in a -vendor prefix, 
preferably one that includes consistent (or at least well-documented) 
major version information.


So many times over the years I've wished that a vendor would relegate to 
nightlies, or omit entirely, property and selector support that's 
off-the-rez.


However, product team dynamics, release schedules, and vendors' grasp of 
our priorities rarely have very little to do with the standards-adoption 
process.  That's why the Acid tests were so important:  they provided 
batteries of sub-tests that provided concrete support goals and 
illuminated implementation challenges that once met would lead to better 
browsing software.



--
Ben Henick  lurker...@henick.net
Sitebuilder At-Larget:@bhenick
+1 785 856 1863
__
css-discuss [css-d@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Re: [css-d] CSS "content" attribute.

[Philip TAYLOR]

Philippe Wittenbergh wrote:


I am not sure I would consider this a 'bug', rather an experimental
feature. The (now marked as obsolete) css-content module allowed the
 content property ( with value: ) to be applied to any
element (as opposed to only generated content pseudo elements):
http://dev.w3.org/csswg/css3-content/#inserting-and-replacing-content-with-the

(I think it was also allowed in early drafts of CSS 2.0)

I don't think the feature is specified in other modules, although I
could have missed it.

Fwiw, WebKit and Opera allow the content of any element to be
replaced with a uri (e.g. an image).


Thank you for your comments, Philippe, for which I am very grateful.
I am, however, puzzled by your view that it can be considered a feature
(albeit an experimental feature) rather than a bug.

If an implementation chooses to ignore the wording of the current
specification, which according to :

http://www.w3.org/Style/CSS/Overview.en.html

is CSS 2.1 as amended by CSS Color Level 3, CSS Namespaces and
Selectors Level 3, and implements a behaviour that directly
contradicts that specification, how can that be classified as
anything other than a bug ?

In my view (which I do not think is heretical), an author should be
able to /rely/ on a W3C specification, not have to test his/her work
against every extant browser -- would you not agree ?

Philip Taylor
__
css-discuss [css-d@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Re: [css-d] pseudo-elements for form elements

[Frank Taylor]

Ahhh, thank you very much. This is the first i've heard the term 'replaced 
elements', but after reading the specs on what they are, it makes complete 
sense why this is the case. 

1. So I didn't necessarily do something 'wrong', other than develop in Chrome 
first. 
2. I did miss something in the specs; adding :after to things like form 
elements and images is not a defined behavior, so the browser will behave 
peculiarly. 

Do you, or does anyone else, know of a CSS-only approach to accomplish this 
task in all modern browsers?




On Oct 22, 2012, at 1:25 AM, Philippe Wittenbergh wrote:

> 
> Le 22 oct. 2012 à 15:50, Frank Taylor  a écrit :
> 
>> I'm working on an application where the client wants input[type="textbox"] 
>> to look more like a sliding on/off switch than a typical checkbox. I was 
>> able to produce the desired effect for -webkit browsers:  
>> http://cssdesk.com/jJd87 
>> 
>> But, It would appear as though :after{content:"blah"} doesn't work on  in 
>> non-webkit browsers. Opera seems to entertain the notion, but FireFox 
>> doesn't try at all. I've experimented with input, select, and textarea in 
>> FireFox and none seem to want to produce generated content. 
>> 
>> I've read through the specs and I don't see where it's written that :after 
>> or ::after shouldn't produce generated content for form elements: 
>> http://www.w3.org/TR/CSS2/generate.html#content. 
>> 
>> 1. Have I done something wrong in the CSS that causes 
>> input[type="checkbox"]:checked:after to not work in FireFox/ Opera?
>> 2. Have I missed something in the specs that makes this approach invalid?
> 
> Read the last paragraph (in green) in 
> http://www.w3.org/TR/CSS2/generate.html#before-after-content.
> Form controls are replaced elements.
> 
> Note that it is only Safari 6 and recent Chrome that support that generated 
> content on form controls (and Mobile Safari on iOS 6).
> 
> Philippe
> --
> Philippe Wittenbergh
> http://l-c-n.com
> 
> 
> 
> 
> __
> css-discuss [css-d@lists.css-discuss.org]
> http://www.css-discuss.org/mailman/listinfo/css-d
> List wiki/FAQ -- http://css-discuss.incutio.com/
> List policies -- http://css-discuss.org/policies.html
> Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

__
css-discuss [css-d@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Re: [css-d] pseudo-elements for form elements

[Philippe Wittenbergh]

Le 22 oct. 2012 à 15:50, Frank Taylor  a écrit :

> I'm working on an application where the client wants input[type="textbox"] to 
> look more like a sliding on/off switch than a typical checkbox. I was able to 
> produce the desired effect for -webkit browsers:  http://cssdesk.com/jJd87 
> 
> But, It would appear as though :after{content:"blah"} doesn't work on  in 
> non-webkit browsers. Opera seems to entertain the notion, but FireFox doesn't 
> try at all. I've experimented with input, select, and textarea in FireFox and 
> none seem to want to produce generated content. 
> 
> I've read through the specs and I don't see where it's written that :after or 
> ::after shouldn't produce generated content for form elements: 
> http://www.w3.org/TR/CSS2/generate.html#content. 
> 
> 1. Have I done something wrong in the CSS that causes 
> input[type="checkbox"]:checked:after to not work in FireFox/ Opera?
> 2. Have I missed something in the specs that makes this approach invalid?

Read the last paragraph (in green) in 
http://www.w3.org/TR/CSS2/generate.html#before-after-content.
Form controls are replaced elements.

Note that it is only Safari 6 and recent Chrome that support that generated 
content on form controls (and Mobile Safari on iOS 6).

Philippe
--
Philippe Wittenbergh
http://l-c-n.com




__
css-discuss [css-d@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/